Why does vulnerability management fall short for application security?

Vulnerability management falls short in application security because it was built to inventory known flaws in installed software, while application risk also lives in your own code, in how dependencies are used, and in logic errors that have no CVE. A list of identifiers is not a measure of exposure.

Where did the model come from?

Traditional vulnerability management grew up around hosts and network services: discover assets, scan for known weaknesses, rank by severity, patch. That works when the unit of risk is a package version on a server and a vendor ships a fix.

Applications break each assumption. The thing you ship is assembled from your code plus hundreds of transitive packages, and it changes several times a day.

What does it miss?

First, flaws that never get an identifier. Cross-site request forgery is catalogued by MITRE as CWE-352: the application does not sufficiently verify whether a request was intentionally provided by the user who sent it. That weakness lives in your routes and your session design. No host scanner will report it as a missing patch.

Second, context. A CVE in a library says a flaw exists somewhere in it. Whether your service calls the vulnerable function with attacker-influenced input is a separate question. Severity scores describe the flaw in general, not in your build.

Third, speed. CISA's Known Exploited Vulnerabilities catalog lists flaws with evidence of exploitation in the wild, and FIRST's EPSS provides a probability estimate of exploitation. Both are signals that differ from a base severity score, and a program that ranks only by CVSS ignores them.

A constructed comparison

Two findings land on the same Monday. The first is a critical-rated flaw in a parsing library used by a build tool that never runs in production. The second is a medium-rated flaw in a library whose vulnerable function your public login endpoint calls with request data.

A severity-sorted queue handles the first. A context-aware queue handles the second. The point is not that severity scores are useless. It is that they are one input.

What would a better program look at?

Ask five questions of every finding:

• Is it reachable from code that runs?
• Is the code exposed to untrusted input?
• Is there known exploitation, per the KEV catalog or similar evidence?
• Does a fix exist and can it ship safely?
• What does the asset hold or control?

Then add what scanners of hosts skip: static analysis of your own code, dependency inventory with lockfile accuracy, secrets detection, and checks in the pull request where the cost of change is lowest.

What about ownership?

A vulnerability queue owned only by security grows forever. Findings need an owning team, a service-level target and a place in the sprint. Without those, "falling short" means the list is accurate and nothing happens.

How to check or apply this

1. Inventory what you ship: first-party code, direct and transitive dependencies, containers.
2. Add reachability or at least usage context before ranking.
3. Combine severity with exploitation evidence from the KEV catalog and an exploit-likelihood score such as EPSS.
4. Cover weakness classes with no CVE, such as CWE-352, using code analysis and design review.
5. Shift checks into the pull request and CI.
6. Assign every finding to a team with a target date.
7. Track time to remediate exposed findings, not the size of the backlog.

Where does Safeguard fit?

Safeguard combines SBOM and dependency scanning, code scanning, and reachability analysis so findings carry context about whether affected code is actually called. Policies and gates can then act on that context in pull requests.

Quick check

Sources

• MITRE CWE-352, Cross-Site Request Forgery
• CISA Known Exploited Vulnerabilities Catalog
• FIRST, Exploit Prediction Scoring System
• NIST SP 800-218, Secure Software Development Framework

Last reviewed: 18 October 2026.