Building a Vulnerability Management Program

Executive Summary

Most organisations scan for vulnerabilities. Few have a programme that systematically reduces risk over time.

The gap between “we run scans” and “we have a vulnerability management programme” is significant. A vulnerability scan produces a list of findings. A programme produces risk reduction — measured, tracked, and reported to leadership.

This whitepaper provides a practical framework for building a vulnerability management (VM) programme from scratch, or for maturing an existing one. The approach is risk-based: not all vulnerabilities are equal, and the goal is not to achieve zero vulnerabilities (impossible) but to reduce exposure to the vulnerabilities that matter most given your environment and threat landscape.

Chapter 1: Foundations

What Vulnerability Management Is

Vulnerability management is the continuous process of:

1. Identifying vulnerabilities across your asset inventory
2. Assessing their risk in the context of your environment
3. Prioritising remediation based on risk
4. Remediating or mitigating vulnerabilities within defined SLAs
5. Verifying remediation effectiveness
6. Reporting on programme performance

What Vulnerability Management Is Not

• Not a one-time project. New vulnerabilities are disclosed every day (NIST NVD receives 50–100 new CVEs daily). VM is a continuous operational function.
• Not the same as patching. Patching is one remediation technique. VM includes compensating controls, configuration changes, and risk acceptance as additional responses.
• Not a ticket queue. Without risk-based prioritisation, VM becomes an endless queue of findings with no strategic direction.

The Business Case

Vulnerability management reduces:

• Breach probability: Most successful attacks exploit known vulnerabilities. The 2024 Verizon DBIR found that 14% of breaches exploited vulnerabilities, with the majority targeting known, patchable CVEs.
• Breach cost: Organisations with mature VM programmes recover faster and sustain lower damage costs.
• Compliance gaps: PCI DSS, ISO 27001, HIPAA, and most major frameworks mandate vulnerability management.
• Cyber insurance costs: Insurers ask about scanning frequency and SLA compliance. Mature programmes command better premiums.

Chapter 2: Asset Inventory — The Foundation

You cannot manage vulnerabilities on assets you do not know exist.

Building the Asset Inventory

A vulnerability management programme is only as good as its asset inventory. Asset discovery must be:

• Complete: All assets, including forgotten systems, cloud instances, and network devices
• Accurate: Current information — decommissioned assets removed, new assets added
• Contextual: Assets classified by criticality, function, and data classification

Asset Discovery Methods

Recommendation: Use at least three discovery methods. In every engagement, CyberneticsPlus discovers 5–15% more assets than the client believed existed.

Asset Classification

Classify assets to drive risk-based prioritisation:

Tier assignment drives remediation SLAs — a critical vulnerability on T1 is treated very differently than the same vulnerability on T4.

Chapter 3: Vulnerability Scanning

Scanning Approach

Authenticated scanning provides dramatically better results than unauthenticated scanning:

• Unauthenticated scans see only what an external attacker can see: open ports, banner information, externally detectable vulnerabilities
• Authenticated scans can enumerate installed software versions, registry settings, OS patch levels, and local configuration — catching far more vulnerabilities

Scan types:

Scan Frequency

Tooling

For mid-market organisations (200–2,000 endpoints), Tenable.io or Qualys VMDR are the most common choices. For smaller organisations or those already in the Microsoft ecosystem, Microsoft Defender Vulnerability Management (included with MDE Plan 2) is cost-effective.

Chapter 4: Risk-Based Prioritisation

Running a scan produces findings. Prioritisation decides what to fix first.

Why CVSS Alone Is Insufficient

CVSS (Common Vulnerability Scoring System) scores severity based on the vulnerability’s characteristics — not your environment. A Critical CVSS score does not mean the vulnerability is critical for you.

Problems with CVSS-only prioritisation:

• A CVSS 10.0 vulnerability on a test machine with no network access is lower risk than a CVSS 7.5 vulnerability on an internet-facing payment server
• CVSS does not account for whether the vulnerability is being actively exploited in the wild
• CVSS scores assume worst-case exploitation conditions

Risk-Based Prioritisation Framework

Combine three factors:

Factor 1: Vulnerability Severity (CVSS) Baseline severity of the vulnerability if exploited.

Factor 2: Exploitation Likelihood (EPSS) EPSS (Exploit Prediction Scoring System) provides a probability (0–100%) that a CVE will be exploited in the next 30 days, based on threat intelligence and machine learning analysis of real attack patterns.

• EPSS > 10%: high probability of exploitation — treat urgently
• EPSS < 1% with CVSS 9.0: technically severe but unlikely to be weaponised in your timeframe

Factor 3: Asset Criticality Your tier classification of the asset. The same vulnerability on a T1 system vs a T4 system warrants different response SLAs.

Risk Priority Matrix:

CISA Known Exploited Vulnerabilities (KEV)

CISA maintains a catalogue of vulnerabilities known to be exploited by real threat actors. Any CVE in the KEV catalogue should jump to the top of your queue regardless of CVSS score, because exploitation is confirmed — not theoretical.

Integrate KEV into your VM platform: most enterprise scanners (Tenable, Qualys, Rapid7) support KEV tagging.

