Risk-Based Vulnerability Management: A Practical Guide

The average enterprise has more than 1,000 open vulnerabilities at any given time. Patches often require testing, change management, and downtime coordination. Security teams have finite capacity. The question is not “patch everything” — it’s “patch the right things first.”

Our vulnerability management service uses exactly this risk-based approach to help organisations focus remediation effort where it matters most.

Most organisations answer this question by sorting by CVSS score. This is wrong, and the consequences are significant: teams spend weeks patching CVSS 9.0 vulnerabilities in isolated internal systems while leaving CVSS 7.0 vulnerabilities in internet-facing applications unpatched — exactly backwards from a risk perspective.

This guide explains why CVSS-centric prioritisation fails, what the better alternatives are, and how to build a programme that reduces actual risk rather than just improving compliance metrics.

Why CVSS Fails as a Prioritisation Tool

The Common Vulnerability Scoring System (CVSS) was designed to measure the intrinsic severity of a vulnerability — how dangerous it is in the worst-case environment. It was never intended to be the primary prioritisation mechanism for a vulnerability management programme, but that’s how it’s almost universally used.

What CVSS measures:

• Attack vector (network, adjacent, local, physical)
• Attack complexity
• Privileges required
• User interaction required
• Impact on confidentiality, integrity, and availability

What CVSS does NOT measure:

• Whether the vulnerability is currently being exploited in the wild
• Whether your specific environment is actually exposed to the attack vector
• Whether you have compensating controls that reduce the risk
• The business value of the affected asset
• Whether a working exploit exists and is in use

The result: A CVSS 9.0 vulnerability in a theoretically exploitable kernel driver that requires local access on a sandboxed development VM scores higher than a CVSS 7.5 authentication bypass in your public-facing payment gateway. Any rational risk prioritisation would reverse this.

A 2022 analysis found that only 5% of known CVEs were ever exploited in the wild. Organisations spending resources patching the other 95% of high-CVSS CVEs are optimising for a score, not for risk.

The Components of Real Risk

Risk = Threat × Vulnerability × Asset Value

Each component needs to be considered:

Threat: Is This Actually Being Exploited?

CISA KEV (Known Exploited Vulnerabilities Catalog)

CISA maintains a living list of CVEs with confirmed exploitation in the wild. These are the vulnerabilities that are actually being used by real attackers, right now. If your environment has a CISA KEV vulnerability, it is your highest priority — regardless of CVSS score.

The CISA KEV catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Subscribe via API or RSS. Automate alerts when new KEVs match your environment.

EPSS (Exploit Prediction Scoring System)

EPSS is a machine learning model developed by FIRST (Forum of Incident Response and Security Teams) that predicts the probability that a CVE will be exploited in the next 30 days.

EPSS Score: 0.0–1.0 (probability of exploitation in 30 days)
EPSS Percentile: Where this CVE ranks among all CVEs

Example:
CVE-2024-12345: CVSS 8.5, EPSS 0.003 (0.3% — 45th percentile)
CVE-2024-67890: CVSS 6.9, EPSS 0.721 (72.1% — 97th percentile)

→ Despite lower CVSS, CVE-2024-67890 is the higher priority

EPSS scores are available via API: https://api.first.org/data/v1/epss?cve=CVE-2024-12345

Integrate EPSS into your vulnerability management tooling. Patch high-EPSS CVEs before high-CVSS-but-low-EPSS CVEs.

Exploit availability:

• PoC (Proof of Concept) publicly available on ExploitDB, GitHub, or Metasploit: significantly higher risk
• Exploit available in exploit frameworks (Metasploit, Cobalt Strike modules): very high risk
• No public exploit: lower exploitation probability

Vulnerability: Are You Actually Exposed?

CVSS base score assumes the worst-case environment. Adjust for your actual environment:

Exposure adjustment factors:

Example: CVE in Apache web server (CVSS 9.8, network-exploitable, no auth required)

• Scenario A: Running on internet-facing web server, no WAF = Critical priority
• Scenario B: Running on internal development server, no internet access = High priority
• Scenario C: Apache version is running but the vulnerable module is disabled = Low priority

