SLA (Service Level Agreements)
Musha tracks remediation SLAs — deadlines by which vulnerabilities should be fixed based on their severity.
Default SLAs
| Severity | SLA |
|---|---|
| Critical | 7 days |
| High | 30 days |
| Medium | 90 days |
| Low | No SLA |
| Info | No SLA |
The SLA clock starts when the vulnerability is first detected (first_seen date).
SLA indicators in the UI
Findings approaching or past their SLA deadline are highlighted:
- Orange — SLA expires in the next 7 days (approaching)
- Red — SLA has already expired (breached)
For accepted findings, the SLA shows the acceptance expiry date instead of the remediation deadline.
Custom SLAs
If your organization has compliance requirements that differ from the defaults (e.g., banking regulations require critical vulns to be fixed in 24 hours), you can configure custom SLAs in Settings → Scan Policy:
- Critical SLA (days)
- High SLA (days)
- Medium SLA (days)
Constraints: all values must be ≥ 1 day, and Critical ≤ High ≤ Medium (a critical vuln can never have a longer deadline than a high one).
Custom SLAs apply to all new findings from the moment you save the settings. Existing findings keep their original SLA based on the settings at the time they were first detected.
SLA and vulnerability states
| State | SLA behavior |
|---|---|
open, in_backlog, in_progress | SLA active — clock is running |
resolved | SLA shown as satisfied (no deadline) |
false_positive | SLA not shown |
accepted | SLA shows acceptance expiry date instead |
Export for compliance
You can export all findings with their sla_deadline and sla_breached fields from Security → Export. This export is specifically designed as evidence for SOC 2 / ISO 27001 audits.
See Vulnerabilities API for the programmatic export endpoint.