Policies & Rule Engine

Paths: /policies · Sidebar: Governance → Policies

Policies and the Rule Engine encode your risk appetite as deterministic rules - the same inputs always produce the same decision, so governance is defensible in an audit and consistent across teams.

The Rule Engine

A rule is a condition → action over findings/vulnerabilities:

• Conditions - severity, CWE, source (DAST/SAST/SCA/IaC…), KEV / exploitable, risk score, reachability, environment, application/product, tags, age.
• Actions - fail / warn / pass at a gate, raise priority, require an owner, notify, or open a ticket.
• Scope - global, per environment (strict prod, lenient dev), or per app.

Rules are versioned with full history and an evaluation log (which rule fired on which finding, when) - so every decision is traceable.

Example rules

• Block on KEV - fail if any finding is on the CISA KEV list.
• Block on proven-exploitable - fail if AI exploitation confirmed exploitation.
• Critical SLA - escalate any Critical not fixed within 7 days.
• New-only gate - fail a PR only on new findings vs the baseline.

Policies vs Rules

• Rules are the fine-grained engine (the building blocks).
• Policies bundle rules into a named, scoped set you apply to a context (e.g. "PCI prod policy").

Both feed the CI Gate, which merges them with the per-call severity threshold and threat-model blind-spots into one verdict.

Start narrow, tighten later

Begin with "block on Critical + KEV only", watch it for a sprint, then add rules. A gate that fails rarely but meaningfully is the one teams respect.

See also Compliance & Maturity for the framework-control view, and SLA Policy for remediation windows.