dpndncY

The decision engine

Every finding — from a scan, a firewall evaluation, or a runtime trace — passes through one decision engine that assigns a tier with a hard SLA. Instead of a wall of CVSS scores, you get a queue: what to patch now, what fits this sprint, what to monitor, and what's been formally accepted.

The four tiers

TierSLAMeaning
Patch Now48hReachable + actively exploited (KEV) or very high EPSS. Drop everything.
Patch This Sprint336h (2 weeks)Serious and credible, but not under active exploitation right now.
Monitor720h (30 days)Real but low exploit signal or unreachable — keep an eye on it.
Accept RiskFormally accepted with a reason and an approver; recorded, not ignored.

How a tier is chosen

The engine combines the same signals everywhere: advisory severity (CVSS), exploit probability (EPSS), known exploitation (KEV), public exploit code (ExploitDB), and code-level reachability / attack-path. A critical CVE that is unreachable and has near-zero EPSS lands in Monitor; a medium one that is reachable and KEV-listed is escalated to Patch Now. Each decision carries a per-signal rationale so the tier is explainable, not a black box.

Mapping to CI gates

Policy gates turn tiers into a PASS/FAIL verdict for CI — e.g. fail the build if any Patch-Now finding is introduced, warn on Patch-This-Sprint. See Policy reference.

One engine, three surfaces
The firewall (pre-install), the scanner (in CI), and the runtime agent (in the job) all call the same engine — so a package’s tier is consistent whether you meet it at install time or scan time.

Overrides

Downgrading a tier (e.g. accepting a risk) goes through the waiver/approval flow and is recorded in the signed decision — see Signed bypass.