DOMAIN:SUPPLY_CHAIN:VULNERABILITY_MANAGEMENT¶

OWNER: julian, pol
ALSO_USED_BY: koen, victoria, ashley
UPDATED: 2026-03-26
SCOPE: CVE monitoring, prioritisation, patching SLAs, zero-day response

OVERVIEW¶

In 2025, barely 1% of disclosed CVEs were actively exploited.
Those exploited caused outsized damage.
28.96% of KEVs showed exploitation on or before disclosure day (up from 23.6% in 2024).
Zero-day exploits increased 46% in H1 2025 (Cybernews).
Over 60% of KEVs are remediated after CISA deadlines (BitSight).

The challenge is not finding vulnerabilities — it is prioritising the right ones.

CVE MONITORING¶

SOURCES¶

PRIMARY:
- NVD (National Vulnerability Database) — US government, comprehensive
- CISA KEV Catalog (Known Exploited Vulnerabilities) — exploitation confirmed
- GitHub Security Advisories — repository-specific
- OSV (Open Source Vulnerabilities) — Google, multi-ecosystem

SECONDARY:
- vendor security advisories (AWS, Microsoft, etc.)
- package-specific advisories (npm audit, pip-audit)
- threat intelligence feeds (commercial — Recorded Future, Mandiant)

MONITORING TOOLS¶

TOOL: trivy — continuous scanning in CI and runtime
TOOL: Grype (Anchore) — SBOM-based vulnerability matching
TOOL: Snyk — commercial, good developer UX
TOOL: npm audit — built-in, npm ecosystem only
TOOL: Socket.dev — behaviour-based detection (beyond CVE matching)
TOOL: GitHub Dependabot alerts — automatic for GitHub-hosted repos

MONITORING CADENCE¶

CI/CD: scan at every build — block deployment on critical findings
PRODUCTION: daily scan of deployed images/SBOMs
REAL-TIME: CISA KEV monitoring (subscribe to RSS/email alerts)
WEEKLY: review all new advisories affecting tech stack

VULNERABILITY PRIORITISATION¶

THREE KEY SIGNALS¶

Each signal answers a different question:

1. KEV — CISA Known Exploited Vulnerabilities¶

ANSWERS: is this vulnerability being exploited in the wild right now?
SIGNAL: binary (yes/no) — the strongest signal available
COUNT: 884 KEVs identified in 2025 (118 unique disclosure sources)
ACTION: if in KEV → immediate triage, bypass standard SLA

2. EPSS — Exploit Prediction Scoring System¶

ANSWERS: what is the probability this CVE will be exploited in next 30 days?
SCALE: 0.0 to 1.0 (probability)
VERSION: EPSS v4 (Mar 2025) — consumes 250K+ threat intelligence data points daily
CAN score CVEs in NVD backlog (when official analysis delayed)
ACTION: EPSS >= 0.7 → treat as high urgency even without KEV listing
EPSS >= 0.1 → elevated monitoring, accelerate patching

3. CVSS — Common Vulnerability Scoring System¶

ANSWERS: how severe could exploitation be in technical terms?
SCALE: 0.0 to 10.0
VERSIONS: CVSS 3.1 (current standard), CVSS 4.0 (adoption growing)
LIMITATION: does not indicate likelihood of exploitation
LIMITATION: same CVSS 9.8 could be widely exploited or never exploited

PRIORITISATION ORDER¶

1. Is CVE in KEV or otherwise confirmed exploited?  
   YES → Emergency tier  
2. Is vulnerable asset internet-facing or reachable?  
   YES → Elevate priority  
3. Does system hold identity, admin, or sensitive business data?  
   YES → Elevate priority  
4. Does EPSS suggest exploitation pressure rising?  
   EPSS >= 0.7 → Accelerated tier  
   EPSS >= 0.1 → Standard tier with monitoring  
5. What is CVSS technical impact?  
   >= 9.0 → High impact  
   >= 7.0 → Medium-high impact  
   < 7.0 → Standard impact

