Source-linked AI summary
Propagation Model for SSC attacks: Why SBOM (tools) don't tell the whole truth
Ljubica Grgic, Lazar Maksimovic, Pavel Laskov
TL;DR
SBOM tools can identify vulnerable dependencies but do not determine whether vulnerable code is reachable or whether attacker-controlled input can reach a vulnerable sink. The paper introduces a four-stage propagation model and evaluates four open-source SBOM tools on three projects using Log4j. The experiment finds that existing tools primarily support structural dependency discovery and CVE matching, leaving the gap between vulnerability presence and propagation analysis.
Problem
SBOM tools identify vulnerable dependencies but cannot determine code reachability or whether attacker-controlled input reaches a vulnerable logging sink, limiting information about propagation effects.
Method
The paper introduces a four-stage propagation model and evaluates four open-source SBOM tools across the stages using three projects and Log4j.
Results
Existing SBOM tools primarily support structural dependency discovery and CVE matching, leaving a gap between Stage 2 and Stage 3 of the propagation model.
Takeaways & Limitations
Propagation-centred analysis can provide information for differentiated defence strategies and help keep cyber risk from developing into systemic risk.
Takeaways & Limitations
Prior evidence indicates that even improved SBOM accuracy does not eliminate the reported 97.5% false-positive rate, while SBOMs remain limited in representing propagation.
Abstract
from arXiv · showhide
Ensuring security of software supply chains (SSC) is indispensable in today's world of modern software practices. SBOM (tools) have been introduced as relevant building blocks to ensure the transparency of SSCs. However they have serious limitations in practices as their vulnerability detection and interpretation capacity is not sufficient to explain exploitability effects that can propagte through the whole chain. To address this gap, we propose a propagation-centred approach to SSC security and introduce a four-stage propagation model. We empirically evaluate four open-source SBOM tools against each stage using three projects and Log4j vulnerability as our test case. Our results show that current SBOM tools systematically support only Stage 1 (Structural Exposure) and Stage 2 (Vulnerability Class Presence) while Stage 3 (Code Reachability) and Stage 4 (Taint Path Analysis) require capabilities absent from the SBOM ecosystem. We argue that putting propagation effects at the centre of SSC security research is essential to prevent cyber risk evolving into systemic risks. Our research findings contribute to a future research and design of modern SSC security tools.
1 Introduction
Software supply-chain attacks can propagate through dependencies and turn cyber risk into systemic risk, while SBOM tools mainly expose vulnerable-component presence rather than exploitability or propagation.
- Software supply-chain attacks target upstream dependencies, infrastructure, update mechanisms, or third-party components rather than only end-user organizations.
- Vulnerable components can propagate through software supply chains, increasing risk across interconnected systems and beyond the initially compromised entry point.
- SBOMs improve transparency and can identify affected applications, but ubiquitous vulnerable libraries and complex dependencies can still make remediation difficult.
- Current SBOM tools generally report binary CVE presence or absence and severity, without determining whether vulnerable code is reachable or exploitable.
- The paper introduces a four-stage propagation model to locate vulnerabilities along an exploitation path and evaluate what information current tools provide.
2 Related Work
Related work identifies persistent gaps in SBOM accuracy, reachability, exploitability, and whole-ecosystem propagation analysis. The paper therefore positions propagation effects as information that existing SBOM-focused approaches do not adequately capture.
- Practitioners criticize SBOMs as static inventory and vulnerability-matching tools that often satisfy compliance without revealing supply-chain risk or component security status.
- Even with lock-file-based accuracy improvements, prior research reported a 97.5% false-positive rate that reachability analysis did not resolve through accuracy alone.
- The literature review converges on propagation effects as a missing element in effective software-supply-chain security strategies.
- Existing research highlights unresolved reachability, incomplete dependency tracking across operational levels, and limits on impact or lateral-movement analysis.
- Graph-based and propagation-oriented approaches improve visibility or assess propagation impact, but some do not determine whether vulnerable code is actually reachable.
3 Methodology
The methodology applies a dynamic, four-stage propagation model to four open-source SBOM tools using Log4j as the experimental vulnerability. The model structures analysis around where exploitation may progress in the supply chain.
- The study introduces a dynamic propagation model with four stages to identify where a vulnerability is located along a cascade path.
- The experiment runs four SBOM tools through all stages of the proposed propagation model using Log4j.
1 Structural Exposure
Structural exposure concerns whether the vulnerable JndiLookup class is present on the application classpath. Presence alone does not establish that the vulnerable functionality is invoked.
- The JndiLookup class is physically present on the application classpath and has not been disabled or removed.
- Class presence is prerequisite evidence, not proof that the vulnerable functionality is invoked.
2 Vulnerable Class Presence
The vulnerable JndiLookup.lookup() method is reachable from the application's call graph when an execution path connects application code to that function.
- JndiLookup.lookup() is reachable when the application call graph contains at least one execution path to the vulnerable function.
3 Code Reachability
User-controlled input can provide an attack vector when it flows into a Log4j logging call, allowing injection of a malicious JNDI expression.
- User-controlled HTTP headers, query parameters, or form fields can flow into a Log4j logging call and provide an injection vector.
4 Taint Path Confirmation
The experiment evaluates whether open-source SBOM tools detect Log4Shell and assess its exploitability or dynamic propagation. It examines four selected tools and adds CodeQL and Semgrep for analysis beyond SBOM scanning.
- 4 Taint Path Confirmation: The experiment asks whether open-source SBOM tools detect CVE-2021-44228 and assess exploitability or dynamic propagation.
- 4 Taint Path Confirmation: Hypothesis 1 predicts identical CRITICAL flags for exploitable and practically non-exploitable applications, regardless of JndiLookup invocation.
- 4 Taint Path Confirmation: Four widely used open-source SBOM tools were selected based on prior literature, with CodeQL and Semgrep added for the experiment.
- 4 Taint Path Confirmation: Syft generates SBOMs, Grype scans them for vulnerabilities, and Trivy combines SBOM and vulnerability-scanning functions.
- 4 Taint Path Confirmation: Log4Shell was chosen because Log4j is widely deployed, propagated structurally into 17,000+ Maven Central packages, and spread as an exploit across hundreds of millions of devices.
4 Experimental Setup
The experiment compares propagation evidence across three Java projects and evaluates progressively stronger requirements, from vulnerable-component presence to class presence, reachability, and taint flow.
- 4 Experimental Setup: Apache Solr 8.11.0, Spring Boot 2.5.0, and Ghidra 10.0.4 represent different dependency and packaging models and each include vulnerable Log4j.
- 4 Experimental Setup: The projects enable comparison across Maven metadata, Gradle context, resolved JARs, and packaged application distributions.
- 4 Experimental Setup: Stage 1 confirms log4j-core component presence; SBOM tools generally detect it, but results depend strongly on the input method.
- 4 Experimental Setup: Stage 2 requires proof that org/apache/logging/log4j/core/JndiLookup.class exists inside the analyzed JAR.
- 4 Experimental Setup: Stage 3 requires a call path from application code to JndiLookup.lookup(), which SBOM tools and vulnerability scanners did not provide.
- 4 Experimental Setup: CodeQL tested direct calls and references to JndiLookup; all three projects returned no direct matches in analyzed source code.
- 4 Experimental Setup: Stage 4 asks whether user-controlled input reaches a logging sink, but SBOM tools provided no source-to-sink taint-flow evidence.
- 4 Experimental Setup: Semgrep identified candidate flows from request-controlled values to logging APIs, without proving exploitation.
5 Discussion and Conclusions
The paper places propagation effects at the centre of SSC security through a four-stage model, showing that existing SBOM tools stop before assessing reachability and cascading compromise. This missing information makes vulnerability findings less actionable for controlling SSC risk.
- Propagation-Centred approach: The four-stage propagation model identifies what information is needed to determine where a vulnerability currently lies on its propagation path.The approach begins from propagation occurrence and aims to make exploitability risk controllable.
- Conclusion of our experiment: Existing SBOM tools primarily support structural dependency discovery and CVE matching, but do not systematically assess reachability, call-graph exposure, or cascading compromise.The experiment places their capability mainly before the transition from Stage 2 to Stage 3.
- Conclusion of our experiment: The Stage 2–Stage 3 gap explains why SBOM tools flag vulnerabilities in unreachable code and produce systematically high false-positive rates.The missing information concerns class-level presence, application call-graph reachability, and exposure to attacker-controlled input.
- Propagation-Centred approach: Understanding propagation effects can support differentiated defence strategies and help prevent cyber risk from developing into systemic risk across an organisation and its ecosystem.The paper presents this as the security significance of obtaining propagation information.