August 20, 2026
Updated: November 6, 2026
A continuous program, not a scan: how to find, rank, fix, and verify the exposures that actually carry risk.
Abdalla Mohamed
Vulnerability management is the continuous, cyclical process of identifying, prioritizing, remediating, and verifying security weaknesses across your systems, so the flaws most likely to be exploited get fixed before an attacker finds them. It is not a one-time scan or an annual audit; it is an ongoing program that never really ends, because new vulnerabilities appear every day. With more than 48,000 CVE records published in 2025, up from roughly 40,000 in 2024, no team can fix everything, which makes the real skill knowing what to fix first. This guide covers the full lifecycle, risk-based prioritization, how vulnerability management differs from exposure management, how to run it in the cloud, and how to measure a program that works.
For prioritization, see EPSS vs CVSS.
Updated: November 2026. Adds cloud vulnerability management (container images, infrastructure as code, CSPM findings, ephemeral assets, and the shared-responsibility split), vulnerability risk management, and how vulnerability management compares with exposure management. Reflects record 2025 CVE volumes, the NVD enrichment backlog, EPSS and the CISA KEV catalog for prioritization, Gartner's CTEM model, and CISA's 2026 move (BOD 26-04) to risk-scored remediation deadlines.
Vulnerability management is a documented, repeatable program for continuously discovering weaknesses in your environment, deciding which ones matter, fixing or mitigating them, and confirming the fix worked. The weaknesses include far more than missing patches: misconfigurations, weak credentials, exposed services, insecure defaults, and outdated software all qualify.
It helps to place it next to two things people confuse it with:
The defining word for vulnerability management is continuous. A scan tells you where you stood on Tuesday; a program keeps you informed and improving week after week.
The scale of the problem has changed. More than 48,000 CVE records were published in 2025, up from roughly 40,000 in 2024, an increase of about 20 percent (CVE.org published-record metrics, checked November 2026), which works out to more than 130 new vulnerabilities disclosed every day. On top of the raw volume, the US National Vulnerability Database (NVD) developed a significant backlog of un-enriched CVEs starting in early 2024, meaning the authoritative source many teams relied on for context could no longer keep pace.
Two conclusions follow, and they shape everything below. First, you cannot patch everything, so a program that treats every vulnerability as equally urgent will drown. Second, severity alone is a poor guide to risk, because only a small fraction of vulnerabilities are ever actually exploited. The organizations that stay secure are the ones that reliably find and fix the few that matter, fast. Our vulnerability statistics roundup puts the numbers behind that reality.
A mature program extends beyond software CVEs. It can include:
Most mature programs run some version of the same repeating cycle. The names vary; the work does not.
You cannot secure what you do not know you have. The cycle starts with a current inventory of assets, servers, endpoints, cloud workloads, applications, containers, and the growing sprawl of internet-facing services. Shadow IT and forgotten cloud instances are where breaches love to start, so discovery is continuous, not a one-time list.
Next, scan those assets for known vulnerabilities and misconfigurations using automated tools, authenticated where possible for accuracy. Scanning covers infrastructure, web applications, cloud, and containers. This is the step that produces the raw findings, and on its own it is a firehose: a mid-sized environment can surface tens of thousands of findings.
This is the stage that separates effective programs from busywork, and it gets its own section below. The goal is to rank the flood of findings so the team spends its limited time on the vulnerabilities that pose real risk to your specific environment.
Fix what matters, in priority order. Remediation usually means patching, but it can also mean reconfiguring, applying a compensating control, isolating a system, or accepting the risk with sign-off when a fix is not feasible. Clear ownership matters here: every priority finding needs a named owner and a deadline.
Prioritization should lead to an explicit treatment decision rather than a ticket that sits open indefinitely.
| Decision | Use when | Example |
|---|---|---|
| Remediate | A practical fix is available and should be applied | Patch a vulnerable library or update a misconfigured service |
| Mitigate | A full fix is unavailable or too disruptive in the short term | Segment the host, disable the feature, or add compensating controls |
| Accept | Residual risk is below tolerance and is formally approved | Keep a low-risk issue on an isolated test asset with documented sign-off |
| Remove | The asset or service no longer provides enough business value to justify the exposure | Retire a legacy internet-facing server |
Confirm the fix actually worked. Re-scan or re-test to make sure the vulnerability is genuinely closed and that the change did not introduce a new problem. A finding is not resolved because a ticket was closed; it is resolved when verification proves it.
Report on progress against goals, track trends, and feed lessons back into the program. Then the cycle repeats, because the environment and the threat landscape both keep changing. Reporting is also where you demonstrate the program's value to leadership and auditors.
For years, teams prioritized by CVSS score alone, fixing the "criticals" and "highs" first. That approach is now understood to be badly flawed, because CVSS measures a vulnerability's theoretical severity in isolation, not the likelihood that it will actually be exploited or the importance of the asset it sits on.
Modern prioritization layers several signals together:
| Signal | What it tells you | Source |
|---|---|---|
| CVSS | Theoretical technical severity of the flaw | FIRST (CVSS v4.0) |
| EPSS | Probability the flaw will be exploited in the near term | FIRST (Exploit Prediction Scoring System) |
| CISA KEV | Whether the flaw is actively being exploited right now | CISA Known Exploited Vulnerabilities catalog |
| Asset context | How critical and how exposed the affected asset is | Your asset inventory |
The combination is powerful. A high-CVSS vulnerability with a near-zero EPSS score on an isolated internal test box is rarely urgent. A medium-CVSS vulnerability that appears on the CISA KEV catalog, meaning attackers are exploiting it in the wild, on an internet-facing production system, is a drop-everything emergency. Prioritizing by exploitability and business context, not raw severity, is the single highest-leverage change most programs can make. This is exactly the discipline behind risk-based vulnerability management (RBVM), and it aligns closely with broader IT risk management practices that assess vulnerabilities in the context of business impact and acceptable exposure.
Vulnerability risk management is the practice of treating each vulnerability as a business risk rather than a severity score. The term is often used interchangeably with risk-based vulnerability management (RBVM). The question changes from "how severe is this flaw?" to "how likely is it to be exploited here, and what would it cost us if it were?" In practice, that means combining two sets of inputs:
The output is a risk tier that sets the remediation deadline, plus an explicit treatment decision using the remediate, mitigate, accept, or remove options above. Vulnerability risk management also makes risk acceptance auditable: when the business chooses not to fix something, the record shows the risk it accepted, who approved it, and when the decision expires.
Vulnerability management finds and fixes weaknesses, mostly known CVEs and misconfigurations, on assets you already know about. Exposure management asks a broader question: what are all the ways an attacker could reach something valuable? It also covers unknown internet-facing assets, identity and permission paths, SaaS settings, third-party connections, and combinations of small issues that only become dangerous together.
| Dimension | Vulnerability management | Exposure management |
|---|---|---|
| Starting point | Assets already in the inventory | Business services and what an attacker could reach |
| What counts | CVEs and misconfigurations found by scanners | Any exploitable condition: vulnerabilities, misconfigurations, identity paths, exposed data, unknown assets |
| Prioritization | Severity plus exploit signals (CVSS, EPSS, KEV) | Attack paths to critical assets, validated where possible |
| Success measure | Findings closed within SLA | Fewer validated paths to what matters |
Exposure management does not replace vulnerability management; it contains it. Scanning, patching, and SLAs remain the engine, while exposure management adds attack surface discovery, attack-path context, and validation around them. Gartner's continuous threat exposure management (CTEM) is the best-known program model for running exposure management; the next section summarizes it and points to our full guide.
Continuous Threat Exposure Management (CTEM) is a framework Gartner introduced in 2022 for running exposure management as a repeating five-stage cycle: scoping, discovery, prioritization, validation, and mobilization. For a vulnerability management team, three things change. The scope widens from known software vulnerabilities to the whole attack surface, including misconfigurations, identity and access risks, exposed APIs, and emerging AI exposures. Each cycle starts from the business services that matter most. And prioritized exposures are tested before remediation is mobilized across teams.
The stage that most often gets skipped is validation, and it is the one that changes everything. A scanner says a vulnerability exists; validation proves whether it is actually reachable and exploitable in your environment, which is the difference between a theoretical finding and a real risk. This is where penetration testing fits directly into a vulnerability management program: it validates that the exposures you prioritized can, or cannot, be exploited, so remediation effort goes where it counts. Our penetration testing methodology guide explains how that validation is scoped and run.
For a stage-by-stage walkthrough, see our guide to continuous threat exposure management.
Fixing fast is as important as fixing the right thing. Programs set remediation SLAs by priority, for example, critical exploited vulnerabilities within days, high within weeks, and lower-risk findings on a longer cadence tied to normal patch cycles. Tie the tightest SLAs to the KEV-and-EPSS signals above, not to CVSS alone.
The regulatory baseline is instructive. CISA's KEV catalog was long paired with fixed federal deadlines under Binding Operational Directive 22-01. In June 2026, CISA replaced that flat model with BOD 26-04, which scores each vulnerability against multiple risk criteria and can demand remediation in as little as three days when a flaw is severe, exploited, and exposed. The direction of travel is clear: deadlines are getting tighter and more risk-driven, and private-sector programs are adopting the same logic. Effective patch management is the engine that makes those SLAs achievable.
Not every vulnerability can be fixed immediately. When a team accepts risk or grants an exception, the decision should be time-bounded and auditable rather than permanent by default.
A good exception record includes:
Exceptions should expire automatically unless they are reviewed and renewed. That prevents temporary workarounds from becoming permanent blind spots.
A program needs tooling, but tools do not make a program. The core categories are:
What turns those tools into a program is the human structure around them: defined ownership, agreed SLAs, executive sponsorship, and a repeatable cycle. A pile of scan results with nobody accountable for fixing them is not vulnerability management; it is a liability with a dashboard.
Ownership is shared, but accountability should be explicit.
| Activity | Security | IT / Operations | Application Owner | Risk / Governance |
|---|---|---|---|---|
| Asset discovery | R | C | C | I |
| Prioritization | R | C | C | A |
| Remediation | C | R | R | I |
| Risk acceptance | C | C | C | A |
| Verification | R | C | C | I |
| Reporting | R | C | C | A |
R = Responsible, A = Accountable, C = Consulted, I = Informed.
Measure the program the way you would any operational capability. The metrics that matter most:
Trend these over time. A healthy program shows falling MTTR, high SLA compliance, and near-zero long-lived KEV exposure.
Scan frequency should match how fast your environment and the threat landscape change, which is to say: more often than most teams do. Continuous or near-continuous scanning is the modern standard, because a monthly scan leaves you blind to three-and-a-half weeks of newly disclosed vulnerabilities. Practical guidance:
Compliance minimums, such as quarterly scans, are floors, not targets. The gap between "we scanned last quarter" and "we know our exposure today" is exactly where attackers operate.
Cloud vulnerability management applies the same lifecycle to infrastructure you rent rather than own: discover what is running, find weaknesses, prioritize them by real risk, fix them, and verify the fix. What changes is the shape of the problem. Cloud assets are created through APIs and code, many of them live for minutes or hours, and a large share of the risk sits in configuration and identity settings that never receive a CVE number. A scanning schedule built for a static data center misses most of that.
Five areas need deliberate handling: the shared-responsibility split, container images, infrastructure as code, CSPM findings, and ephemeral assets. The diagram below shows where each kind of finding appears, from code to runtime, and where it should be fixed.
Every major cloud provider publishes a shared responsibility model. AWS describes it as security "of" the cloud, meaning the hardware, software, networking, and facilities it runs, versus security "in" the cloud, meaning what the customer builds and configures. For patching specifically, the AWS Shared Responsibility Model states that AWS fixes flaws in its infrastructure while customers patch their guest operating systems and applications. Microsoft's shared responsibility guidance adds that, whatever the service model, customers always keep responsibility for their data, endpoints, accounts, and access management.
For a vulnerability management program, that split decides who owns each finding:
| Layer | IaaS (virtual machines) | PaaS and managed containers | SaaS |
|---|---|---|---|
| Physical hosts, network, data center | Provider | Provider | Provider |
| Hypervisor and managed-service internals | Provider | Provider | Provider |
| Guest or node operating system | You | Provider on managed or serverless nodes; you on self-managed nodes | Provider |
| Application code, dependencies, container images | You | You | Provider |
| Configuration, network exposure, storage settings | You | You | You (tenant settings) |
| Identities, permissions, data | You | You | You |
The practical rule: provider-side flaws arrive as provider security bulletins. Track them for awareness, but they are not your tickets. Everything above that line is. The most common mistake is assuming a managed service is "patched by the provider" all the way up, when the configuration, the identities, and the code running on it are still yours.
Containers change how patching works. A running container is meant to be immutable, so you do not patch it in place; you fix the image it was built from, rebuild it, and redeploy. NIST's Application Container Security Guide (SP 800-190) makes the same point: traditional scanning tools often miss vulnerabilities inside containers, and responding to a vulnerable image that is widely used may mean rebuilding and redeploying it rather than installing a patch on existing systems. Scan at three points:
Most image findings come from the base image. Standardizing on a small set of maintained base images, and rebuilding on a schedule even when your own code has not changed, removes a large share of findings at the source. For orchestration-layer risk, our Kubernetes penetration testing guide covers what image scanners miss in cluster configuration and RBAC.
When infrastructure is defined in Terraform, CloudFormation, Bicep, Helm charts, or Kubernetes manifests, a misconfiguration is a line of code before it is a running resource. Scanning those templates in the pull request catches public storage, overly broad IAM policies, open security groups, and missing encryption before they reach an account. The OWASP Infrastructure as Code Security Cheat Sheet recommends static analysis of IaC alongside dependency checks and dynamic analysis of the environments it creates.
Two habits make IaC scanning stick. First, fix findings in the template, not the console; a console fix is overwritten on the next apply. Second, run drift detection, because resources changed by hand or by other tools no longer match the code you scanned. A finding that shows up at runtime but not in the template is usually a drift problem, and its owner is whoever made the manual change.
Cloud security posture management (CSPM) tools read account and service configuration through provider APIs and compare it with benchmarks such as the CIS Benchmarks for AWS, Azure, and Google Cloud. Their findings look different from scanner output: there is usually no CVE, no CVSS score, and no patch. "Storage bucket allows public read" or "access key not rotated in 400 days" is a configuration decision, not a software flaw.
That means CSPM findings need their own prioritization logic. Rank them by what an attacker could reach: is the resource internet-facing, does it hold sensitive data, and does a weak identity or permission connect it to something more valuable? A public bucket of marketing images is low risk; a public bucket next to an over-privileged role that can read your customer database is an attack path. Route each finding to the account or workload owner through the same ticketing and SLA process as CVEs, so posture work does not become a separate, unmeasured queue. Our guide to CSPM tools explains how these platforms work and how to choose one.
Autoscaling instances, containers, and serverless functions may exist for only minutes. A weekly or monthly scan window misses most of them, and an inventory built from scan results is always out of date. Three adjustments help:
Measure accordingly. For an ephemeral fleet, mean time to remediate should track how quickly the fixed image or template reaches production, not how long an individual instance stayed vulnerable. Tags that record owner, environment, and source repository on every resource are what make that routing possible.
The goal is one prioritized view across CVEs in images and hosts, IaC findings, CSPM findings, and identity issues, ranked with the same signals used elsewhere in this guide: active exploitation (CISA KEV), likelihood of exploitation (EPSS), internet exposure, data sensitivity, and asset criticality. Automated tools tell you that a misconfiguration or vulnerable package exists; they rarely prove whether an attacker can chain it into a real path through your accounts. That is the job of cloud penetration testing, which DeepStrike runs across AWS, Azure, and GCP, covering IAM privilege escalation, container and Kubernetes security, and infrastructure-as-code and CI/CD pipelines.
Vulnerability management supports security and assurance requirements across many major frameworks, while some standards such as PCI DSS contain more explicit vulnerability-scanning and remediation requirements. ISO 27001, SOC 2, NIST frameworks, HIPAA, and sector rules may also require or strongly support documented processes for identifying, evaluating, and addressing technical risk, depending on scope and implementation.
The important framing is that compliance is a byproduct of a good program, not its goal. A team that builds vulnerability management to genuinely reduce risk, continuous discovery, risk-based prioritization, tracked remediation, and verification, will satisfy the auditors almost automatically. A team that builds only to pass an audit tends to do the minimum, scan quarterly, file the report, and remains exposed the rest of the time. Build for risk reduction, and let the compliance evidence fall out of it.
Knowing the lifecycle is easy; running it well is where most programs struggle. The recurring obstacles:
Naming these openly is the first step to designing a program that survives contact with reality.
You do not stand up a mature program overnight. A realistic maturity path looks like this:
Crawl. Get an accurate asset inventory and start authenticated scanning on your most important systems. Establish basic severity-based prioritization and a simple ticketing flow so findings become tracked work. The goal here is visibility and a repeatable cycle, however basic.
Walk. Layer risk-based prioritization on top of raw severity, pulling in EPSS and the CISA KEV catalog so effort concentrates on exploitable, exploited flaws. Define remediation SLAs by risk tier, assign clear ownership, and begin reporting trends to leadership. Coverage expands to the full environment, including cloud and external-facing assets.
Run. Move toward continuous, validated exposure management: broaden scope beyond CVEs to misconfigurations, identity, and exposed services in the CTEM spirit, validate prioritized exposures with real testing such as zero-day and exploit-aware assessments, automate the routine, and drive MTTR down while keeping long-lived KEV exposure at zero. At this stage vulnerability management is woven into development and operations, not bolted on afterward.
Most organizations are somewhere between walk and run. The point is not to leap straight to the end, but to always be moving up the curve.
Vulnerability management is not about scanning more; it is about fixing the right things fast, forever. With over 40,000 new CVEs a year and a database backlog behind them, the winning move is disciplined, risk-based prioritization, combining CVSS with EPSS, the CISA KEV catalog, and your own asset context, wrapped in a continuous lifecycle and, increasingly, the broader CTEM model. Validate what you prioritize with real testing, remediate against tight SLAs, and measure relentlessly. Do that, and you fix the handful of exposures that actually drive risk instead of drowning in the thousands that do not. The goal was never a clean scan report; it was a smaller, better-understood attack surface that shrinks a little more with every turn of the cycle.
A vulnerability assessment is a point-in-time snapshot, a scan or review that lists weaknesses at one moment. Vulnerability management is the ongoing program that surrounds those assessments: continuously discovering, prioritizing, remediating, and verifying weaknesses in a repeating cycle. The assessment is one step; the management is the whole lifecycle.
Vulnerability management is a continuous program built largely on automated scanning to find and fix known weaknesses at scale. Penetration testing is a targeted, human-led engagement that actively exploits and chains weaknesses to show real-world impact. They complement each other: pentesting validates whether the exposures your program prioritized are truly exploitable.
Do not rely on CVSS alone. Layer CVSS with EPSS (probability of exploitation), the CISA KEV catalog (active exploitation in the wild), and your own asset context (how critical and exposed the system is). A flaw that is actively exploited and internet-facing outranks a higher-CVSS flaw that no one is exploiting on an isolated system.
Continuous Threat Exposure Management is a Gartner framework that broadens vulnerability management from known software flaws to the whole attack surface, misconfigurations, identity risks, exposed APIs, and more, across five repeating stages: scoping, discovery, prioritization, validation, and mobilization. Think of it as vulnerability management grown up: continuous, risk-based, and validated by real testing.
Set SLAs by risk, not by CVSS alone. Actively exploited, internet-facing vulnerabilities should be fixed in days; lower-risk findings can follow normal patch cycles. As a benchmark, CISA's 2026 BOD 26-04 can require federal agencies to remediate the most dangerous flaws in as little as three days, and private-sector programs are trending toward similarly risk-driven deadlines.
A program typically combines a vulnerability scanner (covering infrastructure, web, cloud, and containers), asset-discovery and attack-surface tooling to keep the inventory current, a risk-based prioritization or CTEM platform that ingests EPSS, the CISA KEV catalog, and asset context, and integration with ticketing so findings become owned, tracked work. But tools alone are not a program; the human structure of ownership, SLAs, and a repeating cycle is what makes them effective. For published scanner and platform list prices, see our vulnerability management pricing guide.
Much of it can and should be. Discovery, scanning, prioritization enrichment, and ticket creation are all automatable, which is what lets a small team keep pace with tens of thousands of findings. But remediation decisions, risk acceptance, and validating whether an exposure is genuinely exploitable still need human judgment, and hands-on testing like penetration testing remains essential. Automate the routine so people can focus on the calls that require reasoning.
Cloud vulnerability management is the continuous process of finding, prioritizing, and fixing weaknesses in cloud workloads, container images, infrastructure-as-code templates, and account configuration. It differs from traditional programs because assets are short-lived and defined in code, much of the risk is misconfiguration and identity rather than CVEs, and the cloud provider fixes some layers while the customer always owns its data, identities, configuration, and the code it deploys.
Vulnerability management finds and fixes known weaknesses, mostly CVEs and misconfigurations, on known assets. Exposure management is broader: it looks at every way an attacker could reach critical assets, including unknown assets, identity paths, and chained weaknesses, and validates which paths are really exploitable. Vulnerability management is one component of an exposure management program such as CTEM.
Vulnerability risk management, often called risk-based vulnerability management, ranks vulnerabilities by business risk rather than severity alone. It combines likelihood signals such as CISA KEV, EPSS, and internet exposure with impact signals such as asset criticality and data sensitivity, then sets remediation deadlines and treatment decisions by risk tier.
Stay secure with DeepStrike penetration testing services. Reach out for a quote or customized technical proposal today
Contact Us
