Vulnerability management lifecycle

Vulnerability management lifecycle

TL;DR: Vulnerability management (VM) is the continuous program that discovers assets, scans them, prioritises findings, drives remediation, verifies fixes, and reports trends. It is unglamorous and operational, and 90% of organisations do it badly because they confuse “we run a scanner” with “we manage vulnerabilities.” The hard parts are not the scanner — they are asset coverage, ownership, SLA enforcement, and the human politics of patching. Companion to cvss-epss-kev-prioritisation, vuln-exception-management, patch-management-program, and asset-management-easm-cmdb.

Why it matters

Every framework you will ever audit against — pci-dss-4-implementation, ISO 27001, SOC 2, HIPAA, NIS2 — requires “a vulnerability management program.” Auditors will accept thin evidence (a Nessus screenshot, a Jira ticket), but real attackers do not. The gap between “we have VM” and “we actually reduce exposure” is where ransomware affiliates (ransomware-affiliate-playbook) and initial-access brokers live. Most breach post-mortems — case-study-equifax-2017, case-study-moveit-2023 — trace back to a known CVE that VM should have caught but didn’t, because the asset wasn’t scanned, the ticket wasn’t owned, or the SLA wasn’t enforced.

VM is also the program most likely to get a security team fired for over-promising. “We have full coverage” is almost always a lie. Be honest with leadership about what you can and cannot see.

The six phases (and where each one fails)

1. Discover / inventory

You can only manage what you can see. This is the phase everyone skips and then wonders why breaches happen on the box no one knew existed.

  • Sources: CMDB, cloud provider APIs (AWS Config, Azure Resource Graph, GCP Asset Inventory), DHCP logs, EDR agent inventory, AD/Entra, network discovery scans, EASM (external attack surface management) tools.
  • Failure mode: treating the CMDB as ground truth. CMDBs are aspirational documents maintained by IT, not security. Reconcile against multiple sources.
  • See asset-management-easm-cmdb for the deep dive.

2. Assess / scan

Run scanners. This is the part vendors sell you.

  • Network scanners: Nessus (Tenable), Qualys VMDR, Rapid7 InsightVM. Authenticated scans (credentials) find 5-10x more than unauthenticated.
  • Web app scanners (DAST): Burp Suite Enterprise, Acunetix, Invicti (formerly Netsparker). See sast-dast-ci-integration.
  • Container scanners: Trivy, Snyk, Anchore, Grype. Scan images in registry and at runtime.
  • Cloud posture (CSPM): Wiz, Prisma Cloud, Orca, AWS Security Hub. See cloud-iam-misconfig-patterns.
  • SAST / SCA: Semgrep, SonarQube, Snyk Code, Dependabot for source-level findings.

3. Prioritise

Scanners produce noise. A fresh Nessus scan of a mid-size enterprise returns tens of thousands of findings. You cannot fix them all.

  • Use cvss-scoring-practitioner as a baseline, then layer EPSS (exploit prediction) and CISA KEV (known exploited). See cvss-epss-kev-prioritisation.
  • Add business context: internet-exposed? processes cardholder data? domain controller?
  • Output a small, ranked list — not a 40-page PDF nobody reads.

4. Remediate

The phase where security stops and IT/engineering starts. This is where programs die.

5. Verify

Re-scan and confirm closure. Never close a ticket on “engineer said it’s patched.”

  • Tag verified-fixed vs. self-attested. Auditors will ask.
  • Watch for regressions — a finding closed in March that reappears in April means image rebuild or config drift.

6. Report

Trend lines, not point-in-time counts.

  • Metrics that matter: mean-time-to-remediate (MTTR) by severity, % SLA compliance, % assets scanned in last 30 days, KEV exposure window, exception count and aging.
  • Metrics that lie: total open vulns (gameable by closing low-severity noise), “critical reduction %” without coverage denominator.

Scanner classes and tradeoffs

Agent vs. agentless

Aspect Agent Agentless
Coverage Whatever has the agent installed Whatever you can reach on the network
Authenticated data Always (agent runs locally) Requires credential vaulting
Ephemeral workloads Hard (must bake into image) Easier (snapshot scanning)
OT / appliances Impossible Often only option
Performance impact Real but small Network noise during scan windows
Stealth from attackers Visible process Visible network traffic

Most mature programs run both. Agents (EDR + scanner agent like Qualys Cloud Agent) for endpoints and servers; agentless for OT, appliances, and cloud snapshot scanning (Wiz, Orca).

Continuous vs. periodic

  • Periodic (quarterly/monthly): the old PCI model. Cheap, low operational load, useless against fast-moving threats.
  • Continuous: cloud-native scanners and EDR-integrated agents that re-evaluate on every change. PCI DSS 4.0 (see pci-dss-4-implementation) is nudging this direction.
  • Reality check: “continuous” often means “scanner runs daily and dashboard updates” — not real-time. Ask the vendor how often their detection logic itself updates.

