Finding and platform SLAs

Understand finding remediation SLA states and Team or Regulated platform availability targets, including SLA event webhooks and their limits.

Two different meanings of SLA

CodeCleared uses “SLA” in two separate contexts. Keep them distinct when communicating with stakeholders.

Finding remediation SLA

On the governance branch, a finding can be opened, at_risk, breached, ignored, resolved, or reopened. These states help you track the remediation commitment defined by your policy. Subscribe to finding.sla.* webhooks when another system needs to react to a state change, or use native Jira / Linear issue trackers to open tickets automatically.

An ignored finding remains a recorded decision. A rule-wide or CVE-wide ignore marks matching findings as ignored on governance; unignore restores them to active review when no other active ignore still covers them. Occurrence ignores affect a single finding key.

Deadline clock (org setting)

By default, remediation deadlines start from first seen plus your severity days (unchanged historic behaviour).

Organizations can switch the SLA clock to fixable from: for vulnerabilities, the deadline starts when CodeCleared first observes that a fix is available (fixableFromAt). While no fix is known, there is no deadline (the finding cannot become at_risk or breached from the clock alone). Changing this setting recalculates open findings immediately. There is no separate “unbreached” webhook when a finding leaves breached; Virtual 0 and the dashboard follow the stored status.

Non-vulnerability finding types always use first seen.

Ignore while no fix available (project unit)

Separately, a project unit can enable ignore while no fix is available. Unfixed vulnerabilities then receive a system ignore (awaiting-fix, one row per package occurrence) until a fix is known. That is distinct from the manual Not fixable ignore, which never ends automatically. System awaiting-fix rows are not creatable or removable via the ignore API — turn the project-unit setting off instead. When a fix appears (from a scan or from the advisory cache refresh), the system lifts only that occurrence’s awaiting-fix and resumes the SLA clock according to the org deadline setting.

Fixable columns on the Virtual 0 dashboard

For vulnerability findings, the SLA / Virtual 0 table shows:

Fixable — whether CodeCleared currently knows a fix (scan fixedVersion and/or cached OSV advisory data).
Fixable from — the date CodeCleared first observed that a fix was available, plus how many days ago that was.

This is a platform discovery timestamp, not an official vendor “fix published on” date from NVD/OSV. Advisory caches refresh on a nightly bulk import and a periodic per-ID sync (typical lag up to about 24 hours for OSV-only fixes), on top of fix metadata already present at scan time. After those refreshes, tracked findings and auto-ignores update without waiting for another scan. Non-vulnerability finding types show “—” for these columns.

Platform availability SLA

Team has a 99.9% platform availability target and Regulated has a 99.99% target, subject to the applicable agreement. These numbers describe service availability, not a promise that a finding will be fixed, a scan will finish by a particular time, or every risk will be detected.