Every organization with a vulnerability management program has SLAs. Critical vulnerabilities must be remediated within 7 days. High within 30. Medium within 90. The numbers vary, but the pattern is universal.
What is also universal is the failure to meet those SLAs consistently. Most organizations cannot accurately measure their SLA compliance, let alone improve it. The vulnerability data is scattered across multiple scanners, the remediation tracking is manual, and the exception process is informal.
This guide addresses the practical challenges of making vulnerability SLAs work for supply chain security.
Designing Effective SLAs
Severity-Based Timelines
The standard approach ties remediation timelines to vulnerability severity:
- Critical: 7 days
- High: 30 days
- Medium: 90 days
- Low: 180 days or accept risk
These timelines should reflect your organization's actual remediation capacity. SLAs that nobody can meet create a culture of non-compliance. Start with achievable timelines and tighten them as your processes improve.
Context-Adjusted Severity
Not all critical CVEs are equally critical in your environment. A critical vulnerability in a library function your application never calls is different from a critical vulnerability in your authentication system.
Consider adjusting SLA timelines based on exploitability (is there a public exploit), exposure (is the system internet-facing), and data sensitivity (what data can be accessed through exploitation).
Fix Availability
SLA clocks should account for fix availability. If a vulnerability is disclosed but no patch exists, holding teams to a 7-day remediation SLA is unreasonable. Define separate timelines for when a fix is available and when it is not.
For vulnerabilities without fixes, the SLA should require a documented mitigation plan rather than a patch deployment.
Measurement Challenges
When Does the Clock Start
The SLA clock should start when the organization becomes aware of the vulnerability, not when the CVE was published. If your scanner detects a vulnerability on January 15 that was published on January 10, the clock starts on January 15.
This distinction matters because it focuses on what the organization can control. You cannot control when a CVE is published, but you can control how quickly your scanning detects it.
When Is It Remediated
Remediation is not complete when the patch is applied to one system. It is complete when the patch is deployed to all affected systems. Track per-system remediation status and count the SLA as met only when all instances are remediated.
For container environments, remediation means rebuilding and redeploying the affected container image. Track the deployment of the rebuilt image across all environments.
Handling Rescans and Verification
After remediation, verify that the vulnerability is actually fixed. A scanner rescan that confirms the fix closes the SLA. Without verification, you are tracking intention rather than outcome.
Dealing With Scanner Disagreements
Different scanners may assign different severities to the same CVE or may detect vulnerabilities at different times. Define a primary scanner whose findings drive SLA timelines, and use secondary scanners for validation.
Tracking Infrastructure
Automated Discovery to Ticket Creation
Automate the pipeline from vulnerability discovery to remediation ticket creation. When a scanner finds a new vulnerability that exceeds your severity threshold, automatically create a ticket in your project management system with the CVE details, affected systems, severity, SLA deadline, and remediation guidance.
Manual ticket creation introduces delays that eat into your SLA timeline.
Per-Team Dashboards
Each team should see their own SLA compliance metrics. Show them their open vulnerabilities, upcoming SLA deadlines, and historical compliance rate. Make the information actionable: for each open vulnerability, show what needs to be done and when.
Escalation Automation
When an SLA deadline approaches, automate escalation. Seven days before the deadline, notify the responsible team. Three days before, notify the team lead. On the deadline day, notify the security team. After the deadline, notify management.
This escalation chain should be defined in advance and enforced automatically, not dependent on someone remembering to follow up.
Exception Handling
Formal Exception Process
Not every vulnerability can be remediated within the SLA. Legitimate exceptions exist: the fix introduces a breaking change, the affected system is scheduled for decommission, or the fix requires a major version upgrade that needs extensive testing.
Define a formal exception process that requires a written justification, an approved temporary mitigation, a revised timeline, and periodic review of the exception status.
Track Exceptions Separately
Report on exception rates alongside SLA compliance. A team that is "100% SLA compliant" but has 40% of their vulnerabilities on exception is not actually managing risk well.
Time-Limit Exceptions
Exceptions should not be permanent. Set a maximum exception duration, typically 90 days, after which the exception must be renewed or the vulnerability must be remediated.
Reporting
Executive Reporting
Executives need a simple view: overall SLA compliance percentage, trend over time, and any critical vulnerabilities past their SLA deadline. Focus on risk rather than technical details.
Operational Reporting
Security operations needs detailed reports: which teams are struggling, which vulnerability types are hardest to remediate, and where the process bottlenecks are.
Compliance Reporting
Auditors need evidence that your SLA process is defined, measured, and enforced. Maintain records of SLA definitions, compliance measurements, exception approvals, and escalation actions.
How Safeguard.sh Helps
Safeguard.sh provides the vulnerability discovery and tracking capabilities needed for effective SLA compliance. It continuously scans your software portfolio for vulnerabilities, tracks remediation status across all affected systems, and provides the metrics and reporting needed for SLA management. When a new vulnerability is discovered, Safeguard.sh automatically identifies all affected applications and provides the data needed to initiate remediation within your SLA timeline.