Same CVE, three completely different priority levels based on actual exposure.

Asset Value: What Would Be Lost?

Not all systems are equal. A vulnerability in your customer payment database is more dangerous than the same vulnerability in your developer sandbox.

Asset classification system:

Apply an asset value multiplier to your risk score. A CVSS 7.0 vulnerability on a Crown Jewel asset scores higher than a CVSS 9.0 on a sandbox.

Building a Risk Score

Combine these factors into an operational risk score:

Simple Formula

Risk Score = CVSS × Exploitability Modifier × Exposure Modifier × Asset Value Modifier

Exploitability:
  CISA KEV: × 2.0 (immediate priority)
  EPSS > 50%: × 1.5
  Public exploit available: × 1.3
  EPSS < 10%, no public exploit: × 1.0

Exposure:
  Internet-facing, no compensating controls: × 1.5
  Internet-facing, WAF/network control present: × 1.2
  Internal, reachable from internet-facing systems: × 1.0
  Internal, isolated network: × 0.6
  Vulnerable component disabled: × 0.1

Asset Value:
  Crown Jewel: × 1.5
  Production: × 1.2
  Sensitive Internal: × 1.0
  Standard Internal: × 0.8
  Dev/Sandbox: × 0.5

Example:

CVE-2024-XXXX
CVSS: 7.5
CISA KEV: Yes → Exploitability × 2.0
Internet-facing, no WAF → Exposure × 1.5
Production database (Crown Jewel) → Asset × 1.5

Risk Score = 7.5 × 2.0 × 1.5 × 1.5 = 33.75 → P1, patch immediately

CVE-2024-YYYY
CVSS: 9.0
EPSS < 5%, no public exploit → × 1.0
Internal dev server, isolated → Exposure × 0.5
Dev environment → Asset × 0.5

Risk Score = 9.0 × 1.0 × 0.5 × 0.5 = 2.25 → P4, patch in next quarterly cycle

Commercial Risk Scoring

Modern vulnerability management platforms (Tenable VPR, Qualys Risk Score, Rapid7 Risk Score, Ivanti Risk-Based Vulnerability Management) implement similar logic automatically, incorporating:

• Threat intelligence feeds (exploitation in the wild)
• EPSS integration
• Asset context (criticality from CMDB)
• Environmental context (network exposure, existing compensating controls)

These platform scores are more sophisticated than manual calculation and are worth the investment for organisations with large, complex environments.

Risk Acceptance: When Not to Patch

Not every vulnerability needs to be patched. Formal risk acceptance is appropriate when:

• The vulnerability is in a system being decommissioned within 30 days
• Patching would require an outage during a critical business period with no maintenance window available
• The compensating controls reduce residual risk to acceptable levels
• The cost and complexity of patching significantly exceeds the expected value of risk reduction

Risk acceptance requirements:

• Formal documentation of the decision (which CVE, which asset, why)
• CISO (or equivalent) sign-off
• Time-limited (risk acceptance is not permanent — review quarterly)
• Compensating controls documented and verified
• Logged in your vulnerability management system as “accepted” not “resolved”

Do not use risk acceptance as an escape valve for operational convenience. It should be the exception, not the routine.

Integrating Risk Context Into Your Tools

SIEM Integration

Create alerts for critical risk combinations — not just individual CVEs — or leverage a managed SOC to handle this correlation automatically:

// Alert: CISA KEV detected on internet-facing asset
VulnerabilityFindings
| where CVEId in (external_kev_feed)  // CISA KEV CVEs
| join kind=inner AssetInventory on AssetId
| where InternetFacing == true
| where Severity != "Patched"
| project CVEId, AssetName, AssetTier, DiscoveryDate, EPSSScore
| order by DiscoveryDate asc

Ticketing Integration

When creating vulnerability tickets in JIRA/Linear:

• Tag with calculated risk score (not just CVSS)
• Set priority field based on risk score (not raw severity)
• Include asset tier, exposure factor, and exploitability data in the ticket description
• Set due date based on risk-tiered SLAs (see below)

SLA Adjustment for Risk-Based Prioritisation

Replace CVSS-based SLAs with risk-based SLAs:

