The state of vulnerability management 2025

Executive summary

We surveyed 200+ professionals, predominantly engineering and DevOps, to understand real-world vulnerability remediation challenges and confidence levels.

While most teams express at least moderate confidence in their ability to remediate vulnerabilities, a significant portion reports substantial developer time spent chasing vulnerabilities and a persistent set of remediation blockers tied to change risk, CVE volume, and process inefficiencies.

Who responded

Respondent roles

• Engineering / DevOps: ~94%
• Security / CISOs / leadership: ~6%

Engineering org size distribution

Confidence vs. effort

Confidence in ability to remediate critical CVEs quickly

Developer time spent on remediation

Takeaways:

More than half of respondents report lacking full confidence in their ability to remediate critical CVEs and spending at least an hour each week on vulnerability remediation.

The largest group of respondents sits in a steady state of being somewhat confident while dedicating 1–5 hours per week to remediation

Teams that report low confidence are far more likely to spend 5–10+ hours per week on CVEs, while even highly confident teams do not consistently escape recurring remediation efforts. Taken together, the data shows that vulnerability work is not episodic – it’s continuous, and only a minority of teams experience both high confidence and minimal remediation time.

What slows remediation

Respondents could select multiple blockers. These are the top challenges reported

Takeaways:

1. No single blocker dominates – remediation is constrained by multiple factors at once.

Each blocker has substantial representation (52–78), especially given that respondents could select multiple options. This indicates that remediation slowdowns are rarely caused by one issue in isolation; teams are dealing with overlapping constraints simultaneously.

2. Structural issues rival process issues.

Base image sprawl and lack of standardization is slightly cited more often than slow remediation cycles, suggesting that upstream architectural choices can be just as limiting as downstream remediation workflows.

3. Remediation friction is not primarily driven by edge cases.

“Other” responses are minimal, indicating that the dominant challenges are well-understood and broadly shared rather than highly organization-specific.

Tooling and ownership

Who decides which tools to use to address vulnerabilities

Takeaways:

1. Split ownership reflects competing priorities, not shared accountability.

Tool choice authority is nearly evenly split between security and engineering, reflecting potentially competing priorities around risk reduction and developer velocity rather than a single, shared accountability model.

2. Ambiguity signals operational blind spots, not just org chart confusion.

Nearly one in five respondents do not know who chooses vulnerability tools, pointing to organizational blind spots where ownership is unclear and decision-making becomes implicit rather than intentional.

3. Misalignment likely shows up during remediation, not evaluation.

When tool selection is decoupled from remediation ownership, friction is most likely to surface during adoption and day-to-day remediation, rather than during initial tool evaluation.

AI in remediation

Leveraging AI to patch vulnerabilities

Takeaways:

While AI adoption in vulnerability patching is growing, the majority of teams are still not actively leveraging it in their remediation workflows.

A significant portion of respondents report plans to adopt AI, indicating rising interest and experimentation, but this intent has not yet translated into widespread operational use. The gap between planning and active usage suggests teams are evaluating AI cautiously, particularly given the risks associated with automated remediation, breaking changes, and production stability.

For most organizations today, AI appears to be an emerging supplement to existing processes rather than a trusted default for vulnerability patching.

What these insights mean

Vulnerability management in 2025 is marked by confidence coexisting with cost – remediation remains time-intensive and risk-laden. Breaking changes and vulnerability volume are major blockers, while tooling decisions lack clear ownership. AI adoption is growing, but on its own, it has not fundamentally changed the day-to-day work of fixing vulnerabilities for most teams.

Big picture, this suggests that the limiting factor in vulnerability management is no longer awareness or detection. Most organizations know these vulnerabilities are skyrocketing and have tools in place to find them. The constraint is execution: fixing issues effectively, quickly, and without disrupting delivery.

Based on these findings, the 2026 focus should be:

• Addressing the sources of recurring vulnerabilities to reduce repeat exposure.
• Prioritizing remediation approaches that avoid disruptive upgrades and large-scale refactors to minimize breaking changes
• Clarifying ownership for vulnerability decisions, so it is explicit who is responsible for fixing, deferring, or accepting risk when issues are found
• Investing in workflows that lower the time and risk of remediation, instead of optimizing only for faster detection

The data points to a clear conclusion: the next gains in vulnerability management will not come from seeing more vulnerabilities, but from making them easier and safer to eliminate.

Where does echo fit in?

This is where approaches like echo come in. With vulnerability-free container images that are automatically patched and hardened, echo takes the burden off engineers and security teams – eliminating these issues at the source. Built to fit into existing workflows with seamless compatibility, echo solves the volume, breaking-change risk, and ownership gaps highlighted in the data, without requiring organizations to replace their existing security tooling.

Want to discuss with a product expert? Book a call.