Vulnerability Management SLA

Property	Value
Document ID	SID-POL-VULNMGMT
Version	1.0
Effective Date	2026-04-12
Owner	Platform Team
Review Cycle	Annual (next review: 2027-04)

1. Purpose

This document defines the service level agreements (SLAs) for handling security vulnerabilities discovered in SirosID software, dependencies, and infrastructure.

2. Scope

This policy covers:

• Vulnerabilities reported by automated tools (Dependabot, CodeQL, govulncheck, npm audit).
• Vulnerabilities disclosed via responsible disclosure channels.
• Vulnerabilities discovered during code review or penetration testing.

3. Severity Classification

Severity is determined by the CVSS v3.1 base score, aligned with GitHub advisory severity levels:

Severity	CVSS Score	Examples
Critical	9.0 – 10.0	Remote code execution, authentication bypass, private key exposure
High	7.0 – 8.9	Privilege escalation, SQL injection, significant data exposure
Medium	4.0 – 6.9	Cross-site scripting, information disclosure, denial of service
Low	0.1 – 3.9	Minor information leaks, low-impact misconfigurations

4. Response SLAs

4.1 Timelines

Severity	Acknowledgment	Remediation (Fix or Mitigate)	Verification
Critical	4 hours (business hours)	72 hours	Same day as fix
High	1 business day	7 calendar days	Within 1 day of fix
Medium	3 business days	30 calendar days	Within 3 days of fix
Low	5 business days	90 calendar days	Next scheduled review

4.2 Definitions

• Acknowledgment: The vulnerability is triaged, assigned a severity, and an owner is designated.
• Remediation: A fix, workaround, or compensating control is deployed. If a fix is not possible within the SLA, a documented risk acceptance with mitigation plan is required.
• Verification: The fix is confirmed effective (tests pass, vulnerability scan clean).

5. Workflow

5.1 Automated Discovery

5.2 Manual Discovery / Disclosure

5.3 Risk Acceptance

If a vulnerability cannot be remediated within the SLA:

1. Document the vulnerability, its impact, and why remediation is delayed.
2. Implement compensating controls (e.g., WAF rule, feature flag, network restriction).
3. Obtain written approval from the project lead.
4. Set a revised remediation date (not to exceed 2× the original SLA).
5. Track in the compliance system as an open finding.

6. Dependency Vulnerabilities

6.1 Automated Response

Dependabot security updates are treated as follows:

Dependabot Severity	Our Severity	Action
Critical	Critical	Merge within 72 hours
High	High	Merge within 7 days
Moderate	Medium	Merge within 30 days
Low	Low	Merge within 90 days

6.2 Breaking Updates

If a security update introduces breaking changes:

1. Assess whether the vulnerability is exploitable in our usage.
2. If not exploitable, document as risk-accepted and schedule the update.
3. If exploitable, prioritise the migration work within the SLA.

7. Metrics and Reporting

The following metrics are tracked quarterly:

• Mean Time to Remediate (MTTR) by severity.
• SLA compliance rate (% of vulnerabilities fixed within SLA).
• Open vulnerability count by severity and age.
• Dependency update freshness (% of dependencies at latest patch version).

Reports are generated from GitHub Security Advisory data and Dependabot metrics.

8. Escalation

Condition	Escalation
Critical not acknowledged within 4h	Escalate to project lead
Critical not remediated within 72h	Escalate to project lead + document risk acceptance
SLA compliance < 80% for any quarter	Review process and staffing with management

9. Compliance Mapping

This policy addresses:

Finding	Framework	Control
EN-S-3	ENISA	Vulnerability scanning and management
ISO-T-6	ISO 27001	Vulnerability and malware protection
ISO-O-12	ISO 27001	Supply chain security

10. Document History

Version	Date	Author	Changes
1.0	2026-04-12	Platform Team	Initial version