Examples in this article are illustrative, not customer case studies. Product availability and coverage are described on the linked capability pages.
Your scanner reports a thousand criticals against the payments API, and the team can fix perhaps a handful this week. This post shows how to rank them by reachability and exposure, so the handful you fix are the ones an attacker could actually use.
Risk-based vulnerability management ranks findings by the risk they pose in your environment rather than by CVSS alone. It combines severity, known exploitation, reachability confidence, exposure and business impact. Unknown reachability is an evidence gap, not proof that a component is safe.
CVSS measures the vulnerability, not your risk
A CVSS score describes the flaw in isolation: how it could be exploited and what it could do, assuming an attacker can reach it. It does not know whether the vulnerable function is ever called by the payments API, whether the library is linked but dead, or whether the service sits behind a public load balancer. Two organisations can carry the same critical CVE and face entirely different risk, because CVSS was never designed to answer the deployment question.
Rank the queue by CVSS alone and a reachable, internet-facing flaw sits at the same priority as a theoretical one that no code path touches. That is how the payments API accumulated a thousand criticals in the first place: every one looked urgent, so none of them stood out.
Risk-based vulnerability management starts with reachability
One important signal is reachability: does execution ever reach the vulnerable function with attacker-influenced input. Much of the payments API’s queue comes from transitive dependencies, and many of those CVEs sit in functions the service never calls under any configuration. Those findings are real, because the vulnerable code exists in the tree, but they present little risk to this application. A flaw in a parser that receives request bodies directly, with no validation in between, deserves attention whatever its base score.
Answering the question means tracing data flow, not listing packages. Taint analysis follows input from an entry point, such as an HTTP handler, a message consumer or a CLI argument, through the call graph to the point where the vulnerable code runs. A dependency list can only tell you the vulnerable version is present; it cannot tell you whether anything uses it.
Exposure decides who can trigger a reachable flaw
Reachability says whether the code path runs. Exposure says who can make it run. The payments API ships as the same image to two places: a public checkout service behind an internet-facing ingress, and an internal reconciliation job that only processes files from another internal system. The same reachable flaw carries very different risk in each.
Exposure therefore has to be assessed on the running workload, not the repository: its network placement, whether it has a public address or sits behind a public load balancer, and what authentication stands in front of it. That requires knowing which image runs where, the problem image-to-workload binding addresses. Scoring the repository alone would give both deployments the same rank.
Exploitability signals refine the ranking rather than replace it
Within the reachable, exposed set, a few further signals set the order. Evidence that a working exploit exists and is used in the wild raises urgency far more than a theoretical score does. A component running with elevated privileges, or holding credentials or access to cardholder data, widens the blast radius if it falls. Compensating controls, such as a WAF rule, a restrictive network policy or an authentication layer the attacker must also defeat, reduce how much the flaw alone matters.
Known exploitation can justify urgent action even when reachability is unknown. Static analysis can miss dynamic calls and internal systems can be reached through lateral movement. Use all signals together rather than filtering out findings before considering exploitation evidence.
Tiering turns a thousand criticals into a plan
Applied in order, the filters turn a flat wall into tiers. Unreachable findings drop to a background tier: still tracked and still reported, but not competing for this week’s attention. Reachable findings on the internal reconciliation job form the next tier, scheduled into normal work. Reachable findings on the public checkout service rise to the top, ordered by known exploitation, privilege and proximity to sensitive data.
The top tier is short enough to read in one sitting. For the payments API it might be a request parser, an authentication library and a template engine, each reachable from the internet and each with a clear owner. That is a list an engineering lead can plan against, rather than a number to report upwards.
What risk-based vulnerability management leaves for this week
The output of the exercise should be small enough to act on now: findings that are reachable, exposed, and either actively exploited or adjacent to sensitive data. Everything else stays tracked and is re-ranked as the deployment changes. When the reconciliation job gains a public endpoint, or a refactor makes a dead code path live, its findings should climb automatically instead of waiting for someone to notice.
The same ranking belongs at the deployment boundary. A policy that blocks a release carrying a reachable, internet-facing critical is far more precise than one that counts criticals, and it stops the queue refilling as fast as the team drains it. Once a finding reaches the top tier, it still needs to reach the right team, which is where ownership routing takes over.
Key takeaways
- Separate evidenced non-reachability from unknown reachability, and keep both visible for reassessment.
- Assess exposure on the running workload, since the same image can be public in one place and internal in another.
- Combine exploitation evidence, privilege and compensating controls with reachability confidence and exposure.
- Re-rank automatically when a deployment changes, so newly exposed findings rise without manual review.
How SecurityVault approaches this
SecurityVault combines finding severity with available exploitation, source, deployment and ownership context. Reachability signals vary by analysis and language; static hints are not runtime proof. Unknown context remains a reason to investigate. Teams can inspect ranking inputs, assign an owner and enforce their own remediation and release policies.
For evaluation, select findings with different evidence quality rather than only different severities. Include a confirmed exposed path, a static hint without deployment context and a known-exploited component whose use is uncertain. Ask the team to explain the order and show how a corrected input changes it. Keep low-ranked findings available for review. The practical goal is a queue that helps owners choose the next action while exposing uncertainty, not a smaller number created by silently removing items that are difficult to analyse.
Explore Vulnerability management or talk to our team about an evaluation with your engineering, security and compliance stakeholders.