If you’ve been following me for some time, you know how big of an advocate of effective vulnerability prioritization and management I am.

To put it bluntly, the industry is largely broken when it comes to vulnerability management for various reasons, and it is only getting worse. This recent 2025 AppSec Benchmark Report from OX Security really puts in perspective just how critical context is for optimized prioritization in vulnerability management and how failing to do so is burying developers and business peers in noise and toil.

As I discuss some of the report's findings, I’m sure you’ll agree that context-based prioritization is critical for effective vulnerability management.

Setting the Table

Before we discuss the report's findings, explaining why context and prioritization are crucial for vulnerability management is helpful.

As of March 2025, CVEs are growing 48%~ year over year (YoY) from 2024, averaging 135~ CVEs a day. This is in addition to double-digit CVE growth throughout 2024 (and the year before).

Due to this, organizations are outright drowning in vulnerability backlogs in the hundreds of thousands and even millions in large enterprise environments. This has created a situation where organizations struggle to keep up and are unsure where to begin, making prioritization a critical need. The below image from the OX report really puts in perspective the exponential growth of vulnerabilities over the past almost-decade:

The problem is further amplified since most organizations use legacy approaches to vulnerability prioritization, such as the Common Vulnerability Scoring System (CVSS) base scores. These scores have no organizational context and do not account for factors such as known exploitation (e.g., CISA’s Known Exploited Vulnerability—KEV) or exploitation probability (e.g., Exploit Prediction Scoring System—EPSS).

Failing to account for these means organizations spend an inordinate amount of time on vulnerabilities that are never exploited, roughly 95% of CVEs annually, and waste tremendous time and effort from Development, Engineering, and Business peers. This makes security a tax on the organization rather than a business enabler, as we like to frame it.

But just how much noise is there? That’s where the report from OX really sheds light, so let’s take a look.

Key Findings

At a high level, OX found that 95% of all AppSec alerts can be safely deprioritized for various reasons, as seen in the image below, such as a low exploit risk, a lack of public exploitation, and being tied to indirect or development dependencies.

OX found that only 2-5% of alerts are critical and require action, such as being tied to known exploitation or the exposure of secrets.

To get through the noise and find out how problematic the alert fatigue is, OX looked at 101 million security findings across 178 organizations. It is astounding that the average organization faces over 500,000 security alerts, of which 2%~ truly pose risk and require action by the organization.

The problem is that isn’t how most organizations handle AppSec and VulnMgt. We beat development peers with massive spreadsheets and lists of findings with little to no context or enrichment around known exploitation, exploitability, reachability, or business criticality.

We do all this while masquerading as business enablers, actively burying our peers in toil, delaying development velocity, and ultimately impeding business outcomes.

OX looked at the security profile of the average organization, and the clarity that came from context-based prioritization for both active and critical issues is massive:

As seen above, on average, an organization deals with 98% of its “findings” being outright noise that isn’t exploitable, likely to be exploited, lacking business context, and more. So, while the rate of CVEs in the NVD is climbing, and we continue to “shift left” by adding more security tooling to CI/CD pipelines and arbitrary gates for development to make it through to production, we’re doing so with nearly all of the findings being toil that does little to eliminate real risks for the organization.

Imagine how much worse the problem would be if organizations widely adopted AI-driven development and Copilots and drove their development velocity higher than it already is.

Four key takeaways and recommendations OX makes include:

• Shift from Vulnerability Management to Risk Management

• Build an End-to-End AppSec Pipeline

• Assist Developers Instead of Overwhelming Them

• Foster Cross-Team Collaboration

“Security” Making Us Insecure

Another theme that jumped out to me from the OX report and that I’ve written about extensively is that security is counterintuitively having the opposite impact. While we claim to be a business enabler, looking to reduce organizational risk, by burying engineering and development peers in toil and noise, we’re both impeding business outcomes and distracting from actual risk reduction.

Developers spend inordinate amounts of time chasing down findings that lack any context or true risk to the organization while slowing down product velocity, and security teams triage, track, and manage long lists of vulnerabilities that don’t pose a risk rather than focusing on those that do.

The below quote from Gartner and in the OX report highlights the challenge that legacy tooling presents:

While we’ve discussed that 95-98% of findings are noise, which is often cited in other sources and reports as well, what I liked about OX’s report is that it dives into the remaining subset of findings that are legit and where they originate.

This is captured in the image below, which shows the source of the genuine risks, ranging from KEVs to secrets (of various types and sources) and more.

To optimize prioritization, OX advocates for methods such as:

• Reachability analysis

• Exploit probability

• Business impact

• Environmental context

• Dependency mapping

Legacy vulnerability tooling and organizational vulnerability management programs lack many of these methods and considerations. Most of these programs just rely on CVSS base scores. These programs do not consider whether something is known to be exploited, exploitable, or reachable or the context of the assets and data involved.

To put in perspective the massive impact effective prioritization can have on the average organization, take a look at the image below, which shows how both issues and critical issues were decreased by 96-97% with context-based prioritization.

If you’ve ever worked in DevSecOps environments with developers, the idea of trying to advocate that they remediate 97%~ less vulnerabilities than they currently should appeal to you, as it certainly will for Developers as well. When applying methods to reduce the alert fatigue, you can see the various factors playing a part:

These include findings with low EPSS scores, a lack of a public exploit, limited business impact (e.g., non-business critical systems or processes), and being tied to indirect and development dependencies. However, with the exception of potentially the business context, manually applying this context to thousands (or millions) of findings at scale is impractical and unrealistic, hence the need for modernized tooling and automation.

Loose Lips (Secrets) Sink Ships

Another thing that jumped out is that, beyond findings such as known exploited vulnerabilities, secret leakage was rampant among valid findings from multiple disparate sources and methods.

This involves SaaS, source code management, CI secrets, repos, Infrastructure-as-Code (IaC), and more. I’ve previously discussed this challenge in articles such as “Keeping Secrets in a DevSecOps Cloud-native World”.

Secret leakage has been involved in several high-profile incidents and data breaches, and continues to be a growing problem YoY, with public repositories and exposure involve countless examples of insecure secret management.

GitGuard, for example, which publishes an annual “State of Secrets Sprawl Report,” found in their latest report a 25% growth in publicly exposed secrets in GitHub alone in 2024.

OX identified these secrets, such as API keys, passwords, and tokens, as being integrated directly into code and repositories and posing real organizational risks due to poor secret management.

Additionally, poor posture management remains problematic, as factors such as excessive administrators, outside code contributions, and even code forking from former users come into play.

Closing Thoughts

It may be tempting to think the figures above are isolated examples, but OX examined hundreds of organizations and applications across a diverse range of industries, such as Tech, Transportation, Financial Services, and more. The findings were relatively equal across all environments.

Massive noise and only an average of 2%~ of findings are real risks, as opposed to toil and frustration burying development teams and dragging down organizational software velocity, all at a time when competitive pressures in the market are rising.

Through effective context-based vulnerability prioritization, cybersecurity has an opportunity to be a real business enabler focused on risk reduction, but it requires embracing modern tools and methodologies and bringing relief to our development peers to be seen as a partner rather than a problem.