Phase 1: Foundations — get the inventory right
Vulnerability management is impossible without an authoritative asset inventory. The first 30 days of the program should produce a single source of truth that lists every host, every container, every cloud workload, every SaaS app, every code repository, and the team that owns each. CAASM tools accelerate this; for smaller orgs a well-maintained spreadsheet works.
Tag every asset with: business criticality (tier-0 through tier-3), data sensitivity, internet exposure, owning team, and expected patch window. These tags drive every downstream prioritization decision.
Phase 2: Scanning — coverage before depth
Deploy scanners across the four layers: external (EASM), authenticated network (Nessus, Qualys, Rapid7), endpoint (most EDRs now do CVE matching), and code (SCA + container image scanning). Aim for breadth before depth — a 70% coverage scan running weekly delivers more value than a 95% coverage scan running quarterly.
Cloud workloads deserve special attention. Use agentless snapshot scanning (Wiz, Orca, Lacework) to avoid the operational tax of agents on ephemeral infrastructure, and combine with runtime scanning where workloads are long-lived. See our CNAPP vs. CSPM vs. CWPP breakdown for how those scanners overlap.
Phase 3: Prioritization — beyond CVSS
CVSS alone is a poor prioritization signal. By 2026 the consensus is to combine three signals: EPSS (Exploit Prediction Scoring System) for exploitation probability, CISA KEV (Known Exploited Vulnerabilities) catalog for confirmed in-the-wild exploitation, and your own asset criticality tag. A tier-0 internet-facing host with a KEV-listed CVE is a same-day fix; a tier-3 internal host with a CVSS 9.8 that has zero EPSS is a quarterly fix.
Modern vulnerability prioritization platforms (Vulcan, Nucleus, Tenable Cloud Security, Rapid7 ExposureCommand) automate this combination, but a homegrown scoring formula in a notebook works fine for smaller programs.
Phase 4: Remediation — SLAs and ownership
Every finding must have a named owner and an SLA based on its prioritization tier. Typical mid-market SLAs:
- P0 (KEV + internet-exposed + tier-0): 72 hours
- P1 (KEV or high EPSS + critical asset): 7 days
- P2 (high CVSS, low EPSS): 30 days
- P3 (medium CVSS, low EPSS): 90 days
- P4 (low CVSS): best-effort, batch with regular maintenance
Push tickets directly into the owning team's existing tool (Jira, Linear, GitHub Issues) rather than a separate vulnerability queue. Friction kills programs; meet developers where they work.
Phase 5: Verification and measurement
Re-scan after remediation closes and verify the finding is actually gone — not just suppressed. Track program health with: mean time to remediate by severity, percentage of SLA breaches by team, percentage of total vulnerabilities introduced vs. closed each week (the "vulnerability debt" curve), and percentage of internet-exposed assets with no known critical vulnerabilities. Cross-reference these numbers against your security tooling stack to find where coverage gaps live.
Phase 6: Maturity — shift left and exception management
A mature program prevents most vulnerabilities from reaching production. Integrate SCA into pull requests, container scanning into the registry, IaC scanning into PRs, and pre-deployment gates that block known-bad images. Pair this with a formal exception process for the genuine cases where a vulnerability cannot be patched in SLA — documented compensating controls, time-bound, signed off by the asset owner.
Tooling landscape in 2026
- Network scanning: Tenable, Qualys, Rapid7
- Cloud + container: Wiz, Orca, Tenable Cloud Security, Sysdig
- Code / SCA: Snyk, Mend, Checkmarx, Semgrep
- Prioritization layer: Vulcan, Nucleus, Phoenix Security
- External / EASM: Bitsight, CyCognito, Censys, runZero
- Open-source: OpenVAS / Greenbone, Trivy, OWASP Dependency-Track