Defensive baseline (a VM program that actually works)

  1. Define scope in writing. “All production systems” is not scope. List environments, cloud accounts, IP ranges, repos, container registries. Get the CISO to sign it.
  2. Name an owner per asset class. Workstations → IT. Servers → platform team. Apps → engineering. Cloud → platform/SRE. K8s → DevOps. No owner = no remediation.
  3. Publish an SLA table (see below) and get exec sign-off.
  4. Integrate with ticketing. Auto-create Jira/ServiceNow tickets at a defined severity threshold. Tickets must have asset, finding, SLA clock, and owner. Manual ticket creation does not scale.
  5. Track exceptions like first-class objects. See vuln-exception-management. Every exception has an owner, expiry, compensating control, and review date.
  6. Re-scan to verify. Closure without re-scan is not closure.
  7. Report monthly to leadership with trend lines. Use the same metrics every month so trends are visible.

SLA framework (example, tune to your risk appetite)

Severity (CVSS / KEV / EPSS context) Internet-facing Internal Workstation
Critical + KEV-listed 7 days 14 days 14 days
Critical (CVSS 9.0+) 14 days 30 days 30 days
High (CVSS 7.0-8.9) 30 days 60 days 60 days
Medium 90 days 90 days 90 days
Low Best effort Best effort Best effort

These numbers are negotiable; what is non-negotiable is having them, enforcing them, and reporting breaches.

Common organisational failure modes

  • No scope. Program “covers everything” → covers nothing. First finding in an un-owned environment becomes a political fight.
  • No owner. Findings pile up in a security queue that engineering ignores. Security ends up patching servers it doesn’t own.
  • No SLA enforcement. SLAs exist on paper but nothing happens when breached. After three quarters of this, engineering knows the SLA is theatre.
  • Scanner fatigue. Security floods Jira with 10,000 medium findings. Engineering filter-bans the security label. Real criticals get lost.
  • Confusing VM with patch management. VM finds and tracks; patch-management-program actually applies the fix. They are different teams in most orgs and must talk.
  • Ignoring exceptions. Exceptions accumulate forever, become permanent, and re-emerge as audit findings or breaches.
  • Vendor-led metrics. Letting the scanner vendor define “success” via their dashboard. Their dashboard is a sales tool.

How VM interacts with adjacent programs

Vendor marketing vs. reality

  • “Continuous” usually means “daily scan + dashboard.” Real continuous is rare.
  • “AI-powered prioritisation” usually means CVSS + EPSS + KEV with a UI on top. Build your own with the same inputs and a spreadsheet.
  • “Single pane of glass” requires expensive integrations and rarely covers OT or legacy.
  • “Zero false positives” is a lie. Authenticated scans have fewer false positives but never zero.
  • Per-asset pricing punishes growth. Negotiate hard, or expect your VM cost to balloon as you scale to cloud.

Workflow to study

  1. Pick a scope (one cloud account, one app, one office network). Inventory it three ways and reconcile.
  2. Run an authenticated scan with one tool (Nessus Essentials is free for 16 IPs). Review every critical and high by hand.
  3. Apply the cvss-epss-kev-prioritisation filter. How many “criticals” survive as truly urgent?
  4. Write tickets in Jira with owner, SLA clock, and re-scan trigger.
  5. Track MTTR for one quarter. Publish the trend to your manager.
  6. Add an exception process. Document one real exception end-to-end.
  7. Compare what your scanner reports against what an attacker would find externally — try an EASM trial or run Shodan/Censys against your perimeter.

Realistic effort and who succeeds

  • A real VM program with one scanner, basic CMDB, Jira integration, and SLA enforcement takes 6-12 months to stand up in a mid-size company and ongoing 1-2 FTE to run.
  • Programs that succeed have an executive sponsor (CISO or CIO) who enforces SLAs and an embedded relationship with IT/engineering owners.
  • Programs that fail are security-only initiatives with no operational partners, run by an analyst with no political cover.
  • Career path: VM analyst → VM lead → security operations manager → ciso-vciso-track. Also feeds grc-analyst-career-track and security-auditor-career-track.

References

  • https://csrc.nist.gov/publications/detail/sp/800-40/rev-4/final — NIST SP 800-40 Rev 4 (Guide to Enterprise Patch Management Planning)
  • https://www.cisa.gov/known-exploited-vulnerabilities-catalog — CISA KEV catalog
  • https://www.first.org/epss/ — EPSS model and API
  • https://www.sans.org/white-papers/implementing-vulnerability-management-process/ — SANS practitioner reading on VM process
  • https://owasp.org/www-community/Vulnerability_Management_Guide — OWASP VM Guide
  • https://www.gartner.com/en/documents/market-guide-for-vulnerability-assessment — Gartner Market Guide for Vulnerability Assessment (paywalled, but the abstract is useful for vendor landscape)