Severity SLAs

Every open finding (SAST, dependencies, container images, malware) carries an inline SLA pill next to its severity. The pill is computed from one input — how old the finding is — and one config — your org’s severity-SLA policy.

Defaults

Out of the box, every org gets these targets:

These are industry-anchored — they match the upper bound NIST SP 800-40r4 recommends for enterprise patching of HIGH/CRITICAL CVSS findings, and they line up with the defaults GitHub Advanced Security ships when you turn on Dependabot SLAs. Tighten them if your audit posture demands it.

States the pill can show

• Within (green) — under the SLA, less than 80% of the way to the deadline.
• Approaching (amber) — between 80% and 100% of the deadline. Plan a fix this week.
• Breached (red) — past the deadline. Counted in the weekly digest and the overview “SLA breaches” tile.
• No SLA (grey) — severity has no policy attached (the default for low).

The 80%-of-deadline threshold for approaching is deliberate — most fixes take a non-trivial amount of work to dispatch, review, and roll out, and surfacing the warning before the deadline gives you that runway.

Setting per-org policy

Currently the form for editing the per-org SLA lives on the roadmap; until it ships, the defaults above apply. The schema is in place — security_sla_policy per-tenant table — and the breach calculation already reads it, so when the form lands your edits take effect immediately without a re-scan.

How breaches feed other pages

• Open security PRs widget on /<org>/_admin/overview highlights the highest-severity breached recommendation first.
• Weekly digest counts breaches in the headline summary.
• SIEM forwarding emits code-security.sla.breached audit events the first time a finding crosses the line.

See also

• OSV recommendations — the fix list that closes the loop.
• Push protection — secrets get pre-receive treatment instead of an SLA clock.