Security Policies as Code: Version Control Your Risk Appetite

Security policy decisions should not live in a dashboard, a wiki page, or someone's head. They should be versioned, reviewed, and deployed like any other configuration.

What policy-as-code means for security

Policy-as-code means expressing security rules as structured configuration that is:

• Version controlled — every change is tracked, attributed, and reversible.
• Code reviewed — policy changes go through the same PR process as code changes.
• Environment-aware — different policies for different repositories, branches, or deployment targets.
• Machine-readable — enforcement is automated, not manual.

A practical policy schema

# .secbez/policy.yml
version: 1
gate:
  mode: enforce          # shadow | warn | enforce
  thresholds:
    critical: block
    high: block
    medium: warn
    low: pass
    info: pass
detectors:
  secrets:
    enabled: true
    allowlist:
      - "test/fixtures/**"
  injection:
    enabled: true
  xss:
    enabled: true
    exclude_patterns:
      - "*.test.tsx"
notifications:
  slack_channel: "#security-alerts"
  mention_on: critical

Benefits of versioned policy

Audit trail

When a compliance auditor asks "what was your security policy on this date?" you can answer with a git commit hash.

Accountability

Policy changes require a PR with a description of why the change was made. No more silent configuration changes in a dashboard.

Consistency

The same policy file governs every CI run. There is no drift between what the team agreed to and what the automation enforces.

Testability

Policy configuration can be validated in CI. If someone removes a required detector, the policy validation step catches it before merge.

Migration path

If your security policies currently live in a dashboard or wiki:

1. Export current policy settings to a YAML or JSON file.
2. Add the file to the repository root.
3. Update your security tooling to read policy from the file.
4. Require PRs for policy changes.
5. Add policy validation to your CI pipeline.

Treat security policies like infrastructure configuration. Define them in code, review changes in pull requests, and enforce them automatically.