Vulnerability management for the modern engineering team
Vulnerability management is more than scanning. It’s a continuous cycle of inventory, prioritization, remediation, and verification across teams.
Poor vuln management costs real money. Breaches, audit failures, tool sprawl, and burnout pile up when teams chase endless backlogs of Common Vulnerabilities and Exposures (CVEs).
Split findings into two lanes. Findings that are publicly exposed, known exploited, or automatable get a deadline, and everything else gets fixed at your next scheduled rebuild.
What you rebuild from sets your workload. Chainguard Containers are minimal, continuously rebuilt images that start with zero known CVEs and carry published remediation timeframes. They and Chainguard Libraries ship with Software Bills of Materials (SBOMs), so fewer findings reach either lane.
Most teams experience vulnerability management as endless toil: new vulnerabilities are published every day and the work never catches up.
Your security scanner flags them all. As engineers address and fix each one, your backlog continues to grow with every new scan.
The team feels stuck in a cycle of never-ending scanning and patching.
Seem familiar?
Teams are dealing with more vulnerabilities, stricter compliance requirements, and faster release cycles. And you still have to ship products.
However, it doesn’t have to be this way. The most effective programs go beyond triage to focus on building secure foundations that prevent vulnerabilities from reaching production in the first place.
In practice, that means two lanes.
Findings that are publicly exposed, known exploited, or automatable get a remediation deadline, and technical impact helps set how short it is. Everything else gets fixed at your next scheduled rebuild, which makes the components you rebuild from your biggest lever.
What is vulnerability management?
Vulnerability management is the ongoing process of identifying, evaluating, prioritizing, and addressing security weaknesses across your systems and software. It's a continuous lifecycle spanning multiple teams (security, operations, development) and requiring coordination across your entire infrastructure.
Vulnerability scanning is the automated process of detecting known vulnerabilities. Scanners check your code, containers, and infrastructure against databases, like the National Vulnerability Database (NVD) and the CVE list. Scanning is just one part of vulnerability management.
Patch management is the follow-up process of applying updates and fixes to address known vulnerabilities. It's the remediation phase. You can't patch effectively without first identifying and prioritizing what needs to be fixed.
Vulnerability management is the framework that connects all of these pieces. It includes asset discovery, scanning, risk assessment, prioritization, remediation (including patching), and verification.
Most organizations focus primarily on scanning and patching after vulnerabilities surface. That’s not wrong, but it's incomplete and inefficient. Effective vulnerability management involves a more comprehensive approach: understanding the assets you have, where they're deployed, the vulnerabilities that affect them, which ones pose a real risk, and how to prevent similar issues in the future.
For teams that ship software, many of those vulnerabilities don’t come from code you wrote. They arrive with the third-party libraries and operating system packages inside your container images.
Why vulnerability management matters
Vulnerability management protects businesses from real consequences that affect revenue, reputation, and day-to-day operations.
High-profile breaches often trace back to unpatched vulnerabilities or misconfigurations that could have been caught with the right management processes.
Vulnerability management helps:
Reduce security risk and exposure: Every unpatched vulnerability is a potential entry point for attackers. Vulnerability management helps you reduce your attack surface by identifying which assets are exposed and which vulnerabilities are the most urgent.
Meet compliance and regulatory requirements: Without a structured program, compliance audits take longer to prepare for and cost more. Frameworks like the Federal Risk and Authorization Management Program (FedRAMP), Payment Card Industry Data Security Standard (PCI DSS) 4.0.1, and Cybersecurity Maturity Model Certification (CMMC) explicitly require documented vulnerability management practices. Failing here can directly block contracts, delay audits, or trigger fines. Solid vulnerability management helps you maintain the documentation, metrics, and processes that auditors expect.
Save time and resources: Without proper vulnerability management, teams waste time on low-priority issues while critical vulnerabilities slip through. Some teams report spending thousands of hours annually triaging vulnerabilities that never posed a real risk in the first place. Good vulnerability management guides teams to work more efficiently by creating clear priorities, automating repetitive tasks, and focusing human attention where it’s actually needed.
The costs of poor vulnerability management
When vulnerability management breaks down, the costs show up in both direct and hidden ways.
Direct costs, like breach fines and regulatory penalties, can run into millions of dollars. Incident response costs add up fast with forensic investigators, legal counsel, and public relations crisis management.
IBM’s Cost of a Data Breach Report 2026 found that the average cost of a data breach reached $4.99 million.
Meanwhile, hidden costs add up. Engineers burn out from constant firefighting. Features don't ship while teams fix preventable problems. And a failed compliance renewal can stop you from closing new deals and signing new customers.
The core processes of vulnerability management
Most frameworks describe vulnerability management as a lifecycle: discovery, identification, prioritization, remediation, and verification.
The process is iterative and ongoing because new vulnerabilities appear daily. The cycle looks something like this:
Asset discovery and inventory: You can't protect what you don't know about. Asset discovery is the process of identifying all assets within your environment, and the inventory is the catalog of assets that you have documented. Cloud environments make this hard because resources scale dynamically and are constantly changing. Your asset inventory needs to be automated to stay up to date.
Vulnerability identification and scanning: Once you know what assets you have, identify which vulnerabilities affect them. The challenge generally isn't finding vulnerabilities (scanners are great at that), but just dealing with the sheer volume of findings.
Risk-based prioritization: Not all vulnerabilities require the same level of urgency. Prioritize based on severity scores, exploitability, asset criticality, exposure, and data sensitivity. A "critical" vulnerability in a library you don't use (but ships as a dependency) isn't really critical for you.
Remediation and patching: Fix vulnerabilities through patching, rebuilding on updated components, configuration changes, workarounds, or compensating controls.
Verification and continuous improvement: After remediation, check that the fix worked and report the findings to the right stakeholders. Learn from each cycle to address root causes rather than treating symptoms.
Common challenges with vulnerability management
Even with good intentions and the right tools, most teams hit predictable roadblocks when implementing vulnerability management programs. Some of the most common problems are:
Alert fatigue and false positives: Like an oversentive smoke detector that screams every time you make toast, scanners flag everything that might be a problem without taking into account the context. False positives are frustrating and waste time.
Growing CVE backlogs: New CVEs are published faster than most teams can remediate them after they’ve already been deployed. Teams fall behind as a list of vulnerabilities continues to pile up.
Tool sprawl and integration gaps: Most organizations use multiple security tools with their own interfaces and alerting systems, which creates extra work. Scanner integration, for example, is notoriously difficult, and keeping up with tools requires expertise and time. Teams spend too many resources on tool integration and maintenance instead of on actual security work.
Misalignment between security and development teams: Security teams want to block risky deployments, but development teams want to ship fast. Developers are likely to bypass (or ignore) security processes that disrupt their workflows, which can cause vulnerabilities to slip through to production. Both teams waste time fighting each other instead of fixing actual problems.
Compliance pressures and visibility gaps: Auditors want documentation of your vulnerability management plans. Most teams struggle to meet this requirement because they don't have good visibility into their own processes.
Most of these problems share a root cause. In many teams, findings land in a single queue, sorted by Common Vulnerability Scoring System (CVSS) severity. You work it from the top down and the program gets judged by how fast tickets close.
Why one CVSS-sorted queue can’t clear a CVE backlog
A single queue sorted by CVSS severity can’t keep up. In 2025, Jerry Gamblin’s annual review counted 48,185 published CVEs, up 20.6% from the year before.
The list attackers actually used is much shorter. In 2025, VulnCheck found first-time exploitation evidence for 884 vulnerabilities, and the Cybersecurity and Infrastructure Security Agency (CISA) added 245 to its Known Exploited Vulnerabilities (KEV) catalog.
Even the National Institute of Standards and Technology (NIST) has changed its approach. Since April 2026, it has prioritized enriching CVEs in the NVD, focusing on known exploited vulnerabilities and software used by federal agencies. Other CVEs might still have severity scores and product information from their original sources, but NIST no longer analyzes all of them individually.
A CVSS base score alone doesn’t tell you which vulnerabilities pose the greatest risk to your environment. It describes a vulnerability’s severity, but it doesn’t account for your specific exposure, runtime context, or whether it’s known to be actively exploited.
When Datadog added runtime context, such as whether a service runs in production or faces the internet, the average count of high and critical vulnerabilities per application fell from 12.2 to 7.5. The drop was steepest at the top, where only 18% of CVSS-critical vulnerabilities stayed critical.
FedRAMP’s 2026 rules state that “most traditional vulnerabilities discovered by scanners or during assessment are not likely to be exploitable.” A queue sorted by CVSS spends most of its time on findings that never needed a deadline, while the few that did wait their turn.
The response lane: CISA BOD 26-04’s four questions set remediation deadlines
The first lane, the response lane, holds the findings that need remediation within a defined timeframe based on their exploitation risk.
CISA’s Binding Operational Directive (BOD) 26-04, issued in June 2026 for federal civilian agencies, gives you a ready-made way to pick them. It asks four questions about each vulnerability:
Whether the vulnerable asset is publicly exposed to untrusted users
Whether the CVE is in CISA’s KEV catalog
Whether an attacker can automate every step of the exploit
Whether exploitation gives the attacker total control of the software, such as running arbitrary code or obtaining login credentials, or only partial control, such as causing a denial of service
CISA’s decision table covers all 16 combinations of answers, and these six rows show selected examples. Match a finding’s four answers to a row to read its deadline in calendar days. Deadlines are in calendar days, and the full table covers any combination not shown here.
Publicly exposed | In the KEV catalog | Automatable | Technical impact | CISA deadline |
|---|---|---|---|---|
Yes | Yes | Yes | Total control | Three days, plus forensic triage to check for compromise |
Yes | No | Yes | Total control | Three days |
Yes | No | No | Partial control | 60 days |
No | Yes | No | Partial or total control | 14 days |
No | No | Yes | Total control | 60 days |
No | No | No | Partial or total control | Fix on system upgrade |
The same automatable, total-control flaw that isn’t in the KEV catalog gets three days on an exposed system and 60 days on an internal one.
To pick a lane, you only need the first three answers. If a finding is publicly exposed, in the KEV catalog, or automatable, it gets a deadline, and technical impact helps set how short it is. If all three answers are no, it goes to the rebuild lane.
BOD 26-04 only binds federal agencies, but the logic carries over to your team.
You also don’t have to research most of the answers yourself. CISA says it publishes KEV status, automatability, and technical impact for every CVE ID through its Vulnrichment Program. Exposure is the answer only you can supply, so tag each asset as public or internal in your inventory and feed those tags into triage.
For dependencies, “exposed” means reachable from an internet-facing service, even when the vulnerable library sits several calls deep (FedRAMP calls this internet-reachable). Runtime context can answer this at scale, using the signals behind Datadog’s numbers above: whether the service runs in production and whether it faces the internet.
“Automatable” asks whether an attacker could script the whole exploit, and public exploit code is a strong sign. When you can’t tell, assume yes, which is what FedRAMP’s new rules require of cloud providers.
The Exploit Prediction Scoring System (EPSS) helps on the other end. It estimates how likely a CVE is to be exploited in the next 30 days. Datadog’s prioritization treats a score under 1 percent as a reason to downgrade.
Deadlines move, too. Take a system off the internet and its clock slows down, while a new KEV listing speeds it up.
What if no patch exists when the deadline arrives? CISA counts patching, decommissioning the system, or another action as remediation, and it names taking a system off the internet as a valid mitigation. That moves the finding to a slower row, though a KEV-listed finding still gets 14 days or fewer. Record the mitigation and keep the finding open until a fix ships.
Exploiting a vulnerability was how attackers got in for 31% of breaches in the 2026 Verizon Data Breach Investigations Report, so this lane can’t wait.
The rebuild lane: fix everything else at your next container image rebuild
Everything that doesn’t earn a deadline goes into the second lane. CISA calls this outcome “fix on system upgrade,” meaning the fix lands “the next time the vulnerable asset receives a scheduled major upgrade or rebuild.”
For container workloads, that’s your next image build once the components are patched.
Say a Java service that isn’t internet-facing picks up a high-severity CVE in an operating system package with no known exploit. The vulnerability isn’t in CISA’s KEV catalog, and the exploitation isn’t automatable. It goes in the rebuild lane, and what matters is how soon you rebuild and whether the new base image has the fix.
It still gets fixed, on a cadence your team commits to. NIST calls this kind of routine patching preventive maintenance.
CISA doesn’t set a number here, so choose one you can hold. Rebuilding base images weekly is a reasonable place to start, and a fix only counts once the new image is deployed. Set a maximum image age too, so a rarely updated service can’t hold on to a finding indefinitely. That limit also covers the risk of an attacker who’s already inside your network, since “not exposed” only describes the path in from the internet.
Before you shorten that cadence, check that your tests would catch a breaking change in a new base image, since every rebuild pulls in updated packages.
Three things decide how much work this lane costs you, and Datadog’s data puts numbers on each.
What you start from. Images under 100 MB averaged three high or critical vulnerabilities (median zero), and images over 500 MB averaged 20 (median seven).
How often you rebuild. Dependencies in services deployed less than once a month were 47% more outdated than in services deployed daily.
Whether your dependencies are still maintained. One in two services used libraries that no longer get updates. Rebuilding can’t fix those, so Datadog’s advice is to treat them like an end-of-life operating system and move to a maintained version.
For teams working with containers and third-party dependencies, most findings land in this lane. FedRAMP’s view that most scanner findings aren’t likely to be exploitable points the same way. That makes what you build from the biggest decision in your program, because a package you don’t ship is a finding nobody has to triage.
FedRAMP is moving to the same split, and PCI DSS already asks for risk ranking
If you sell to regulated customers, expect auditors to ask about both lanes.
BOD 26-04 replaced CISA’s earlier directives, BOD 22-01 and BOD 19-02, with risk-based timelines. Six days later, FedRAMP told cloud providers that “the legacy monthly vulnerability scanning process that most FedRAMP Rev5 Certified cloud services currently follow is insufficient.”
Its replacement rules, mandatory from December 7, 2026, have providers sort findings by whether they’re internet-reachable and likely exploitable, the same split as the lanes above.
PCI DSS 4.0.1 already asks you to rank vulnerabilities by risk and install patches for the ones you rank critical within one month of release.
If you’re in scope, your remediation has to meet that deadline, even if it means rebuilding ahead of schedule.
Which vulnerability management metrics should each lane track?
Useful metrics include mean time to remediate by severity level, percentage of assets scanned recently, service-level agreement (SLA) adherence, and vulnerability density per service.
Then give each lane its own scoreboard. In the response lane, measure the time from a KEV listing or exposure discovery to the fix against the deadline you adopted, plus the share closed on time.
In the rebuild lane, track the age of each base image in production, the days since each service’s last rebuild, the CVE count in images at build time, and the share of services running on a maintained base. A fast ticket close rate tells you very little about either lane on its own.
The future of vulnerability management
Vulnerability management is changing faster now than it has in years. Here's what to expect in the future:
AI for exploit discovery and patch prioritization: Machine learning models will continue to get better at predicting which vulnerabilities are likely to be exploited based on patterns in attacker behavior. Malicious actors are already using AI to look for vulnerabilities, and CISA warns that their use of AI may further narrow the time defenders have to react, so organizations need to stay ahead.
SBOM mandates, provenance requirements, and compliance: Government agencies and enterprise customers will increasingly require SBOMs that document software components with signatures and provenance that verify their integrity and their origin.
Proactive prevention over reactive scanning: More organizations will use secure base images, enforce policies at build time, and choose components that minimize attack surface, so they have less reactive work to do.
Integration across DevSecOps pipelines: Security tools are already becoming more tightly integrated with development and operations tools that teams already use, making security more actionable.
Best practices for building an effective vulnerability management program
The two-lane approach works best when it’s supported by consistent practices. Some ways to create a top-notch, proactive vulnerability management program include:
Write the lane rule into your policy: Put the four questions, your deadlines, and your rebuild cadence in your vulnerability management policy, so triage calls don’t depend on who’s on rotation.
Automate wherever possible: Manual processes don't scale. Automate asset discovery, scanning, ticket creation, and remediation where you can.
Align security and engineering workflows: Build security into the tools and processes engineers already use, so they don’t have to choose to use them. The goal is to make the secure choice the path of least resistance.
Shift security left in the software development lifecycle: The earlier you catch vulnerabilities, the cheaper they are to fix. Policy enforcement at build time, automated scanning in continuous integration and delivery pipelines, and secure base images prevent introducing vulnerabilities before code ever ships.
How to choose base images and libraries for your rebuild lane
Your rebuild lane is only as good as what it rebuilds from. Look for five things in the base images and library sources you choose.
Minimal images, so fewer packages enter in the first place
Continuous rebuilds from source, so your next build picks up fixes without waiting for a distro upgrade
Published remediation timeframes, so you can plan your rebuild cadence around them
An SBOM and provenance for every artifact, so audit evidence ships with the component
A way to fix CVEs in libraries you can’t upgrade yet
Both lanes have one limit: They only work on known CVEs. Datadog found thousands of malicious PyPI and npm packages in 2024.
A malicious package doesn’t need a known vulnerability to do damage, so CVE-based processes miss it, and stopping it takes controls at the registry.
Strengthen your vulnerability management program with Chainguard
Most vulnerability management solutions focus on detection. Chainguard takes a different approach by helping you eliminate vulnerabilities at the source.
With Chainguard, you get:
Continuously rebuilt, SLA-backed container images that incorporate critical patches within published remediation timeframes
Minimal, hardened components that shrink your attack surface and dramatically reduce false positives
Built-in SBOMs and provenance attestations that simplify compliance audits
Drop-in compatibility with your existing workflows and tooling
Chainguard Libraries for Python, Java, and JavaScript, with early access for Go and .NET. For supported Python, Java, JavaScript and Go libraries, it also backports critical and high CVE fixes to versions you can’t upgrade yet.
Chainguard Repository, one policy-aware endpoint where you set the rules for upstream packages, including configurable cooldown periods and CVE blocking
Chainguard Harness (currently in beta) finds vulnerabilities in your own code and delivers proposed fixes
Chainguard won’t run your response lane for you. Exposed and known-exploited findings in your own code and services still need triage against their deadlines, though Harness can help with your own code. Starting from container images with zero known CVEs and Chainguard Libraries means fewer findings reach your response lane and keeps your rebuild lane short.
A short rebuild lane means engineers spend less time on vulnerabilities and more time on the product. Domino Data Lab estimates that using Chainguard Containers eliminates about four hours of CVE remediation work per engineer every month.
Start by reviewing your existing vulnerability backlog using the four questions. Identify which findings belong in the response lane and which belong in the rebuild lane. Then, establish a rebuild and deployment cadence, and verify that fixes are reaching production within the deadlines you set.
Talk to an expert to learn how Chainguard can help you move from reactive vulnerability management to proactive prevention. You can also take the Painless Vulnerability Management course.