A typical mid-size software application has somewhere between fifty and several hundred open CVEs in its dependency tree at any given time. If you triaged every one of those individually, you would be doing nothing else. CVSS scores were designed to help with this: a numeric severity rating that lets you filter the High and Critical findings from the noise. The problem is that CVSS scores are calculated in isolation, and vulnerability exploitability is fundamentally about context.
A Critical CVSS score on a vulnerability in a library that is never called from a reachable code path is less urgent than a Medium score on a vulnerability in a library that is reachable from an unauthenticated endpoint and chains to a component that can write to your database. The single-finding view misses this. The exploit chain view captures it.
What CVSS Is and Is Not
The Common Vulnerability Scoring System was designed to provide a baseline severity rating that applies to a vulnerability in isolation, without reference to any specific deployment environment. CVSS v3 incorporates attack vector (network, adjacent, local, physical), attack complexity, privileges required, user interaction, scope, and impact dimensions. A score of 9.8 on a remotely exploitable, low-complexity, no-authentication-required vulnerability with high impact tells you the vulnerability is serious in a generic deployment.
What CVSS does not tell you: whether the vulnerable code path is actually reachable in your application, whether your network architecture blocks the attack vector, whether compensating controls exist, and whether exploiting the vulnerability gets an attacker to anything they care about. Those questions require context about your specific environment. CVSS intentionally abstracts that context away to produce a portable score. That abstraction is a feature for the NVD. It is a problem when you use CVSS as your prioritization mechanism.
The reachability gap
A dependency with a deserialization vulnerability may ship in your build artifact but be completely unreachable because your application never calls the affected code path. The vulnerability is real. It is in your binary. A scanner will flag it. But an attacker cannot trigger it without having a code execution path that invokes the vulnerable deserializer with attacker-controlled input. If that path does not exist in your application, the finding is low priority despite its CVSS score.
Reachability analysis requires understanding your call graph, not just your dependency manifest. It is a harder technical problem than scanning a lockfile against a CVE database. But without it, your vulnerability backlog is filled with findings that look urgent and are not, while the ones that actually matter are buried in the noise.
What an Exploit Chain Actually Looks Like
Consider a realistic multi-stage chain. An application has a public-facing API endpoint that accepts JSON payloads. The endpoint uses a Java serialization library that has a known gadget chain allowing remote code execution if attacker-controlled input reaches the deserializer. That is the entry point: one CVE, reachable from an unauthenticated endpoint, CVSS 9.8.
The RCE lands on an application server with an attached IAM role. The IAM role was created for a feature that was decommissioned, but the role itself was never removed. The role has s3:GetObject permissions on a bucket containing customer payment data exports. This is not a CVE. It is a misconfiguration. It does not appear in any CVE database. But it is the difference between an attacker achieving code execution on an isolated application server and an attacker exfiltrating customer payment data.
The full chain: public endpoint, deserialization RCE, IAM role lateral movement, S3 data exfiltration. Each link is a separate finding. None of the individual findings, evaluated in isolation, tells you what the combination enables. The chain is what matters for incident severity and remediation priority.
Why Security Tools Report Findings Instead of Chains
Most security tools report individual findings because that is the unit of analysis that maps cleanly to their detection method. A SAST scanner identifies a code pattern. A dependency scanner identifies a vulnerable package version. A cloud misconfiguration scanner identifies an IAM policy that violates a rule. Each tool operates on its own data source and its own rule set. Connecting findings across tools requires shared context about the application topology that no individual tool maintains.
The result is that security teams receive findings from multiple tools with no indication of which findings connect to each other, which connections form paths to high-value targets, and which paths are actually traversable given the network and authentication controls in place. Synthesizing this into prioritized chains requires either manual analysis from a skilled security engineer or a system that maintains the application topology graph and can trace paths across it.
Manual synthesis does not scale. A security engineer might spend a day building a complete chain for one critical finding. If your application has fifty open High or Critical findings, that math does not work. Chain analysis needs to be automated to be operationally useful.
The Impact-Anchored Triage Model
A more useful triage model starts from your high-value assets and traces backward: what paths exist to reach them, which paths pass through exploitable vulnerabilities, and which of those vulnerabilities can be reached from untrusted input sources. This reverses the usual direction of analysis.
Rather than asking "how bad is this CVE," you ask "what could an attacker reach if they exploited this CVE given where it sits in our architecture." The same CVE scores differently depending on whether it is in a component that can reach your payment processor versus a component that can only read a cache of public product listings. The CVE did not change. Your application's architecture determined the actual risk.
This model requires mapping your application's data flow and trust boundaries explicitly. What are your high-value assets (customer PII, payment data, secrets, configuration stores, privileged execution environments)? What components can directly access them? What can reach those components, and through what paths? The attack surface graph that answers these questions is the foundation for impact-anchored triage.
Practical Implications for Remediation Prioritization
Chain-based prioritization changes the remediation backlog in two important ways. First, it elevates some Medium-severity findings to immediate priority because they are the enabling step in a chain that reaches a high-value target. A medium-severity SSRF vulnerability in an internal service is not alarming in isolation. If that service runs on an EC2 instance where the IMDSv1 metadata endpoint is enabled and the instance role has broad IAM permissions, the SSRF is the key that unlocks everything else. It moves from Medium in isolation to Critical in context.
Second, it deprioritizes some High and Critical CVEs because the chain from the vulnerability to any meaningful impact is blocked by compensating controls. A high-CVSS authentication bypass on a component that is only accessible from your internal corporate network with MFA-required VPN is less urgent than the same finding on an internet-facing component.
This is not a reason to deprioritize CVE remediation indefinitely. Compensating controls change. Network topology changes. An IAM role gets permissions added. VPN access gets widened for a vendor. The chain that was blocked yesterday may be open tomorrow. Continuous evaluation of chain traversability matters as much as the initial prioritization decision.
Building Chain Awareness Into Your Security Program
Operationalizing chain-based prioritization requires three capabilities that many security programs build gradually. First, an inventory of high-value assets with their access paths. Second, a continuously maintained application topology map that includes code-level data flow, network segmentation, and cloud configuration. Third, a mechanism for evaluating whether a given CVE or misconfiguration is traversable in the current state of that topology.
The first capability is a planning activity. The second and third are where automated tooling earns its keep. A system that maintains a live topology model and continuously re-evaluates chain traversability as the codebase and infrastructure change is what enables impact-anchored triage at the speed of modern software delivery.