RULE: "KEV usually outranks CVSS and EPSS.
EPSS helps find tomorrow's KEV candidates.
CVSS helps understand technical consequence."

REACHABILITY ANALYSIS¶

NOT every vulnerability in SBOM is actually exploitable.
REACHABILITY: is the vulnerable function actually called from our code?

TOOLS:
- Snyk reachability analysis (commercial)
- Grype + Reachable (experimental)
- Manual code analysis for critical findings

IF_NOT_REACHABLE: lower priority but still patch within standard SLA.
DOCUMENT: reachability assessment for any vulnerability accepted as risk.

PATCHING SLAs¶

TIER STRUCTURE¶

Tier	Criteria	SLA	Examples
EMERGENCY	KEV-listed + internet-facing/critical asset	<48 hours	RCE in web server, auth bypass
ACCELERATED	EPSS >= 0.7 OR public exploit + exposed asset	7 days	Privilege escalation in prod dep
STANDARD	CVSS >= 7.0 OR EPSS >= 0.1	30 days	High-severity without exploitation
ROUTINE	CVSS < 7.0, low EPSS, compensating controls	60-90 days	Medium/low severity, isolated system

SLA EXCEPTIONS¶

RISK_ACCEPTANCE: if patching breaks functionality — document with:
- vulnerability details and impact assessment
- compensating controls implemented
- planned remediation date
- senior management approval
- review date (max 30 days)

WAIVER_LIMIT: no waiver for KEV-listed vulnerabilities — must patch or isolate.

SLA TRACKING¶

METRIC: % of vulnerabilities remediated within SLA per tier
TARGET: 95% for Emergency/Accelerated, 90% for Standard, 80% for Routine
REPORT: monthly vulnerability management dashboard
ESCALATION: SLA breach → escalate to Team PM → human if unresolved

ZERO-DAY RESPONSE¶

DEFINITION¶

ZERO-DAY: vulnerability that is exploited before patch is available.
Zero-day exploits increased 46% in H1 2025.

RESPONSE PROCEDURE¶

HOUR_0: alert received (KEV listing, vendor advisory, threat intelligence)
HOUR_0-2: triage
- confirm vulnerability affects our stack
- assess reachability in our codebase
- determine exposed assets (internet-facing, internal)
- classify severity (critical, high, medium)

HOUR_2-8: mitigate
- IF patch available: apply to production (emergency change)
- IF no patch: implement compensating controls:
- WAF rules to block exploit patterns
- network segmentation to isolate affected systems
- disable affected feature if possible
- rate limiting to slow exploitation
- enhanced monitoring/alerting for exploit signatures

HOUR_8-48: resolve
- apply vendor patch when available
- verify fix deployment
- scan for indicators of compromise
- update SBOM and vulnerability records
- notify affected clients if their systems exposed

POST_INCIDENT:
- document timeline and response actions
- update playbook if new patterns identified
- review if earlier detection was possible

DEPENDENCY CONFUSION ATTACKS¶

ATTACK VECTOR¶

Attacker registers a public package with the same name as a private/internal package.
Package manager resolves to public version (typically higher version number).
Malicious code executes during install or at runtime.

DETECTION¶

CHECK: audit package-lock.json resolved URLs — all should point to expected registry
CHECK: monitor for public packages matching internal package names
TOOL: Socket.dev detects dependency confusion patterns
TOOL: npm audit signatures verifies package provenance

PREVENTION¶

CHECK: use scoped packages for all internal packages (@ge/package-name)
CHECK: configure npm scope to internal registry in .npmrc
CHECK: register placeholder packages on public npm for internal names
CHECK: disable public registry fallback for internal scoped packages

TYPOSQUATTING DETECTION¶

ATTACK VECTOR¶

Attacker publishes package with name similar to popular package.
Developer mistypes package name during install.
Malicious code executes via install scripts or at runtime.

2025_SCALE: 71.2% of malicious packages use names >10 characters with dashes (mimicking legitimate patterns).
LAZARUS_GROUP: 800+ associated packages on npm in 2025.

DETECTION¶

