Vulnerability Management

Purpose

This standard defines MANDATORY requirements for identifying, tracking, prioritising, and remediating security vulnerabilities across all systems and software components. It establishes SLA timelines, evidence requirements, asset inventory requirements, and the exception process for zero-day and EOL scenarios.

Normative language (MUST, MUST NOT, SHOULD, MAY) follows RFC 2119 semantics.

Rules

R-1: Asset Inventory

Every production service and its infrastructure components MUST be registered in a maintained asset inventory before or at the time of first deployment:

• The asset inventory MUST record for each asset: name, owner (team), data classification tier per SEC-GDL-001, criticality rating (Critical / High / Standard), technology stack (languages, frameworks, OS, container base image), and current deployed version
• Criticality MUST be assessed based on: data classification tier, external exposure, blast radius on compromise, and revenue/operational impact
• Asset inventory MUST be updated within 5 business days of: new service deployment, decommissioning, significant technology change, or change in data classification
• Unregistered services MUST NOT be deployed to production environments

R-2: Vulnerability Discovery

All production assets MUST be enrolled in continuous vulnerability discovery:

• Software Composition Analysis (SCA): all production services must have automated SCA scanning per SEC-STD-006 R-4
• Container image scanning: all production container images MUST be scanned for OS and package vulnerabilities before deployment and on a weekly scheduled basis against live deployments
• Infrastructure scanning: network-accessible services MUST be subject to authenticated infrastructure vulnerability scanning at minimum monthly
• SAST and DAST: integrated in the CI/CD pipeline per SEC-GOV-001
• Discovery outputs MUST feed into the vulnerability register (R-3) within 24 hours of detection

Scan configuration MUST include:

• Identification of the affected component (name, version, installed path)
• CVE identifier(s)
• CVSS v3.1 base score
• EPSS score (Exploit Prediction Scoring System) — used for prioritisation alongside CVSS

R-3: Vulnerability Register

Every confirmed vulnerability affecting a production asset MUST be tracked in a vulnerability register (may be the same system as the risk register from SEC-GOV-004 or a dedicated tool). The following fields are MANDATORY per entry:

Field	Description
vuln_id	Unique tracking identifier
cve_id	CVE identifier(s) or advisory reference
cvss_score	CVSS v3.1 base score
epss_score	EPSS score at time of ticket creation
severity	Derived severity (Critical / High / Medium / Low) per R-4
asset	Affected service and component
asset_criticality	Criticality rating from asset inventory
due_date	SLA-derived remediation deadline per R-4
resolution_date	Actual date remediation was confirmed
resolution_type	Patched / Mitigated / Accepted / False Positive
assignee	Named owner of remediation
status	Open / In Progress / Resolved / Excepted

R-4: Remediation SLA

Severity is determined by the CVSS v3.1 base score with the following adjustments:

CVSS base score	Base severity	EPSS adjustment	Mandatory remediation deadline
9.0–10.0	Critical	—	24 hours from confirmation
7.0–8.9	High	Upgrade to Critical if EPSS > 0.70	7 calendar days
4.0–6.9	Medium	Upgrade to High if EPSS > 0.50	30 calendar days
0.1–3.9	Low	—	90 calendar days

"Confirmation" for SLA start purposes means the vulnerability has been triaged and confirmed as affecting a production asset — not the CVE publication date.

SLA clocks MUST NOT be paused except during an approved change freeze. Change freezes MUST NOT extend the SLA by more than 5 business days without an explicit exception per R-6.

For Critical assets (per asset criticality): all SLAs are halved. A High severity vulnerability on a Critical asset has a 3.5-day SLA; a Medium has a 15-day SLA.

R-5: End-of-Life Component Policy

Components that have reached or passed vendor end-of-life (EOL) — including operating systems, container base images, programming language runtimes, frameworks, and third-party libraries — are subject to a time-limited migration window:

• Teams MUST be notified of impending EOL for production components at minimum 6 months before the EOL date; this notification SHOULD be automated by monitoring vendor EOL calendars
• Upon reaching EOL, a 6-month migration grace period begins; during the grace period, the EOL component MAY remain in production with a documented remediation plan and the asset owner's approval
• After the 6-month grace period: new production deployments MUST NOT include the EOL component; existing deployments that have not migrated require a formal risk acceptance per SEC-GOV-004 R-4 with Security Architecture Board approval
• Components under active exploit against the EOL version during the grace period are escalated to Critical severity and subject to the Critical SLA (R-4), overriding the grace period

EOL tracking MUST be included in the asset inventory (R-1).

R-6: Exception Process

When the mandatory SLA cannot be met:

• An exception request MUST be raised before the SLA deadline expires (not after)
• The request MUST document: CVE identifier, affected asset, reason the SLA cannot be met (no patch available, patch introduces breaking change, approved change freeze), compensating controls in place or planned, and the proposed extended remediation deadline
• Exception approval authority:
  • Medium: Engineering Lead or equivalent
  • High: Director of Engineering or equivalent
  • Critical: CISO or equivalent; approval MUST occur within 4 hours of request
• Approved exceptions MUST be recorded in the vulnerability register with approver name, approval date, and extended deadline
• Extended deadlines MUST NOT exceed: Medium +30 days, High +7 days, Critical +72 hours (available patch) or until patch availability + 72 hours (no patch)

R-7: SLA Metrics and Reporting

Vulnerability management SLA performance MUST be measured and reported:

• SLA compliance rate by severity MUST be calculated monthly (percentage of vulnerabilities remediated within SLA)
• Mean time to remediate (MTTR) by severity MUST be tracked
• Reports MUST be provided to the Security Architecture Board or equivalent accountable authority at minimum quarterly
• SLA compliance below 90% for any severity tier requires a written remediation plan presented to the Security Architecture Board within 30 days

Examples

EPSS-adjusted prioritisation

CVE-2024-XXXX: CVSS base score 7.8 (High) — standard SLA: 7 days
EPSS score: 0.82 (82% probability of exploitation in next 30 days)
Adjusted severity: Critical (EPSS > 0.70 for High-base CVEs)
Effective SLA: 24 hours from confirmation

Vulnerability register entry

vuln_id: VULN-2026-0412
cve_id: CVE-2026-12345
cvss_score: 9.1
epss_score: 0.15
severity: Critical
asset: payment-service (dependency: openssl 3.0.7)
asset_criticality: Critical
due_date: 2026-04-13T14:00:00Z  # 24h from confirmation
resolution_date: 2026-04-13T10:30:00Z
resolution_type: Patched
assignee: Bob Tanaka
status: Resolved

References

• NIST SP 800-40r4 — Guide to Enterprise Patch Management Planning
• CVSS v3.1 Specification
• EPSS Model
• CIS Controls v8 — Control 7: Continuous Vulnerability Management
• PCI DSS 4.0 — Requirement 6.3 (Security Vulnerabilities)
• endoflife.date — EOL calendar aggregator
• SEC-STD-006 — Software Supply Chain Security (SCA scanning feeds vulnerability register)
• SEC-GOV-004 — Security Risk Assessment Framework (risk acceptance for exceptions)
• SEC-STD-004 — Security Logging (vulnerability scan results in security log pipeline)

Rationale

Why EPSS as an adjustment factor on top of CVSS? CVSS measures theoretical severity; EPSS measures observed exploitation likelihood. A Critical CVSS score on a vulnerability with no known exploit in the wild can safely be treated differently from a High CVSS score with active exploitation at 80% probability. Using both gives a risk-based rather than theoretical-severity-based priority ordering.

Why a 6-month EOL grace period rather than immediate hard ban? Organisations need time to plan and execute migrations, especially for foundational runtimes. An immediate hard ban at EOL would create unrealistic compliance demands. The grace period is long enough to execute a migration for all but the largest systems, while the hard ban on new deployments prevents EOL components from spreading.

Why mandatory exception before the SLA deadline? After-the-fact exceptions normalise SLA breaches. Pre-deadline exceptions force the team to acknowledge the gap early, document compensating controls, and get approval at the right authority level before the risk is realised — not after.

Version History

Version	Date	Change
1.0.0	2026-05-05	Initial definition