Skip to main content
Security
Severity SLAs

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:

SeverityDefault SLA
Critical7 days
High30 days
Medium90 days
Lowno 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/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.

See also

Cosign signingVulnerability disclosure