Proposal: Governance Policy Integration for Security Reviews
Summary
Extend the security review action to support governance policies — configurable rules that define what constitutes a security violation based on organizational context, not just generic vulnerability patterns.
Problem
The current security review action uses Claude to analyze code changes for vulnerabilities, which is great for generic security scanning. However, organizations need:
- Custom policy enforcement — Different rules for different repos/teams (e.g., "no direct database queries in API controllers", "no eval() in user-facing code")
- Governance-aware severity scoring — A
curl | bash in a CI script is different from curl | bash in a dev utility. Context matters.
- Tool/command governance — When reviewing agent code, flag agents that call dangerous tools without governance wrappers
- Audit trail integration — Security review findings should feed into compliance audit trails
Proposed Enhancement
A .github/governance-policy.yaml that the security review action loads:
governance:
name: org-security-policy
severity_overrides:
- pattern: "eval\\("
context: "user_input"
severity: critical
- pattern: "subprocess\\.call"
context: "hardcoded_args"
severity: low
agent_governance:
require_tool_allowlist: true
flag_unrestricted_agents: true
require_audit_trail: true
custom_rules:
- name: no-raw-sql-in-controllers
pattern: "execute\\(.*SELECT|INSERT|UPDATE|DELETE"
paths: ["src/controllers/**", "src/api/**"]
severity: high
message: "Use ORM methods instead of raw SQL in API controllers"
Integration
The security review action would:
- Load
governance-policy.yaml if present
- Pass governance context to Claude alongside the diff
- Apply severity overrides based on organizational policy
- Add governance-specific findings to the review output
Context
We maintain Agent-OS governance framework. Related proposals:
Proposal: Governance Policy Integration for Security Reviews
Summary
Extend the security review action to support governance policies — configurable rules that define what constitutes a security violation based on organizational context, not just generic vulnerability patterns.
Problem
The current security review action uses Claude to analyze code changes for vulnerabilities, which is great for generic security scanning. However, organizations need:
curl | bashin a CI script is different fromcurl | bashin a dev utility. Context matters.Proposed Enhancement
A
.github/governance-policy.yamlthat the security review action loads:Integration
The security review action would:
governance-policy.yamlif presentContext
We maintain Agent-OS governance framework. Related proposals: