Policy Engine

Express custom security rules as code. 'No Critical findings on production assets', 'License GPL blocked', 'SLA breach pages on-call'. The policy engine evaluates every scan + every finding against your policies.

What policies are

Policies are rules that fire on events (finding created, scan completed, asset added). They evaluate conditions and execute actions. Examples:

  • "Critical finding on Tier-0 asset → page on-call within 5 min"
  • "PR introduces GPL dep → fail PR gate"
  • "Scan finds > 10 new Highs → notify security team Slack"
  • "Customer asset has unverified domain > 30 days → email asset owner"
  • "Verify-fix returns Still-exploitable on Critical → reopen ticket + assign senior eng"

Policy components

policy "critical-tier0-pages-oncall" {
  when:
    event = "finding.created"
    finding.severity in ["critical"]
    finding.asset.tier == "tier-0"
  then:
    page_oncall(channel = "pagerduty", severity = "P1")
    slack_post(channel = "#sec-incidents", template = "critical_tier0")
    audit_log(reason = "policy critical-tier0-pages-oncall fired")
}

Events

finding.created
finding.updated
finding.verified_fixed
finding.sla_approaching
finding.sla_breached
scan.started
scan.completed
scan.failed
asset.added
asset.changed
pr.gate_failed
user.invited

Actions

  • Notify — Slack, PagerDuty, email, custom webhook
  • Create ticket — in your linked tracker
  • Deploy virtual patch — Shield rule from the finding
  • Run Auto-Fix — generate PR
  • Block PR — fail the PR gate
  • Pause scan — temporarily disable a schedule
  • Tag — add a label to the finding/asset
  • Run sub-scan — trigger a deeper scan on the asset
  • Audit log — record the policy firing

Policy library

Settings → Policies → Library shows pre-built policies for common scenarios — pick a starter pack:

  • Standard — Critical paging, SLA enforcement, basic license control.
  • Strict — block any PR with any new finding, page on every High, etc.
  • Compliance-driven — SOC 2 / ISO 27001 specific.
  • Custom — write your own from the policy editor.

Testing policies

The policy editor includes a "dry-run" mode — point a policy at past findings and see which would have fired. Useful for tuning before deploying.

Audit trail

Every policy execution lands in the audit log: which policy, what fired it, which actions ran, success/failure of each action. Useful for retrospectives + auditor verification.

What's next

  • Alerts — simpler alternative for basic notification flows.
  • Compliance — policies driving compliance enforcement.
  • License Policies — a specialized policy category.