Vulnerability Management SLA

Policy status

Status: Approved · approved 2026-08-21

Document ID: SID-POL-VULNMGMT
Version: 1.1
Effective Date: 2026-08-21
Owner: CISO
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.

1.1 Relationship to Commercial Support

This policy is the floor, not the ceiling. It applies to every vulnerability report regardless of who submits it or whether the affected organisation holds a paid support subscription. Customers under a SIROS Foundation commercial support agreement receive, for any ticket classified as a security vulnerability, whichever is faster: their subscription tier's committed response time, or the timelines in this policy. See the Commercial Support & SLA Framework for tier-specific commitments, which are designed to meet or exceed this policy.

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

Acknowledgment timelines above are a hard internal commitment, enforced through the on-call and triage workflow in Section 5. Remediation timelines are the Foundation's operational target for delivering a fix, workaround, or compensating control — not a guarantee of resolution by a fixed date, since fix complexity, upstream dependencies, and coordinated-disclosure timing are not always within SIROS Foundation's control. Where a remediation timeline is at risk of being missed, the Risk Acceptance process (Section 5.3) applies: the delay is documented, approved by the project lead, capped at 2× the original SLA, and tracked as an open finding, with aggregate performance published via the metrics in Section 7.

4.2 Definitions

• Business Hours: 09:00–17:00 Central European Time (CET/CEST), Monday through Friday, excluding SIROS Foundation public holidays.
• Business Day / Business Days: One Business Hours window per business day; a timeline of "N business days" is measured in elapsed Business Hours windows, not calendar days.
• 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. Remediation timelines are operational targets, not contractual guarantees to individual reporters (see above).
• Verification: The fix is confirmed effective (tests pass, vulnerability scan clean).

5. Workflow

5.1 Automated Discovery

Dependabot / CodeQL / govulncheck alert
    → GitHub Security Advisory created automatically
    → Assigned to CISO via CODEOWNERS
    → Triaged within acknowledgment SLA
    → Fix PR created → reviewed → merged → deployed
    → Alert auto-closes on fix

5.2 Manual Discovery / Disclosure

Report received (security.txt / SECURITY.md contact)
    → Acknowledge to reporter within SLA
    → Triage and classify severity
    → Create private GitHub Security Advisory (if applicable)
    → Fix PR created → reviewed → merged → deployed
    → Coordinate disclosure with reporter

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	CISO	Initial version
1.1	2026-08-21	CISO	Clarified relationship to commercial support SLAs (§1.1); reframed Remediation as an operational target rather than a contractual guarantee (§4.1); added Business Hours/Business Day definitions (§4.2)