Policy-as-code
Policies are declarative YAML you version alongside your code. One policy governs the scan gate, the firewall, license rules, and the runtime allowlist. The policy version is stamped into every signed decision, so an auditor can replay exactly which ruleset produced a given verdict.
Shape
policy.yaml
version: 3
gate: # CI PASS/FAIL
fail_on_tier: patch-now # patch-now | sprint | monitor
max_critical: 0
max_high: 5
cvss_ceiling: 9.0
licenses:
deny: [GPL-3.0-only, AGPL-3.0-only]
allow_with_obligation: [MPL-2.0, EPL-2.0]
firewall:
modes: { npm: enforce, pypi: enforce, maven: soak }
block_when:
- kev: true
- epss_gte: 0.90
reachable: true
cooldown_hours: { npm: 24 } # hold brand-new versions
runtime:
egress:
allow: [registry.npmjs.org:443, github.com:443]
default: denySections
| Section | Controls |
|---|---|
gate | The CI verdict: severity ceilings, count thresholds, and which decision tier fails the build. |
licenses | Allow/deny lists and obligation conditions (copyleft scope, attribution, NOTICE). |
firewall | Per-ecosystem mode, block conditions (KEV/EPSS/reachable), version-pinning, cooldown windows. |
runtime | The egress allowlist enforced by the eBPF agent. |
The policy is part of the evidence
Because the policy version is recorded in every signed decision, “why was this blocked?” is answerable precisely — against the exact rules in force at that moment, not today’s.
Compliance presets
Built-in presets map the gate to regulated frameworks (DORA, NIS2 live; SOC 2, ISO 27001, PCI DSS, FedRAMP, HIPAA and others as presets), so a project can extends: a preset and override specifics.