Measuring Risk Reduction, Not Just Patch Count

Traditional vulnerability metrics measure activity:

• Vulnerabilities patched this month
• Patch SLA compliance rate
• Number of Critical open

These are useful but don’t directly measure whether you’ve reduced your actual risk. Add risk-oriented metrics:

Risk-oriented metrics:

Report these to leadership alongside SLA metrics. “We closed 80% of vulnerabilities this quarter” is less meaningful than “We reduced aggregate risk score by 35% this quarter, closing all CISA KEV vulnerabilities within 7 days.”

Practical 30-Day Quick Start

If you’re currently using CVSS-only prioritisation:

Week 1 — Add Threat Intelligence

• Subscribe to CISA KEV via API or RSS
• Configure automatic alerts when KEV CVEs match your environment
• Run all current open Critical/High CVEs through EPSS API — re-prioritise based on EPSS score

Week 2 — Add Asset Context

• Classify your top 50 assets by business criticality
• Re-score all vulnerabilities on critical assets
• Reprioritise remediation queue

Week 3 — Formalise

• Define your risk score formula (or configure it in your VM platform)
• Update SLAs to be risk-based rather than CVSS-based
• Communicate changes to engineering teams

Week 4 — Measure

• Calculate baseline aggregate risk score
• Define target risk score reduction for next quarter
• Report initial risk posture to leadership

Tools That Support Risk-Based Prioritisation

For organisations not yet on enterprise VM platforms, a spreadsheet with CVE data, EPSS API lookups, manual asset classification, and KEV matching can get 80% of the benefit with basic tooling.

CyberneticsPlus helps organisations build and mature risk-based vulnerability management programmes — from asset classification and risk scoring to tooling integration and reporting. We bring the offensive security perspective to prioritisation: we know which vulnerabilities attackers actually exploit. Contact us to improve your programme.

Building Your Vulnerability Management Programme from Scratch

Most organisations don’t transition from zero to a mature risk-based programme overnight. This section provides a realistic phased approach that moves from basic scanning to a fully mature, risk-contextualised vulnerability management programme.

Phase 1: Asset Inventory and Basic Scanning (Month 1–2)

You cannot manage what you cannot see. The first step is a complete, accurate asset inventory.

Build your asset inventory:

• Network discovery scan (Nmap, cloud provider asset APIs) to enumerate all hosts
• Cloud environment scan (AWS Config, Azure Resource Graph, GCP Asset Inventory) for cloud resources
• Software asset management (SCCM, Jamf, Intune MDM) for endpoint software
• Application inventory — every web application, API, and SaaS tool in use

Start scanning: Deploy a vulnerability scanner (Nessus, Qualys, Rapid7 InsightVM, Tenable.io) for:

• External attack surface (internet-facing hosts and services)
• Internal network (in-scope production hosts)
• Cloud resources (API-based scanning for misconfigurations)

Initial scans will generate a large finding volume — this is normal. Do not panic. Your goal at this phase is baseline, not immediate remediation.

Quick wins in Phase 1:

• Patch critical CISA KEV vulnerabilities immediately on any internet-facing host
• Fix any “low-hanging fruit” credential issues (default passwords, exposed admin interfaces)
• Confirm scanning coverage — every asset should appear in at least one scan

Phase 2: Risk Scoring Implementation (Month 2–3)

With scanning baseline established, layer in risk context:

Integrate CISA KEV:

• Subscribe to CISA KEV catalog via API or RSS
• Configure your VM platform to flag KEV matches in your environment
• Create an emergency SLA: any KEV vulnerability on any host must be triaged within 24 hours

Integrate EPSS:

• Pull EPSS scores via the FIRST API for all High/Critical CVEs in your environment
• Re-sort your remediation queue by EPSS score (not CVSS)
• Target EPSS > 50% CVEs with the same urgency as Critical-rated vulnerabilities

Implement asset classification:

• Define your asset tiers (Crown Jewel, Production, Internal, Dev — or equivalent)
• Classify your top 100 assets manually to start (refine with automation later)
• Apply asset tier multipliers to risk scores

Phase 3: Remediation Workflow (Month 3–4)

Risk scoring is useless without a reliable remediation workflow.

