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:

Severity	Default SLA
Critical	7 days
High	30 days
Medium	90 days
Low	no SLA

These defaults align with common enterprise patching cadences cited in NIST SP 800-40r4 and similar frameworks. 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 real work to dispatch, review, and roll out, and surfacing the warning before the deadline gives you that runway.

Setting per-org policy

The per-org SLA is editable inline on /<org>/_admin/security#severity-sla. Pick a tighter deadline per severity — the breach calculation reads the per-tenant security_sla_policy row immediately, no re-scan needed. The defaults above apply until you override them. If you need a custom non-time-based SLA shape (e.g. business-day clocks, holiday calendars), open a support ticket.

Note on SLA scope. The table above is the finding-remediation clock — how long you have to close a finding raised against your code. That’s distinct from two other SLAs documented elsewhere on fremforge:
The platform CVE patch SLA (Critical 48h / High 72h / Medium 7d) covers how fast fremforge patches its own stack — see the platform-security commitments on Security and supply chain.
The vulnerability disclosure SLA (Critical fix in 24h / disclose 30d after fix, etc.) covers researcher-reported vulnerabilities in fremforge itself — see Vulnerability disclosure.

Via REST API

The severity-SLA policy can be set on the public API surface — useful when you want to enforce a consistent posture across many orgs from a configuration script or compliance pipeline.

Update policy PUT /api/v1/orgs/:slug/security/sla-policy body: { "critical_sla_days": 3, "high_sla_days": 14, "medium_sla_days": 60, "low_sla_days": null }

Each field accepts 1–365 days, or null to leave a severity without an SLA. Requires a Personal Access Token (PAT) with the policy:write scope:

curl -X PUT \
  -H "Authorization: Bearer ${FREMFORGE_PAT}" \
  -H "Content-Type: application/json" \
  -d '{"critical_sla_days":3,"high_sla_days":14,"medium_sla_days":60,"low_sla_days":null}' \
  https://frem.sh/_app/api/v1/orgs/acme/security/sla-policy

See the public REST API reference for the full OpenAPI specification.

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.