Software supply chain (SSC) security has become a regulatory and operational priority. The US executive order on cybersecurity, the EU Cyber Resilience Act, and NIS2 all require organizations to understand what components are in their software and whether known vulnerabilities affect them. Software Bill of Materials (SBOM) tools have emerged as the primary mechanism for achieving this transparency. They enumerate components, map dependencies, and cross-reference known vulnerabilities. But a new paper argues that this approach systematically misses the part of supply chain security that actually matters: whether a vulnerability can propagate from a vulnerable component to the running application.
SBOM Tools Answer the Wrong Question
An SBOM tool can tell you that your application depends on Log4j. It can tell you that Log4j contains a known vulnerability (CVE-2021-44228). What it cannot tell you is whether the vulnerable code path in Log4j is actually reachable from your application's code. A component can sit in a dependency tree, listed in the SBOM, flagged by the vulnerability scanner, and yet never be called during execution. The vulnerable function might be in a module your application does not import, or in a code path that your specific usage never triggers. The SBOM treats all components as equally relevant regardless of whether the vulnerable code is reachable.
This matters because the Log4j vulnerability itself demonstrated the problem at scale. Millions of systems were flagged as vulnerable because they contained Log4j in their dependency tree. But not all of those systems were actually exploitable. The vulnerability only triggers when a specific logging pattern is processed, and not every application that includes Log4j invokes that pattern. The difference between "has the component" and "can reach the vulnerable code" is the difference between a theoretical risk and an actual exploit.
A Four-Stage Propagation Model
The paper proposes a four-stage model for understanding how vulnerabilities propagate through software supply chains. Each stage represents a deeper level of analysis that current SBOM tools do not address.
Stage 1 is Structural Exposure. This is what SBOM tools do: enumerate the components in a software product, map their dependency relationships, and identify which components are present in the build. It answers the question "is the vulnerable component in the tree?" This is the baseline of supply chain transparency.
Stage 2 is Vulnerability Class Presence. This extends structural exposure by checking whether the vulnerable component contains a known vulnerability matching a CVE or similar identifier. Most SBOM tools cross-reference component versions against vulnerability databases like NVD. This answers "does this component have a known vulnerability?"
Stage 3 is Code Reachability. This asks whether the vulnerable code path in the component is actually callable from the application's code. A component might contain a vulnerable function, but if the application never calls that function (or even imports the module containing it), the vulnerability is not exploitable in practice. Reachability analysis requires understanding the call graph from the application entry points through the dependency chain to the specific vulnerable function.
Stage 4 is Taint Path Analysis. This goes beyond reachability to ask whether user-controlled input can actually reach the vulnerable function through the call chain. Even if the vulnerable code is reachable, it might only be callable with internally generated data that an attacker cannot influence. Taint analysis traces data flow from external inputs (HTTP requests, file uploads, API calls) through the application to the vulnerable function, determining whether an attacker can control the values that trigger the vulnerability.
Evaluating SBOM Tools Against the Model
The authors evaluate four open-source SBOM tools against each stage using three real-world projects and the Log4j vulnerability as a test case. The evaluation measures what each tool can and cannot report at each stage of the propagation model.
The results are clear: current SBOM tools systematically support only Stage 1 and Stage 2. They can enumerate components and flag known vulnerabilities in those components. But they cannot determine whether the vulnerable code is reachable from the application, and they cannot trace taint paths from user input to the vulnerable function. Stage 3 and Stage 4 require capabilities that are absent from the SBOM ecosystem.
This means that when an SBOM tool reports a vulnerability, it is reporting that the component is present and has a known CVE, not that the application is actually exploitable. Every flagged vulnerability is treated as equally urgent regardless of whether it is reachable or exploitable. The tool provides a list of potential exposures without the analysis needed to prioritize them.
Why This Matters for Practice
The practical consequence is twofold. First, organizations face alert fatigue. When every dependency with a known CVE is flagged regardless of reachability, security teams spend time triaging vulnerabilities that are not actually exploitable in their specific context. The volume of alerts overwhelms the capacity to respond to genuine risks.
Second, the false sense of completeness is dangerous. An organization that runs an SBOM tool and finds no flagged vulnerabilities might conclude that its supply chain is secure. But the tool only checked stages 1 and 2. A vulnerability could exist in a component that the tool flagged as clean because the CVE database has not been updated, or the vulnerability could be reachable through a path the tool cannot analyze. The SBOM gives a partial picture that masquerades as a complete one.
The paper argues that putting propagation effects at the center of software supply chain security research is essential to prevent cyber risk from evolving into systemic risks. When a single vulnerable component like Log4j affects millions of applications, the question is not whether those applications contain the component, but which ones are actually exploitable. Without reachability and taint analysis, that question cannot be answered.
The Gap Between SBOM and Actual Security
Reachability analysis is technically difficult. It requires building call graphs that span application code and library code, handling dynamic dispatch, reflection, and indirect calls. It must account for different build configurations that might include or exclude modules. It needs to understand the semantics of the programming language well enough to determine whether a function call actually reaches the vulnerable code path.
Taint analysis is even harder. It requires tracking data flow from external sources through transformations, conditionals, and function calls to determine whether attacker-controlled values can reach a sensitive sink. This is a well-studied problem in static analysis, but applying it across dependency boundaries, in polyglot codebases, and at the scale of modern software supply chains remains an open challenge.
Neither capability exists in the current SBOM tooling ecosystem. The SBOM standard (SPDX, CycloneDX) defines formats for listing components and their relationships, but does not include specifications for reachability or taint analysis. The tools that implement these standards focus on enumeration and vulnerability matching, not on the deeper analysis that propagation modeling requires.
What Needs to Change
The paper contributes a research framework for thinking about what modern software supply chain security tools need to provide. The four-stage model defines the gap between current practice and what is needed for meaningful vulnerability prioritization. Tools that stop at Stage 2 provide transparency about what is in the software but not about what is exploitable.
For practitioners, the immediate takeaway is to treat SBOM-based vulnerability reports as a starting point, not an endpoint. A flagged CVE in an SBOM does not mean the application is vulnerable. It means the component is present. Before allocating remediation resources, determine whether the vulnerable code is reachable and whether user input can trigger it. This requires additional analysis beyond what SBOM tools provide, but it is necessary for effective prioritization.
For the research community, the paper establishes that propagation-centered analysis is a distinct and necessary capability beyond SBOM transparency. The four-stage model provides a structured way to evaluate future tools: do they only enumerate (stages 1-2), or do they analyze exploitability (stages 3-4)? The gap between these two levels is where the real security value lies.
The paper was presented at ARES 2026 (Availability, Reliability and Security) and published in Lecture Notes in Computer Science. It addresses a gap that regulatory requirements have created: organizations are being asked to produce SBOMs and manage supply chain risks, but the tools available to them do not support the analysis that risk management actually requires.