Integrate with your ticketing system: Configure your VM platform to automatically create tickets in JIRA, ServiceNow, or Linear for new High/Critical findings. Ticket fields should include:

• CVE identifier and description
• Affected asset (hostname, IP, cloud resource ID)
• Calculated risk score (not just CVSS)
• Remediation deadline (based on risk-tiered SLA)
• Link to patch/fix guidance

Assign ownership: Every ticket needs a named owner from the relevant engineering team. Create service accounts in your ticket system for each engineering team and auto-assign based on asset ownership.

Define exceptions process: Formally document your risk acceptance process — who can accept risk, what documentation is required, what the time limit is. Without a formal process, teams will informally accept risk without accountability.

Phase 4: Continuous Improvement (Month 4+)

Automate what can be automated:

• Auto-patching for Tier 4 (Dev/Sandbox) assets during off-hours — no change management required
• Auto-close tickets for CVEs that are fixed in subsequent scan cycles
• Auto-escalate tickets that breach SLA deadlines (alert security team lead)

Measure and report: Monthly metrics to leadership:

• Total risk score trend (is aggregate risk going up or down?)
• SLA compliance rate by team
• CISA KEV time-to-remediate
• Crown jewel vulnerability count

Annual penetration testing: Pair your continuous vulnerability scanning programme with annual penetration testing. The VA programme identifies known CVEs; the pentest validates exploitability, finds business logic issues, and tests attack chains that scanners cannot identify.

Vulnerability Management for Specific Environments

Cloud Infrastructure Vulnerability Management

Cloud vulnerability management has different requirements from traditional on-premises scanning:

What cloud VA covers that traditional scanners don’t:

• IAM misconfigurations (over-permissive roles, public access to resources)
• Storage exposure (public S3 buckets, publicly accessible databases)
• Network exposure (security groups allowing 0.0.0.0/0 on admin ports)
• Encryption gaps (unencrypted RDS instances, unencrypted EBS volumes)
• Logging gaps (CloudTrail disabled, VPC Flow Logs off)

Cloud-native tools:

• AWS Security Hub: Aggregates findings from GuardDuty, Inspector (for EC2/container vulnerability scanning), Config Rules
• AWS Inspector v2: Agentless EC2 scanning for OS and application CVEs, container image scanning in ECR
• Azure Defender for Cloud: Security posture score, CVE findings on VMs and containers, regulatory compliance dashboard
• GCP Security Command Centre: Security findings, IAM analyser, vulnerability scanning

Key cloud VM requirement: Immutable infrastructure (Lambda, containers, serverless) requires a different patching model — vulnerabilities are remediated by rebuilding and redeploying the artifact, not patching a running system. Your VM platform needs to support container image scanning (in the registry, before deployment) rather than scanning running instances.

Container and Kubernetes Vulnerability Management

Container environments introduce additional complexity:

Container image scanning: Every container image should be scanned before deployment to a registry and again before deployment to production:

• Registry scanning: Trivy, Snyk Container, Amazon ECR scanning, Azure Container Registry scanning
• CI/CD gate: Block image promotion if Critical CVEs are present (tune thresholds for your risk tolerance)
• Runtime scanning: Falco, Aqua Security, Sysdig for detecting CVE exploitation in running containers

Kubernetes cluster hardening:

• kube-bench: checks Kubernetes configuration against CIS Kubernetes Benchmark
• kube-hunter: simulates attacker perspective — what can be accessed from inside the cluster?
• kubevuln: CVE scanning for Kubernetes components (kubelet, API server, etcd versions)

Patch strategy for containers:

• Base image updates: rebuild on new base image releases (automate with Renovate, Dependabot)
• Application dependency updates: automated PRs for dependency updates with security patches
• Kubernetes version updates: stay within the N-2 supported version window (Kubernetes releases every 4 months)

Third-Party and Supply Chain Vulnerability Management

A growing proportion of critical vulnerabilities are in third-party dependencies, not your own code:

Software Composition Analysis (SCA):

• Track every open-source library in use (SBOM — Software Bill of Materials)
• Scan dependencies against vulnerability databases (NVD, OSV.dev, GitHub Advisory Database)
• Tools: Snyk Open Source, OWASP Dependency-Check, GitHub Dependabot, Renovate