CHECK: review package name carefully before npm install
CHECK: verify package publisher and download counts
CHECK: use IDE/CLI autocomplete rather than typing package names
TOOL: Socket.dev flags potential typosquats
TOOL: npm shows "did you mean?" for misspelled package names

PREVENTION¶

CHECK: lock file review in every PR — catches unexpected package additions
CHECK: install scripts disabled by default (.npmrc: ignore-scripts=true)
CHECK: pre-approved package list for critical projects
CHECK: automated scanning for newly added dependencies in CI

VEX (Vulnerability Exploitability eXchange)¶

WHAT¶

VEX is a companion to SBOM that communicates vulnerability status.
SBOM lists components. VEX says whether a known vulnerability in a component actually affects your product.

WHY¶

SBOM + CVE matching produces many false positives.
A component may have a vulnerability but the vulnerable function is not called.
VEX lets producer communicate: "this CVE is in our SBOM but does not affect our product."

STATUS VALUES¶

NOT_AFFECTED: vulnerability present in component but not exploitable in this product
AFFECTED: vulnerability is exploitable — patch in progress
FIXED: vulnerability was present and has been remediated
UNDER_INVESTIGATION: assessment in progress

FORMAT¶

CSAF (Common Security Advisory Framework) — OASIS standard, machine-readable
CycloneDX VEX — embedded in CycloneDX SBOM or standalone
OpenVEX — lightweight, focused format

CRA RELEVANCE¶

CRA requires vulnerability handling throughout product lifetime.
VEX is the mechanism to communicate vulnerability status to customers/authorities.
SEPARATE from SBOM — CRA says SBOM must NOT contain vulnerability info (use VEX/CSAF instead).

INCIDENT RESPONSE TEMPLATES¶

CRITICAL CVE IN PRODUCTION DEPENDENCY¶

1. ASSESS reachability — is vulnerable function called from our code?  
2. CHECK exploit availability — public exploit? (KEV catalog, ExploitDB)  
3. DETERMINE severity — CVSS + reachability + data sensitivity + EPSS  
4. REMEDIATE by SLA:  
   - CRITICAL (KEV + reachable): <48h  
   - HIGH (EPSS >= 0.7): 7d  
   - MEDIUM: 30d  
5. UPDATE SBOM  
6. UPDATE VEX status  
7. NOTIFY affected clients if production was exposed

PACKAGE COMPROMISE (event-stream, ua-parser-js scenarios)¶

1. IMMEDIATELY pin to last known good version  
2. AUDIT git history of package for malicious changes  
3. CHECK if malicious version was installed in any environment  
4. ROTATE any credentials that may have been exfiltrated  
5. SCAN for indicators of compromise (network connections, file changes)  
6. REPORT to npm/registry + NCSC-NL if significant  
7. UPDATE incident report and post-mortem

SUPPLY CHAIN WORM (Shai-Hulud scenario)¶

1. ISOLATE affected environments (network segmentation)  
2. IDENTIFY all affected packages (worm propagation path)  
3. PIN all dependencies to pre-compromise versions  
4. REBUILD from clean state (do not trust node_modules)  
5. ROTATE all secrets accessible from CI/CD  
6. AUDIT CI/CD logs for exfiltration  
7. COORDINATE with package registry security team

METRICS AND REPORTING¶

KEY METRICS¶

MTTR_BY_TIER: mean time to remediation per severity tier
SLA_COMPLIANCE: % of vulns patched within SLA
OUTSTANDING: count of open vulnerabilities by tier
TREND: month-over-month change in vulnerability backlog
COVERAGE: % of production systems with active vulnerability scanning
EPSS_TRACKING: % of EPSS >= 0.7 issues mitigated within SLA

REPORTING CADENCE¶

DAILY: automated scan results (CI/CD pipeline output)
WEEKLY: new vulnerability summary for engineering team
MONTHLY: vulnerability management dashboard for management
QUARTERLY: trend analysis and SLA compliance review

READ_ALSO: domains/supply-chain/index.md, domains/supply-chain/sbom.md, domains/supply-chain/dependency-management.md