Chapter 5: Remediation Workflows

Remediation Options

Patching is not always possible or immediate. The VM programme must support multiple remediation paths:

Remediation SLAs

SLAs must be written into policy and tracked — without accountability, they are aspirational, not operational.

Patch Management Integration

VM and patch management must be integrated, not siloed. The VM programme identifies what needs patching; the patch management process executes it.

Deployment rings for patching:

1. Ring 0 (pilot): IT admin machines — 3–5 days after release
2. Ring 1 (early adopters): Non-critical business users — 7–10 days after Ring 0 validation
3. Ring 2 (general): Broad production deployment — after Ring 1 validation
4. Ring 3 (critical/legacy): Business-critical or sensitive systems — manual review and maintenance window

Chapter 6: Remediation Verification

A vulnerability is not closed until remediation is verified.

Verification Methods

• Rescan: Run a targeted scan of the specific asset after remediation. Confirm the CVE is no longer detected.
• Agent check-in: For agent-based deployments, confirm the agent has re-assessed and cleared the finding
• Manual verification: For configuration-based findings, manual review of the configuration state
• Penetration test: For high-risk findings, a targeted exploitation attempt to confirm the vulnerability is no longer exploitable

Never close a vulnerability ticket based solely on the claim “it’s patched.” Verify.

Chapter 7: Metrics and Reporting

Key VM Programme Metrics

Volume metrics (current state):

• Total open vulnerabilities by severity (Critical, High, Medium, Low)
• Vulnerability count by asset tier
• Mean Time to Detect (MTTD): average time from vulnerability disclosure to discovery in your environment
• Mean Time to Remediate (MTTR) by severity

Performance metrics (programme effectiveness):

• SLA compliance rate: % of vulnerabilities remediated within SLA by severity
• Patch compliance rate: % of assets with no Critical/High vulnerabilities outstanding beyond SLA
• Recurring vulnerabilities: % of closed findings that reopen (indicates remediation quality)
• Coverage rate: % of known assets with a scan in the last 30 days

Trend metrics (direction of travel):

• Week-over-week or month-over-month change in Critical and High vulnerability count
• Reduction in exposure to actively exploited CVEs (KEV coverage)
• MTTR trend over time

Reporting Cadence

Sample Executive Metric: Exposure Score

An intuitive metric for leadership: Critical Exposure Days = sum of (days each Critical vulnerability has been open × asset tier weight).

This single number captures both volume and dwell time, and trends down as the programme matures.

Chapter 8: Special Topics

Cloud Vulnerability Management

Cloud introduces dynamic assets that traditional scanners miss:

• CSPM (Cloud Security Posture Management): Continuously monitors cloud configurations for misconfigurations. Tools: Wiz, Orca, AWS Security Hub, Azure Defender, GCP SCC.
• Cloud-native scanning: AWS Inspector, Azure Defender for Servers, GCP Security Command Center integrate with cloud APIs for native vulnerability detection
• Ephemeral assets: Auto-scaling groups, serverless functions, and containers spin up and down. Agents don’t work — use agentless cloud scanning or image-based scanning

Container and CI/CD Vulnerability Management

The shift left imperative: find vulnerabilities in images before they reach production.

Container image scanning in CI/CD:

# Example: GitHub Actions with Trivy
- name: Scan container image
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: 'myapp:latest'
    exit-code: '1'  # Fail the build on Critical findings
    severity: 'CRITICAL,HIGH'

Policy: Block deployment of images with Critical CVEs unless an exemption is approved. This is the most effective way to prevent known vulnerable software from reaching production.

OT/IoT Vulnerability Management

Operational technology (SCADA, ICS) and IoT devices present challenges:

• Many OT devices cannot be scanned aggressively — probing can cause device crashes or control system disruptions
• Patches may not be available (end-of-support hardware) or require vendor involvement
• Scanning must be performed in a maintenance window with system owner approval

Alternative approach for OT:

• Passive network monitoring (Claroty, Dragos, Nozomi Networks) — identifies vulnerabilities by observing network traffic without active probing
• Asset inventory via network tap or span port rather than active scanning

Chapter 9: Programme Governance

A VM programme without governance degrades over time.

Policy Requirements

Document the following in policy:

• Scope: what assets are in scope for VM
• Scanning frequency by asset type
• Remediation SLAs by priority
• Risk acceptance process (who can approve, for how long)
• Escalation path for SLA violations
• Exceptions process

Roles and Responsibilities

Programme Maturity Model

Most organisations are at Level 1 or 2. Reaching Level 3 is the primary goal for most VM programme implementations.

Conclusion

A vulnerability management programme is not built in a day, but it can deliver meaningful risk reduction within 90 days of inception. The key is to start with a complete asset inventory, establish a risk-based prioritisation framework, and track remediation performance against defined SLAs.

The measure of a VM programme’s success is not the number of vulnerabilities scanned — it is the reduction in critical exposure time over time.

CyberneticsPlus builds and operationalises vulnerability management programmes for organisations across regulated industries. Our engagements include asset discovery, scanner deployment, SLA definition, and a 90-day programme handover with metrics dashboards and reporting templates. Contact us to discuss your VM programme requirements.