SBOM generation: SBOM (Software Bill of Materials) — a formal, machine-readable inventory of all components in a software artifact — is increasingly required by enterprise customers and government contracts:

# Generate SBOM for a container image
syft my-app:latest -o spdx-json > sbom.json

# Scan SBOM for known vulnerabilities  
grype sbom:sbom.json

# Output: list of CVEs in image components with severity

Vendor patching SLAs: When a vendor you depend on (a SaaS tool, a managed service) discloses a vulnerability or breach, you need to:

1. Understand which of your data is affected
2. Confirm the vendor’s remediation timeline
3. Apply compensating controls if the timeline is too slow
4. Document the risk for compliance purposes

Frequently Asked Questions

Q: How many vulnerabilities should we expect to have open at any time?

A: There is no “normal” number — it depends entirely on environment size, technology diversity, and patching maturity. What matters more than the absolute count is the trend (is it decreasing?) and the composition (what proportion are Critical/High on internet-facing assets?). A mature programme with 10,000 endpoints may have 50,000 open findings but 0 CISA KEV vulnerabilities and all Critical/High findings on internet-facing assets remediated within SLA. That’s a healthy programme despite the headline number.

Q: How do we handle legacy systems that can’t be patched?

A: Legacy systems (end-of-life Windows Server, unsupported industrial control systems, medical devices) require compensating controls when patching is impossible:

1. Network isolation — segment them so they cannot reach or be reached from sensitive systems
2. Enhanced monitoring — prioritise monitoring of traffic to/from isolated legacy systems
3. Virtual patching — deploy WAF or IPS rules that block exploitation of known CVEs without modifying the system
4. Formal risk acceptance — document the residual risk, CISO sign-off, annual review
5. Decommission timeline — drive toward eliminating the legacy system, even if slowly

Q: Should we tell our engineers the CVSS score or the risk score?

A: Share the risk score — it’s more actionable. Engineers make better patch prioritisation decisions with “this vulnerability is on an internet-facing server, a working exploit exists, and it scores P1 in our risk model” than with “this is a CVSS 9.0.” That said, CVSS scores are part of the standard vulnerability language — include both, but make the risk score the primary driver of priority and SLA.

Q: How often should we scan?

A: Continuous scanning (daily) for internet-facing and critical internal assets. Weekly for other internal production systems. Triggered scans after any significant change (new system deployed, software updated). For cloud environments, continuous configuration scanning via CSPM tools. The goal is to detect new vulnerabilities within 24–48 hours of them appearing in your environment — whether from a new CVE publication or a new asset being deployed.

Q: What is vulnerability chaining and why does it matter?

A: Vulnerability chaining (or vulnerability stacking) is when an attacker combines multiple lower-severity vulnerabilities to achieve a higher-impact attack. Example: a CVSS 5.0 information disclosure CVE reveals internal infrastructure details, combined with a CVSS 6.5 authentication flaw, combined with a CVSS 7.0 privilege escalation — creates a critical attack chain. CVSS-based prioritisation misses these chains entirely. Periodic penetration testing is essential to identify attack chains that vulnerability scanners report as separate, lower-risk findings.

Q: How does vulnerability management relate to patch management?

A: Vulnerability management identifies what needs to be fixed; patch management is the process of actually deploying the fix. The two programmes must be integrated — vulnerability management outputs (prioritised CVE list) feed directly into patch management workflows (which systems get patched in what order in the next change window). Without integration, vulnerability management produces reports that engineering teams ignore, and patch management runs on schedules that don’t reflect actual risk.

Q: What is the difference between a vulnerability assessment and a penetration test for vulnerability management purposes?

A: Vulnerability assessments are the continuous, automated scanning engine of your VM programme — they run frequently and identify known CVEs across all assets. Penetration tests are periodic, manual validation of exploitability — they confirm which of your scanner-identified vulnerabilities are actually exploitable in your specific environment, and they find attack chains and logic flaws that scanners miss. Use both: VA for continuous hygiene, penetration testing for periodic deep validation.