From Component Snapshots to Lifecycle Traces: Agent-Based Software Composition Analysis
arXiv:2609.18391v1 [cs.SE] 16 Sep 2026
Chaofan Li, Zhengduo Xue, Chengxiang Li, Yutao Hu, Yueming Wu, Deqing Zou Huazhong University of Science and Technology, China
Abstract
To identify third-party components and their dependencies, software composition analysis (SCA) and software bills of materials (SBOMs) have been widely adopted for component identification, vulnerability detection, and supply-chain auditing [38, 48, 50]. Existing Approach: Snapshot-oriented SCA. Existing SCA techniques typically analyze a particular software representation or execution state, such as manifests and lockfiles in source code, resolved dependencies [56] in the build environment [24, 39, 57], release artifacts [1], container images [22], or runtime loading information [24, 39]. Although these approaches use different detection techniques, they follow the same analysis paradigm: given a software state, they recover the composition observable in that state. Their outputs are therefore component snapshots, capturing the components and dependency relationships visible at a particular stage. Limitation of Snapshot-oriented SCA. Software composition does not remain static throughout software development and delivery [25]. As software moves from source code through build, release, deployment, and execution, components may be resolved, introduced, pruned, repackaged, or transformed, changing both the resulting composition and the security-relevant information available for analysis. We therefore focus on five lifecycle stages directly associated with such composition evolution: Code, Build, Release, Deploy, and Runtime. These transformations can produce substantially different component sets across stages [32]. For example, Druid v1.2.28 contains 102, 522, 76, 78, and 58 components at the Code, Build, Release, Deploy, and Runtime stages, respectively [2]. Consequently, a snapshot at any single stage cannot capture how software composition evolves throughout the lifecycle. Different snapshots also preserve complementary security information. Earlier stages typically retain dependency origins and introduction paths, whereas later stages provide stronger evidence about which downstream states a component reaches [12, 46]. At Build, dependency resolution can recover direct and transitive dependency chains and identify which upstream dependency introduces a compo-
Software supply-chain security requires accurate identification of third-party components and an understanding of how they evolve from development to execution. Existing software composition analysis (SCA) approaches examine manifests, build environments, release artifacts, containers, or runtime states, but typically produce only stage-specific views of software composition. As dependencies are resolved, removed, repackaged, and transformed across lifecycle stages, a single snapshot cannot capture both where a component originates and where it ultimately ends up. Combining snapshots from multiple stages still leaves their cross-stage relationships unresolved. We present SCA-Agent, an agent-based approach to lifecycle-aware SCA that reconstructs evidence-backed component lifecycle traces across Code, Build, Release, Deploy, and Runtime. SCA-Agent adaptively explores project-specific analysis paths, gathers stage-specific evidence, and correlates observations across stages to recover component identities, versions, introduction paths, propagation relationships, and final lifecycle states. We evaluate SCA-Agent on 105 realworld projects from the Java, JavaScript, and Python ecosystems. SCA-Agent achieves the highest component detection F1 across all lifecycle stages and ecosystems. For vulnerability exposure assessment, it reaches an F1 score of 96.69%, exceeding the best traditional SCA tool by 18.76 percentage points. These results show that lifecycle-aware SCA supports traceable component provenance and more accurate software supply-chain risk assessment.
1
Introduction
Background. Modern software systems increasingly rely on third-party components and open-source dependencies, making the software supply chain an integral part of software development and delivery [33, 34, 51]. Components are incorporated into downstream software through direct or transitive dependencies, allowing vulnerabilities to propagate along dependency relationships and ultimately affect applications. 1
nent [27, 45, 59]. Yet Build alone cannot determine whether that component survives packaging and reaches release or deployment [12, 46]. Runtime observations provide stronger evidence that a component participates in an execution [11], but they are workload-dependent and often lack the dependency context required to trace the component back to its introducer [11, 42]. Hence, no single snapshot can simultaneously determine a component’s Origin, where it is introduced, and its Fate, which downstream lifecycle stages it reaches. Beyond Multiple Snapshots. A natural alternative is to analyze multiple lifecycle stages [17]. Simply collecting multiple snapshots still leaves their observations disconnected. Components may undergo version resolution, repackaging, and representation transformations, so source dependencies, build dependencies, artifact files, and runtime modules do not have a natural one-to-one correspondence [42]. Connecting a component’s Origin to its Fate therefore requires recovering how it is carried, transformed, or eliminated as software transitions across stages. We refer to these cross-stage relationships as component Propagation. Propagation enables two securityrelevant analyses: determining whether an early-stage vulnerable dependency reaches downstream software, and tracing a vulnerable component observed at a later stage back to the dependency that introduced it. Thus, the fundamental limitation of snapshot-oriented SCA is not merely incomplete coverage, but the absence of cross-stage relationships that connect component provenance with its downstream state. Key Insight. We therefore extend the unit of analysis in SCA from independent component snapshots to component lifecycle traces. A lifecycle trace connects a component’s Origin to its Fate through evidence-backed Propagation relationships. It captures where a component is introduced, how it propagates across lifecycle stages, and which downstream states it reaches. This representation supports both forward reasoning about whether a dependency reaches downstream software and backward tracing from a later-stage component to its introducer. Main Challenges. Reconstructing component lifecycle traces presents two key challenges. First, lifecycle analysis paths are project-specific and progressively discovered during execution. Projects differ substantially in build systems, module structures, artifact formats, and deployment mechanisms, while later analysis targets often depend on objects discovered in earlier steps. Second, lifecycle evidence must be associated across heterogeneous software representations. Manifest dependencies, resolved dependencies, artifacts, and runtime modules expose different forms of evidence [15], while component versions and representations may change across stages. Accurate lifecycle reconstruction therefore requires both adaptive lifecycle exploration and cross-stage reasoning over distributed evidence. Our Approach. To reconstruct lifecycle traces under projectspecific and dynamically discovered analysis paths, we design and implement SCA-Agent, an agent-based system for
lifecycle-aware software composition analysis. SCA-Agent adaptively explores lifecycle stages and analysis objects according to the target project’s structure and intermediate observations. It collects stage-specific evidence across Code, Build, Release, Deploy, and Runtime, then performs crossstage reasoning to resolve component identities, versions, and propagation relationships. By connecting these observations, SCA-Agent reconstructs evidence-backed lifecycle traces describing each component’s Origin, Propagation, and Fate, and incorporates them into a lifecycle-aware SBOM. Evaluation. We evaluate SCA-Agent on 105 real-world opensource projects across Java, JavaScript, and Python. Our analysis confirms substantial component evolution across lifecycle stages. SCA-Agent reconstructs component lifecycle traces with Origin Accuracy ranging from 84.44% to 99.11% and Fate Accuracy from 70.94% to 97.95% across the three ecosystems. For lifecycle-aware vulnerability exposure assessment, it achieves an F1 score of 96.69%, outperforming the best traditional SCA tool by 18.76 percentage points. Ablation studies further show that adaptive planning and cross-stage reasoning are important for lifecycle reconstruction. Contributions. The contributions are summarized as follows: • We propose Lifecycle-aware SCA, extending software composition analysis from isolated component snapshots to lifecycle traces that connect component Origin, Propagation, and Fate. • We design and implement SCA-Agent, which combines adaptive lifecycle exploration, multi-stage evidence collection, and cross-stage reasoning to reconstruct evidence-backed component lifecycle traces. • We systematically evaluate SCA-Agent on 105 real-world open-source projects and demonstrate its effectiveness in lifecycle reconstruction and lifecycle-aware vulnerability exposure assessment.
2 2.1
Motivation and Conceptual Model Motivating Example
To illustrate the limitations of snapshot-based software composition analysis in software supply-chain security assessment, we take a real-world project incorporating D RUIDv1.2.28 as our motivating example to examine how vulnerable components manifest across diverse software states, as shown in Figure 1. Existing SCA tools typically generate component snapshots from a particular class of software objects, such as resolved dependencies, release artifacts, or runtime environments, and perform vulnerability detection based on these snapshots. However, identifying a component in a single snapshot does not fully characterize its security impact on the final software [7]. Path A: Missing Fate Overestimates Vulnerability Exposure. In the component snapshot generated at the Build stage, dependency resolution identifies com.alibaba:[email protected] 2
These two paths show that the limitation of snapshot-based SCA is not merely incomplete component coverage, but the lack of lifecycle information required to support complete security assessment from any single composition snapshot. Earlier-stage snapshots can reveal where a component is introduced, but cannot determine whether it ultimately reaches the delivered software; later-stage snapshots can confirm its final presence, but often cannot recover the original introduction relationship. Therefore, software composition analysis should answer not only whether a component exists, but also two additional questions: where it comes from and where it ultimately ends up across subsequent software states.
Path A: Missing Fate Overestimates Vulnerability Exposure code
build
release
deploy
runtime
dubbo 2.5.3
dubbo 2.5.3
dubbo 2.5.3
dubbo 2.5.3
dubbo 2.5.3
CVE
CVE
Origin
Fate
Absent
Absent
Absent
Path B: Missing Origin Limits Actionable Remediation code
build
springboot -starteractuator 2.7.18
spring-boot-starter -actuator 2.7.18
Upstream Dependency
spring-boot-actuator -autoconfigure 2.7.18 jackson-databind 2.13.5 CVE
Origin
release
deploy
runtime
jacksondatabind 2.13.5
jacksondatabind 2.13.5
jacksondatabind 2.13.5
CVE Propagation
CVE Propagation
CVE Fate
2.2 Software Composition as Lifecycle Context Building on the motivating case above, we define the supplychain-security-relevant state of a component throughout the software lifecycle as its component security context, characterized along two complementary dimensions: Origin and Fate. Origin describes through which dependency relationship or software process a component is introduced into the system, while Fate captures how the component persists across subsequent lifecycle stages and where it ultimately ends up. Compared with a composition snapshot that only records whether a component is present in a particular software state, the security context further connects the component’s introduction source with its final state. Recovering such a security context requires component evidence that supports both Origin and Fate. However, this evidence is not concentrated in any single software object; instead, it emerges progressively as the software transitions from development to delivery and execution. A component’s introduction source is typically preserved in dependency declarations, build-resolution results, and dependency relationships [27], whereas its later state must be confirmed through its actual presence in release artifacts, deployment environments, and runtime states [54, 55]. Therefore, fully reconstructing a component’s security context requires organizing and correlating these distributed composition evidences along the software lifecycle. Therefore, we first identify the lifecycle states that produce composition evidence with distinct semantics. Rather than directly adopting the complete DevSecOps lifecycle, we abstract it into key states that represent distinguishable software composition states [28]. A typical DevSecOps lifecycle includes stages such as Plan, Code/Develop, Build, Test, Release, Deploy, Operate, and Monitor. The Plan stage does not yet produce analyzable dependency composition; Test typically reuses dependencies resolved and artifacts produced during Build and therefore does not introduce a new primary composition state. Operate and Monitor, meanwhile, jointly reflect the software’s actual post-deployment execution state. Based on this abstraction, we summarize the lifecycle states directly relevant to software composition evolution into five
Figure 1: Motivating Example
together with its associated vulnerabilities, causing snapshotbased vulnerability detection to report it as a potential risk. However, examining subsequent software states reveals that [email protected] does not appear in the Release artifact, Deploy environment, or Runtime state. In other words, the Build snapshot can confirm the presence of the vulnerable component in the build dependency graph, but cannot determine whether it ultimately reaches the delivered software. This is not an isolated case: among the 173 CVE matched at the Build stage of this project, 94 (54.3%) correspond to vulnerable components that do not appear in the Release artifact. This demonstrates that detecting a vulnerability in a build snapshot does not necessarily imply that the vulnerability is ultimately exposed in the delivered software. Path B: Missing Origin Limits Actionable Remediation. A different limitation arises for vulnerable components that do reach the final software. In this project, com.fasterxml.jackson.core:[email protected] is a transitive dependency that persists across subsequent software states, allowing Release, Deploy, or Runtime snapshots to confirm that the vulnerable component is present in the delivered software. However, these later-stage snapshots only indicate that the component exists; they do not explain why it appears in the project. Build-stage dependency resolution further reveals that [email protected] is introduced transitively through [email protected], which is itself introduced by [email protected]. Thus, jackson-databind is not directly declared by the project, but is introduced indirectly through an upstream Spring Boot dependency chain. For such transitive dependencies, identifying a vulnerable component from a later-stage snapshot alone does not directly reveal an actionable remediation point. Developers must further trace its dependency origin to locate the upstream direct dependency that can actually be upgraded [39, 41]. 3
Figure 2: Overview of SCA-Agent. stages: Code, Build, Release, Deploy, and Runtime. Because these stages correspond to different software states, they expose substantially different forms of component evidence and therefore provide different levels of support for recovering Origin and Fate. This suggests that a component security context does not reside in any single lifecycle stage, but must instead be reconstructed from evidence distributed across multiple stages. A single-stage SCA result typically provides only a composition snapshot of one software state: it can indicate whether a component is present, but cannot simultaneously explain its Origin and Fate. Therefore, software composition analysis should move beyond static component snapshots toward a lifecycle-aware security context that correlates evidence across lifecycle stages.
3
Approach
3.1
Overview
SCA-Agent consists of four interconnected steps: • Adaptive Lifecycle Planning. SCA-Agent dynamically plans the lifecycle analysis path based on the target project’s structure, build configuration, and analysis feedback, and identifies the software objects at different stages that may contain component information. • Stage-aware Evidence Collection. SCA-Agent collects component evidence from different lifecycle stages and preserves contextual information including the stage at which the evidence is produced, its source object, and the associated evidence path. • Cross-stage Component Reasoning. SCA-Agent correlates component evidence across stages, resolves component identities and versions, and reconstructs component lifecycle traces from introduction to final state. • Lifecycle-aware SBOM Construction. SCA-Agent organizes the reconstructed component lifecycle information into a traceable software composition view, augmenting a traditional SBOM with component lifecycle context.
To address the limitation of traditional SCA in simultaneously determining a component’s Origin and Fate, SCA-Agent dynamically determines which lifecycle stages and analysis targets should be explored based on the target project’s structure, build workflow, and analysis feedback. It then collects component-related evidence from different lifecycle stages while preserving the corresponding stage and provenance context. By further correlating component information across stages, SCA-Agent reconstructs each component’s introduction source, propagation process, and final lifecycle state, and ultimately produces an SBOM enriched with lifecycle context.
3.2
Adaptive Lifecycle Planning
Adaptive Lifecycle Planning addresses the challenge that a project’s lifecycle path is not known in advance. Projects can differ substantially in language ecosystem, build system, release process, and deployment environment, causing component-related evidence to be distributed across different lifecycle stages and software objects. Therefore, SCA-Agent does not follow a fixed analysis workflow. Instead, it dynamically explores the lifecycle path based on the target project 4
3.3
structure and newly observed information during execution, and determines which stage and object should be analyzed next. This process consists of two closely connected steps: Repository Understanding and Initial Planning and Adaptive Planning and Execution.
Stage-aware Evidence Collection
Stage-aware Evidence Collection addresses the challenge that component evidence is distributed across different lifecycle stages. Because components take different observable forms at different stages, evidence from any single stage is insufficient to simultaneously determine a component’s Origin and Fate. Therefore, based on the analysis objects identified by Adaptive Lifecycle Planning, SCA-Agent collects component evidence with explicit stage semantics across multiple lifecycle stages. SCA-Agent’s base prompt incorporates ecosystem-specific dependency resolution methods, tool usage strategies, and basic analysis rules. According to the current lifecycle stage and analysis target, SCA-Agent dynamically selects the corresponding analysis operations to extract component-related information from Code, Build, Release, Deploy, and Runtime. During execution, SCA-Agent selects and adapts parsing scripts for the target object to obtain observable information such as component identity, version, and dependency relationships. For example, the Code stage exposes dependency declarations, the Build stage provides resolved dependency information, while the Release, Deploy, and Runtime stages further reveal whether components reach the final software environment. Because component representations and evidence granularity differ across stages, SCA-Agent does not directly merge cross-stage results during evidence collection. Instead, it preserves each raw observation together with contextual metadata, including the source stage, evidence source, and evidence path. Finally, the outputs from each stage are organized as stagespecific evidence. This representation preserves the local state of a component at a particular lifecycle stage while enabling each analysis result to be traced back to the corresponding file, artifact, or runtime object, providing the foundation for subsequent cross-stage reasoning.
Repository Understanding and Initial Planning. SCAAgent first inspects the target repository to identify engineering information relevant to software composition analysis, including directory structure, source-code types, dependency descriptor files, build configurations, release scripts, and deployment files. Based on this information, SCA-Agent infers the project’s language ecosystem, package management scheme, build system, and potential software delivery path. For each supported ecosystem, SCA-Agent’s base prompt incorporates lifecycle knowledge such as common dependency resolution mechanisms, build workflows, artifact types, and analysis-tool usage strategies. SCA-Agent then combines this ecosystemlevel prior knowledge with project-specific characteristics to construct an initial lifecycle exploration plan, identifying candidate source dependencies, build outputs, release artifacts, deployment objects, and runtime environments for subsequent analysis. The goal of this step is not to directly recover the final component set, but to establish the project’s lifecycle context and locate where component evidence may emerge. Adaptive Planning and Execution. During execution, SCAAgent performs analysis actions according to the current plan and continuously updates its analysis state with the observations produced by each step. When new modules, build outputs, release packages, container images, deployment configurations, or runtime objects are discovered, they are added to the analysis state and used to guide subsequent lifecycle exploration. When the current analysis path can no longer make progress, or when the current object does not provide sufficient component information, SCA-Agent revises its plan based on error logs, project configurations, and the accumulated analysis state. Replanning may involve adjusting execution parameters, selecting alternative tools, switching analysis targets, or exploring newly discovered lifecycle objects. As a result, SCA-Agent forms a closed-loop planning–execution– observation–replanning process, allowing the analysis workflow to evolve dynamically according to the specific project and previously collected evidence rather than relying on a fixed lifecycle script. To prevent unrecoverable projects from causing unbounded exploration, SCA-Agent limits this process to at most 30 iterations.
3.4
Cross-stage Component Reasoning
Cross-stage Component Reasoning is the core module in SCAAgent for recovering component lifecycle context. Its goal is to associate local component observations across different lifecycle stages and reconstruct the complete trajectory of a component from introduction to final state. Because component evidence from different stages may differ in naming conventions, version representations, and dependency context, SCA-Agent divides this process into two steps: Identity and Version Resolution and Lifecycle Trace Reconstruction. Identity and Version Resolution. This step first determines whether component observations from different lifecycle stages refer to the same software entity. Specifically, identity normalization maps package coordinates, file names, artifact metadata, and runtime records from different stages to a unified component identity. Through this process, SCA-Agent
Finally, Adaptive Lifecycle Planning outputs the identifiable lifecycle stages of the target project, the corresponding analysis objects at each stage, and the derivation relationships among these objects, providing the context required for subsequent stage-aware evidence collection. Stage-aware Evidence Collection step. 5
reconciles heterogeneous component representations across stages into unified software component entities. It then determines which concrete version of each component is ultimately used. Version resolution combines sourcelevel declarations, dependency resolution results, and downstream artifact information to resolve variables, inheritance relationships, and version ranges into concrete component versions. Dependency conflict resolution further handles cases in which the same component is introduced through multiple dependency paths with different candidate versions. SCA-Agent uses the build system’s actual resolution result together with downstream lifecycle evidence to determine the version that is ultimately selected and delivered, while preserving its original declaration and dependency source. Lifecycle Trace Reconstruction. After resolving component identities and versions, SCA-Agent reconstructs how each component propagates through the software lifecycle. It first determines how the component is introduced based on stagespecific evidence, including direct declarations in source code, indirect introduction through dependencies, or components that first appear at later lifecycle stages. By analyzing the stage in which a component first appears together with its dependency context, SCA-Agent recovers its Origin. SCA-Agent then correlates component evidence across lifecycle stages and combines this evidence with derivation relationships among analysis objects to reconstruct crossstage propagation, determining how a component moves from source code and the build environment into release artifacts, deployment environments, and runtime objects. Finally, it uses evidence from subsequent stages to infer the component’s Fate, including whether it is removed during later processing, included in the final delivered artifact, deployed, or loaded or executed at Runtime. Ultimately, Cross-stage Component Reasoning transforms component observations from lifecycle stages into evidence-backed lifecycle traces, which serve as the input to Lifecycle-aware SBOM Construction.
3.5
Finally, SCA-Agent outputs a unified Lifecycle-aware SBOM that extends traditional static component inventories with additional information about where a component is introduced, which lifecycle stages it passes through, and what final state it reaches. This enhanced representation provides a foundation for downstream component auditing, vulnerability analysis, and software supply chain security analysis.
4
Experiment
Our experiments focus on answering the following Research Questions (RQs): • RQ1: How do software dependencies evolve across lifecycle stages? • RQ2: How necessary are the components of SCA-Agent? • RQ3: How effectively does SCA-Agent identify software components across lifecycle stages? • RQ4: How accurately does SCA-Agent recover dependency component lifecycle trajectories? • RQ5: Does lifecycle context improve software supplychain vulnerability exposure assessment?
4.1
Experimental Setup
Lifecycle-aware Ground Truth Construction. We collect open-source projects from GitHub across three ecosystems: Java, JavaScript, and Python. We require each project to have at least 100 GitHub stars to ensure a reasonable level of maturity and practical adoption. We then manually validate the collected projects and exclude those for which complete lifecycle analysis cannot be performed due to build failures, missing release artifacts, abnormal dependency management, or toolchain incompatibility. Finally, we retain 35 projects for each language ecosystem, resulting in a total of 105 experimental subjects. The selected projects cover a variety of software categories, including Web frameworks, build tools, enterprise applications, microservice systems, and data science libraries, and exhibit substantial diversity in project size, dependency scale, and build complexity. For each project, we perform a complete analysis across the five lifecycle stages defined in this work, namely Code, Build, Release, Deploy, and Runtime, and collect the thirdparty dependencies actually present at each stage. Specifically, at the Code stage, we comprehensively collect and parse dependency declaration files in the project whenever possible. At the Build stage, we record the dependency components actually resolved and downloaded during the build process. At the Release stage, we analyze the generated release artifacts. At the Deploy stage, we identify relevant components in the actual deployment environment by combining information from Dockerfiles, deployment configurations, and project documentation. At the Runtime stage, we manually construct
Lifecycle-aware SBOM Construction
Lifecycle-aware SBOM Construction organizes the unified component view produced by Cross-stage Component Reasoning into the final Lifecycle-aware SBOM. SCA-Agent first generates fundamental software composition information, including component identity, version, and dependency relationships, following standard SBOM formats. On top of these standard fields, each dependency entry is further augmented with its recovered complete lifecycle trajectory. Specifically, in addition to standard SBOM fields, each dependency entry records its lifecycle states across Code, Build, Release, Deploy, and Runtime stages, the source of dependency introduction, and the propagation relationships among different stages. Furthermore, each entry is associated with the corresponding stage-specific evidence and evidence paths that support these lifecycle decisions. 6
inputs that cover as much project functionality as possible, execute the project, and identify dependencies that are actually loaded or used through runtime monitoring. In total, we obtain 58,211 stage-level dependency instances. Based on the above process, we first organize the dependencies collected at each lifecycle stage into the stage-level component ground truth, which characterizes the actual software composition at different lifecycle stages and serves as the reference for subsequent stage-level component detection and lifecycle evolution analysis. Second, we further correlate the presence states, dependency origins, and cross-stage propagation relationships of the same component across different stages to construct the lifecycle trace ground truth. This ground truth records the introduction origin and final lifecycle state of each component and is used to evaluate the accuracy of recovering component Origin and Fate. Finally, we associate the components confirmed at each stage with their corresponding vulnerability information to construct the CVE-stage ground truth. Each (CVE, stage) pair is treated as a basic annotation unit, indicating the actual presence and exposure state of a vulnerability at a specific lifecycle stage, and is used to evaluate the impact of lifecycle context on software supply chain vulnerability detection. In total, we construct 17,482 CVE-stage ground-truth instances. To ensure ground-truth reliability, three annotators independently extract and review dependencies at each lifecycle stage. Disagreements are resolved through discussion and consensus. The resulting annotations form the stage-level component sets, lifecycle-level component sets, and component lifecycle trace ground truth. Baseline Configuration. To evaluate SCA-Agent against existing SCA approaches, we select Syft [3], Microsoft SBOM Tool [26], and cdxgen [35] as baselines. All three are representative open-source SCA/SBOM tools but adopt different component discovery strategies. Syft primarily scans software artifacts for components, Microsoft SBOM Tool detects components from project files and build-related information, and cdxgen recovers direct and transitive dependencies mainly from manifests, lockfiles, and package-manager information. Together, they represent artifact scanning, project dependency detection, and package-manager-driven component recovery, providing representative baselines for comparing different SCA strategies. SCA-Agent Implementation. SCA-Agent is implemented based on the Claude Agent framework [4] and organizes its lifecycle analysis capabilities in a skill-driven manner. Specifically, we design a dedicated skill for each of the four core analysis steps described in our approach, with corresponding domain knowledge, processing strategies, and auxiliary scripts configured in their references. This design enables the agent to perform lifecycle planning, stage-aware analysis, cross-stage reasoning, and final result construction following the defined analysis workflow. In our experiments, we use Claude-Sonnet-4.6 [5] as the underlying language model
Table 1: Distribution of component observations across lifecycle stages. Language
Code
Build
Release
Deploy
Runtime
Total
Python JavaScript Java
993 1145 1753
646 21784 10285
748 370 6945
678 1075 7056
388 726 3619
3453 25100 29658
Total
3891
32715
8063
8809
4733
58211
and maintain the same model configuration across all experiments. SCA-Agent ultimately produces a Lifecycle-aware SBOM conforming to the CycloneDX standard, recording both component information and its lifecycle context to support subsequent lifecycle reconstruction and security analysis. Evaluation Metrics. To evaluate the lifecycle analysis capability of SCA-Agent, we define task-specific evaluation metrics for different analysis objectives. For lifecycle component evolution, we use Added, Removed, Retained, and Jaccard Similarity to characterize component changes and set overlap between adjacent lifecycle stages. For stage-level component identification and mechanism ablation experiments, predicted components are matched against the ground truth of the corresponding stage, and project-level average Precision, Recall, and F1-score are calculated based on TP, FP, and FN. For lifecycle trajectory reconstruction, we use Origin Accuracy and Fate Accuracy to measure the correctness of identifying the earliest stage in which a dependency appears and the final stage in which it is retained, respectively. For vulnerability exposure detection, each exposure instance is defined by a component, its associated vulnerability, and the lifecycle stage in which the vulnerability is present; Precision, Recall, and F1-score are then calculated based on TP, FP, and FN.
4.2
Lifecycle Dependency Evolution
To analyze how software dependencies evolve throughout the lifecycle and whether a single lifecycle stage can represent the complete software composition, we use the stage-level component ground truth to examine component evolution across the five stages of Code, Build, Release, Deploy, and Runtime for Java, JavaScript, and Python projects. Specifically, we measure the numbers of Added, Removed, and Retained components between adjacent stages to characterize component introduction, removal, and persistence throughout the lifecycle. We further compute Jaccard Similarity to quantify the overlap between component sets across different stages. Software dependencies are continuously introduced, removed, and adjusted as the lifecycle progresses, rather than remaining static. As shown in Table 1, we obtain a total of 58,211 stage-level component observations across the five lifecycle stages. Among them, the Build stage contains the largest number of components (32,715), substantially exceed7
ing the Code stage (3,891), indicating that the build process introduces a large number of dependencies that are not visible at the source-code stage. From Build to Release, the number of components decreases to 8,063, showing that many buildtime dependencies do not enter the final release artifacts. The number then increases again to 8,809 at the Deploy stage, while further decreasing to 4,733 at Runtime, indicating that deployed components are not necessarily equivalent to runtime components. The Added and Removed results further show that components continuously transition throughout the lifecycle, and their security states cannot be fully captured from any single stage.
Summary Software dependencies are continuously introduced, retained, and removed as the lifecycle progresses, while both the number of Retained components and the overall set similarity between adjacent stages indicate that software composition remains unstable across stages. Therefore, no single lifecycle stage can fully represent the actual state of components throughout the entire lifecycle.
4.3
To analyze the contributions of the key mechanisms in SCAAgent to lifecycle component recovery, we further conduct an ablation study. Specifically, we remove the two core modules, Adaptive Lifecycle Planning and Cross-stage Component Reasoning, to construct two variants, No Planning and No Reasoning, respectively, and evaluate them on the same projects under the same execution environment. All variants are evaluated against the stage-level component ground truth using Precision, Recall, and F1 to assess how different mechanisms affect component recovery across lifecycle stages. No Planning removes the dynamic planning process based on project structure and previous analysis results, and instead uses a fixed prompt that instructs the agent to analyze the Code, Build, Release, Deploy, and Runtime stages sequentially. This variant is used to evaluate the impact of adaptive analysis paths on lifecycle tracking. No Reasoning preserves the independent analysis of each lifecycle stage but removes cross-stage component association and evidence integration, generating the final component view solely from stage-level results. This variant is used to evaluate the contribution of cross-stage reasoning to component identity resolution and lifecycle recovery. Adaptive planning enables continuous lifecycle evidence discovery. As shown in Fig. 3, removing Planning causes substantial performance degradation across all three language ecosystems, with the most pronounced impact occurring in later lifecycle stages such as Release, Deploy, and Runtime. For Java, No Planning decreases F1 by 52.84, 85.87, 88.66, 86.56, and 77.80 percentage points across the five stages, respectively, with post-build stages being affected most severely. For JavaScript, performance remains relatively high at the Code and Build stages, whereas F1 at the Release and Deploy stages decreases by 89.40 and 85.04 percentage points, respectively. Python exhibits a similar trend after the Build stage, with F1 at the Release and Deploy stages decreasing by 78.48 and 67.05 percentage points, respectively. These results show that although a fixed prompt can leverage explicit dependency declarations or build configurations to identify components in some early stages, it cannot dynamically adjust subsequent analysis targets according to project structure and previously obtained analysis results. Since component evidence in later lifecycle stages is typically
Component sets are not consistently stable across adjacent lifecycle stages, indicating that no single stage can fully represent the overall software composition. As shown in Table 2, the number of Retained components in each stage transition is consistently lower than the complete component set of the corresponding stages, indicating that only a subset of dependencies persists into the next lifecycle stage, while the remaining components are removed or replaced. Meanwhile, Jaccard Similarity further shows that the overall compositions of adjacent stages are not consistent. For example, the Jaccard similarities across lifecycle transitions in Python range only from 22.57%–48.10%. Even though Java reaches a relatively high similarity of 98.29% from Release to Deploy, this does not imply comparable stability across the remaining stages. Taken together, the Retained and Jaccard results show that component sets are continuously reorganized as the lifecycle progresses, and any individual stage can only reflect a partial composition state rather than fully represent the complete software composition.
Table 2: Dependency changes between different software lifecycle stages. C, B, Rel, D, and Run denote Code, Build, Release, Deploy, and Runtime stages, respectively. Lifecycle Transition
Language Measure C→B
B→Rel
Rel→D
D→Run
Added 506.74 Removed 1.26 JavaScript Retained 31.29 Jaccard 8.10%
0.03 527.49 10.54 2.44%
18.89 0.03 10.54 53.07%
0.29 9.63 19.80 84.68%
Java
Added 212.94 Removed 1.23 Retained 46.49 Jaccard 18.10%
2.89 65.83 193.60 73.38%
3.17 0 196.49 98.29%
1.00 97.77 101.89 55.30%
Python
Added 9.26 Removed 15.71 Retained 9.20 Jaccard 26.71%
10.49 9.00 9.46 29.78%
11.17 11.74 8.20 22.57%
1.43 9.71 9.66 48.10%
Ablation Study
8
Figure 3: Ablation Results Across Lifecycle Stages and Language Ecosystems distributed across heterogeneous objects such as release artifacts, deployment configurations, and runtime environments, the absence of Planning limits the agent’s ability to continuously locate downstream analysis objects, preventing the lifecycle evidence chain from being fully extended. Cross-stage reasoning enables component identity resolution and lifecycle association. After removing Cross-stage Reasoning, the performance degradation mainly reflects weakened component identity resolution and cross-stage association capabilities. As shown in Fig. 3, No Reasoning exhibits decreases in both Precision and Recall across multiple lifecycle stages, indicating that independently obtained stage-level results cannot be directly transformed into an accurate lifecycle component view. For component identity resolution, the lack of cross-stage evidence constraints makes it difficult to associate components with similar names but different versions or origins across stages. For example, Precision at the Java Code stage decreases by 52.39 percentage points, while Precision at the JavaScript Release stage decreases by 77.38 percentage points. This indicates that relying on single-stage detection results can easily introduce incorrect matches, whereas cross-stage evidence provides constraints such as component versions, dependency relationships, and occurrence locations.
For continuous lifecycle tracking, removing cross-stage reasoning also weakens component recovery in later stages. Recall at the Java Deploy and Runtime stages decreases by 50.96 and 22.60 percentage points, respectively, while Recall at the JavaScript Release stage decreases by 81.37 percentage points. This is because components in later stages often need to be completed and validated using dependency relationships established in earlier stages, whereas simply aggregating independent stage-level results cannot determine the evolutionary relationships among components. Planning determines whether SCA-Agent can continuously discover component evidence across lifecycle stages, while Cross-stage Reasoning determines whether such distributed evidence can be correctly associated and reconstructed into complete lifecycle traces. Together, these two mechanisms enable SCA-Agent to move beyond stage-level component detection toward lifecycle-aware component recovery. Summary Planning enables SCA-Agent to continuously discover lifecycle-specific evidence, while cross-stage reasoning integrates heterogeneous evidence to resolve component identity and reconstruct complete lifecycle contexts.
9
(a) Java
(c) Python
(b) JavaScript
Figure 4: Stage-level component identification performance of SCA tools across language ecosystems.
4.4
Component Detection Comparison
even in later stages. Across different language ecosystems, traditional SCA tools exhibit more pronounced language-specific performance variations, whereas SCA-Agent maintains a relatively consistent advantage across Java, Python, and JavaScript. The Java ecosystem provides relatively standardized dependency resolution and build mechanisms through Maven and Gradle, enabling traditional tools to achieve strong results at certain stages; for example, cdxgen already approaches SCA-Agent at the Java Build stage. By comparison, dependency sources and project structures in Python and JavaScript are more diverse and may be jointly affected by dependency files, development dependencies, optional dependencies, build scripts, and environment configurations, making fixed analysis workflows difficult to apply consistently across projects. In contrast, SCA-Agent dynamically selects analysis objects and execution strategies according to the specific language ecosystem and project structure, enabling it to achieve the highest F1 in all three languages while exhibiting smaller cross-language performance variations.
To evaluate the component detection capability of SCA-Agent across different lifecycle stages, we compare SCA-Agent with traditional SCA tools using the stage-level component ground truth. For each of the five stages, namely Code, Build, Release, Deploy, and Runtime, we match the component set reported by each tool against the corresponding stage-level ground truth and use the average F1 score to measure detection accuracy. Since traditional SCA tools typically generate component inventories from specific software objects without explicitly modeling lifecycle stages, we align their detection results with the ground truth of each of the five stages to assess their component coverage across different lifecycle stages. To evaluate the component detection capability of SCAAgent across different lifecycle stages, we compare SCAAgent with Syft, SBOM-tool, and Cdxgen based on the stagelevel component ground truth. For the five lifecycle stages, including Code, Build, Release, Deploy, and Runtime, we match the component sets reported by each tool at the corresponding stage with the ground truth of that stage, and use the average F1 score to measure detection accuracy. Since traditional SCA tools typically generate component inventories based on specific software artifacts without explicitly modeling lifecycle stages, we align their detection results with the ground truth of each lifecycle stage to analyze their component coverage capability throughout the software lifecycle. As shown in Fig. 4, SCA-Agent achieves the highest F1 across all five lifecycle stages, namely Code, Build, Release, Deploy, and Runtime, while maintaining relatively stable detection performance from early to later stages. In contrast, traditional SCA tools perform mainly well at the Code and Build stages, but generally degrade substantially at the Release, Deploy, and Runtime stages. For example, cdxgen achieves an F1 of 0.957 at the Java Build stage, which is close to SCAAgent’s 0.959, but its performance drops considerably at the subsequent Release, Deploy, and Runtime stages. This is because traditional tools typically recover component sets from dependency manifests, package-manager metadata, or build systems at a particular stage, without continuously tracking how dependencies evolve afterward. In contrast, SCA-Agent analyzes stage-specific project files, configurations, and runtime environment information across different lifecycle stages, allowing it to maintain high component detection performance
Summary SCA-Agent achieves the highest F1 across all lifecycle stages and all three language ecosystems, demonstrating both stable component detection performance across different stages and strong adaptability to variations in dependency management and build processes across language ecosystems.
4.5
Lifecycle Trajectory Recovery
This experiment evaluates SCA-Agent’s capability to recover dependency Origin and Fate using the manually constructed lifecycle trace ground truth. For traditional SCA tools, we derive their inferred lifecycles from the stage-level detection results in RQ3: for each language ecosystem, we treat the stage with the highest F1 as the latest stage at which a component can be confirmed to exist, and assume that the component is also present in all preceding stages. We then compare SCAAgent with Syft, Microsoft SBOM Tool, and cdxgen across Java, JavaScript, and Python, using Origin Accuracy and Fate Accuracy to measure the accuracy of identifying the starting and ending points of component lifecycles. 10
For Origin estimation. As show in Table 3 that SCA-Agent substantially improves Origin localization accuracy across all three language ecosystems. In Python, JavaScript, and Java, SCA-Agent achieves Origin Accuracy values of 84.44%, 99.11%, and 90.65%, respectively, significantly outperforming all traditional tools. In comparison, Syft achieves its best result of only 7.05% on Java, Microsoft SBOM Tool reaches 28.78% on Python, and cdxgen reaches 43.62% on Python. This advantage mainly comes from SCA-Agent’s cross-stage component reasoning mechanism. For components observed in later stages, SCA-Agent can correlate dependency declarations, resolution relationships, and propagation evidence from preceding stages, unify component identities across stages, and trace them back to their original introduction points, thereby recovering component Origin more accurately.
objects, making it difficult to establish continuous relationships for components across different stages. In particular, for Python, Syft achieves an Origin Accuracy of only 0.00%, while both cdxgen and Syft obtain 0.00% Fate Accuracy, and Microsoft SBOM Tool reaches only 3.48%. These results indicate that even when traditional tools can detect certain components, they often cannot further determine where those components were initially introduced or whether they eventually propagate to later lifecycle stages. In other words, without cross-stage correlation, traditional SCA is better suited to producing local component snapshots than reconstructing complete component lifecycle trajectories. Summary SCA-Agent achieves 84.44%–99.11% Origin Accuracy and 70.94%–97.95% Fate Accuracy across the three language ecosystems, substantially outperforming traditional SCA tools and demonstrating its ability to more accurately recover dependency origins and propagation states.
Table 3: Origin and Fate scores by language and tool. Language
Tool
Accuracy (%) Origin
Fate
JavaScript
SCA-Agent Cdxgen Syft SBOM Tool
99.11 5.99 1.56 2.92
97.95 71.55 0.66 12.59
Java
SCA-Agent Cdxgen Syft SBOM Tool
90.65 16.72 7.05 9.03
70.94 26.37 1.85 11.57
Python
SCA-Agent Cdxgen Syft SBOM Tool
84.44 43.62 0.00 28.78
74.32 0.00 0.00 3.48
4.6
Lifecycle-aware Vulnerability Assessment
This experiment evaluates whether lifecycle context can improve software supply chain vulnerability exposure assessment. Based on the stage-level vulnerability ground truth defined in the setup, we compare the vulnerability detection results of SCA-Agent with those of cdxgen, Microsoft SBOM Tool, and Syft. For traditional tools, the lifecycle stages associated with their detected CVEs follow the component-to-stage mappings established in Section 4.5, ensuring consistent lifecycle determination across experiments. We use Precision, Recall, and F1 to measure each method’s ability to determine the actual exposure state of vulnerabilities. As shown in the Table 4, SCA-Agent achieves the best overall performance in vulnerability exposure assessment. Among the 17,482 ground-truth vulnerability exposure instances, SCA-Agent correctly identifies 16,497, with only 145 false positives (FPs) and 985 false negatives (FNs). Its Precision, Recall, and F1 reach 99.13%, 94.37%, and 96.69%, respectively. In comparison, although cdxgen achieves a Recall of 99.30%, it produces 9,710 FPs, resulting in a Precision of only 64.13% and an F1 of 77.93%. SCA-Agent therefore improves F1 by 18.76 percentage points over the bestperforming traditional tool. This advantage is directly related to SCA-Agent’s accurate recovery of Origin and Fate in RQ4.1. Accurate Origin allows SCA-Agent to determine where a vulnerable component enters the software lifecycle, while accurate Fate enables it to determine whether the component continues to propagate into subsequent stages. As a result, SCA-Agent can avoid treating vulnerabilities that have already disappeared during build, release, or deployment as still exposed in later stages, while also reducing omissions caused by incorrect lifecycle bound-
For Fate estimation, SCA-Agent achieves Fate Accuracy values of 74.32%, 97.95%, and 70.94% on Python, JavaScript, and Java, respectively. In particular, it reaches 97.95% on JavaScript, substantially improves over the traditional tools’ results of below 3.5% on Python, and also clearly outperforms cdxgen’s 26.37% on Java. This advantage is mainly attributable to SCA-Agent’s adaptive lifecycle planning mechanism. Traditional tools are typically limited to specific software objects or lifecycle stages, whereas SCA-Agent can dynamically plan and continuously extend evidence collection into subsequent stages based on the current analysis results. This allows it to determine whether components continue to propagate into Release, Deploy, and Runtime, thereby recovering their final lifecycle states more accurately. In contrast, traditional SCA tools exhibit clear limitations in recovering component Origin and Fate. Their results are typically derived from specific lifecycle stages or software 11
and dependency evolution patterns, the agent can continuously update its knowledge and optimize planning strategies, reducing manual maintenance and improving adaptability to evolving software ecosystems. Dataset and Ground-truth Reliability. Our dataset is constructed by manually executing the complete software lifecycle of each project and labeling the dependencies observed at each stage. For Runtime, we design execution scripts to exercise major project functionalities and cover dependency loading as comprehensively as possible, while recognizing that observations may still depend on workload coverage. To reduce annotation bias, multiple annotators cross-validate the labels and manually resolve inconsistencies. Dependency resolution may also vary across operating systems, package managers, and execution environments, so we use the same experimental environment for all evaluated methods and consider declared version constraints during component matching to mitigate environment-induced version variations. Although these measures cannot eliminate all ground-truth uncertainty, they improve the consistency and fairness of our evaluation. Cost–Benefit Trade-off of SCA-Agent. Compared with traditional SCA tools, SCA-Agent introduces additional analysis overhead due to LLM-based reasoning, adaptive Planning, and cross-stage Reasoning. In our experiments, the API cost of SCA-Agent is approximately $0.85 per project, with an average analysis time of about 5 minutes. Most of the overhead comes from project understanding, lifecycle planning, and cross-stage evidence correlation. Although this cost is higher than that of traditional static SCA approaches, SCA-Agent is not designed merely to accelerate component scanning, but to improve the accuracy of security assessment through lifecycle context. Traditional SCA may directly treat vulnerable components observed in intermediate lifecycle stages as risks to the final software. By recovering the actual propagation states of components, SCA-Agent improves CVE assessment accuracy by approximately 21.98%–35% compared with traditional approaches. For software supply-chain security analysis, more accurate risk assessment can reduce unnecessary investigation and remediation caused by false positives. Therefore, in security-sensitive scenarios, the additional analysis overhead introduced by SCA-Agent can be partially offset by the improved quality of security assessment. Supporting Deeper Supply-chain Security Analysis. SCAAgent tracks where a component is introduced, how it propagates across lifecycle stages, and whether it reaches release, deployment, or runtime, allowing vulnerability exposure to be assessed with lifecycle context. The current analysis operates at the component level and does not determine whether vulnerable code is reachable or whether a vulnerability can be triggered during execution. Answering these questions requires additional program-level evidence, such as call relationships, dynamic execution traces, and vulnerability-specific triggering conditions. The provenance, propagation relationships, and runtime observations produced by SCA-Agent can be
Table 4: Performance metrics of different tools Metric
SCA-Agent
Cdxgen
SBOM Tool
Syft
Results TP FP FN
16,642 16,497 145 985
27,070 17,360 9,710 122
18,415 12,235 6,180 5,247
2,022 1,560 462 15,922
Precision Recall F1
99.13% 94.37% 96.69%
64.13% 99.30% 77.93%
66.44% 69.99% 68.17%
77.15% 8.92% 16.00%
ary estimation. The high Recall but low Precision of cdxgen further shows that extending vulnerability states from traditional static SBOM results can cover most real vulnerabilities but tends to cause substantial over-propagation. In contrast, by relying on reconstructed lifecycle boundaries, SCA-Agent reduces the number of FPs from 9,710 to 145. Microsoft SBOM Tool achieves Precision, Recall, and F1 values of 66.44%, 69.99%, and 68.17%, respectively, while still producing a considerable number of both FPs and FNs. Syft achieves only 8.92% Recall, resulting in an F1 of 16.00%. These results indicate that, without reliable lifecycle context, traditional SCA tools struggle to determine whether vulnerabilities truly persist into subsequent software states. In contrast, SCA-Agent combines dependency origin, propagation, and final lifecycle state to more accurately characterize the actual scope of vulnerability exposure. Summary Lifecycle context can substantially improve software supply chain vulnerability exposure assessment. By accurately recovering dependency Origin and Fate, SCA-Agent more precisely identifies the actual propagation and persistence of vulnerabilities throughout the software lifecycle, reducing both the erroneous extension of vulnerabilities that have already disappeared and omissions of real exposures. As a result, SCA-Agent achieves an F1 of 96.69%, outperforming traditional SCA tools by 18.76– 80.69 percentage points.
5
Discussion
Toward Self-Evolving SCA-Agent. SCA-Agent currently relies on manually constructed domain knowledge, including dependency management, build workflows, tool usage, and stage-specific analysis strategies. This knowledge helps the agent adapt its analysis to different projects, but continuously evolving software ecosystems make comprehensive manual maintenance difficult. A promising direction is to develop self-evolving SCA-Agent that learn from previous analyses. By accumulating successful execution paths, failure cases, 12
7
linked with such evidence in future work to extend lifecycleaware vulnerability assessment toward code reachability and exploitability analysis.
6
Conclusion
This paper presents SCA-Agent, a lifecycle-aware SCA system that reconstructs component traces across Code, Build, Release, Deploy, and Runtime through adaptive planning and cross-stage reasoning. Evaluation on 105 real-world projects shows that SCA-Agent consistently improves component detection and achieves 96.69% F1 for vulnerability exposure assessment, outperforming the best traditional SCA tool by 18.76 percentage points. These results demonstrate that lifecycle-aware SCA provides a more accurate and traceable foundation for software supply-chain security analysis.
Related Work
Software Composition Analysis (SCA) is a fundamental technique for software supply-chain security, used to identify third-party components, recover dependency relationships, and associate vulnerability information. Early SCA tools mainly relied on project declarations such as manifests and lockfiles for dependency resolution [16, 31, 37], and their effectiveness has been validated by multiple empirical studies [14, 19, 53, 57, 59]. With the standardization of SBOMs driven by NTIA, SPDX, and CycloneDX [29, 36, 49], tools such as Syft, cdxgen, and Microsoft SBOM Tool further recover components from software packages, file systems, build environments, and container images [6, 52, 53]. However, extensive studies have shown that even for the same software object, different tools can produce substantially different component names, versions, and dependency relationships [18, 40, 52, 53, 57, 60], indicating that software composition results are highly dependent on the analyzed representation and evidence source. To broaden component observability, subsequent studies have explored complementary evidence from different software representations, including incremental SBOM construction [20], multi-channel analysis for firmware and IoT systems [44], container image analysis [8], and component identification and source matching for stripped or closed-source binaries [21, 30, 58]. Meanwhile, runtime SCA shows that dynamically loaded, reflectively injected, or runtime-resolved components are difficult to capture through static analysis alone. MEM-SBOM and NodeShield complement static evidence through memory forensics and runtime observation, respectively [1, 13]. These studies collectively demonstrate that different software states expose distinct and complementary component evidence, making a single artifact or analysis stage insufficient to characterize software composition. Recent studies have also begun to compare SCA and SBOM results across lifecycle stages and investigate SBOM consumption consistency, validation, and trustworthy sharing [9, 10, 23, 43, 47]. However, existing approaches mainly acquire evidence independently from specific stages or software objects, without systematically correlating component evidence across its evolution from introduction and build to release, deployment, and runtime. Therefore, recovering complete component lifecycle traces and using them to characterize component origin, propagation, and fate remains a key challenge for lifecycle-aware software composition analysis. 13
A
Open Science
[11] Serena Cofano. Transparent dependencies: Improving software supply chain visibility at build time and runtime. 2026.
The prompts and experience files used by SCA-Agent are available in our anonymous repository at https://anonymous. 4open.science/r/sca_agent-E0AC/. To support reproducibility, we provide the core prompts, agent configurations, and representative experience files required to understand and reproduce the analysis workflow.
[12] Serena Cofano, Giacomo Benedetti, and Matteo Dell’Amico. Sbom generation tools in the python ecosystem: an in-detail analysis. In 2024 IEEE 23rd International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom), pages 427–434. IEEE, 2024.
References
[13] Eric Cornelissen and Musard Balliu. Nodeshield: Runtime enforcement of security-enhanced sboms for node. js. In Proceedings of the 2025 ACM SIGSAC Conference on Computer and Communications Security, pages 1844–1858, 2025.
[1] Hala Alia, Andrew Case, and Irfan Ahmed. What you see is not what you execute: Memory-based runtime sbom generation for supply chain security. arXiv preprint arXiv:2606.22827, 2026.
[14] Andreas Dann, Henrik Plate, Ben Hermann, Serena Elisa Ponta, and Eric Bodden. Identifying challenges for oss vulnerability scanners-a study & test suite. IEEE Transactions on Software Engineering, 48(9):3613–3625, 2021.
[2] Alibaba. Druid 1.2.28 release. GitHub Release, March 2026. Release tag 1.2.28; accessed: 2026-08-26. [3] Anchore. Syft. https://github.com/anchore/syft. Accessed: 2026-08-26. [4] Anthropic. Claude agent sdk. https://docs. anthropic.com/, 2026. Accessed: 2026-08-26.
[15] Jens Dietrich, Shawn Rasheed, Alexander Jordan, and Tim White. On the security blind spots of software composition analysis. In Proceedings of the 2024 Workshop on Software Supply Chain Offensive Research and Ecosystem Defenses (SCORED ’24), pages 1–11. Association for Computing Machinery, 2024.
[5] Anthropic. Introducing claude sonnet 4.6. https: //www.anthropic.com/news/claude-sonnet-4-6, February 2026. Accessed: 2026-08-26. [6] Giacomo Benedetti, Serena Cofano, Alessandro Brighente, and Mauro Conti. The impact of sbom generators on vulnerability assessment in python: a comparison and a novel approach. In International Conference on Applied Cryptography and Network Security, pages 487–509. Springer, 2025.
[16] Eclipse Steady Project. Eclipse steady. https:// github.com/eclipse/steady/. Accessed: 2026-0825. [17] Darius Foo, Jason Yeo, Hao Xiao, and Asankhaya Sharma. The dynamics of software composition analysis. CoRR, abs/1909.00973, 2019.
[7] D. Bifolco, Simone Romano, S. Nocera, R. Francese, G. Scanniello, and Massimiliano Di Penta. An empirical study on the accuracy of github’s dependency graph and the nature of its inaccuracy. Information and Software Technology, 187:107854, 2025.
[18] Derek Garcia, Mehdi Tarrit Mirakorhli, Schuyler Dillon, Kevin Laporte, Matthew Morrison, Henry Lu, Viktoria Koscinski, Christopher Enoch, Mohamad Fazelnia, and Roger Chen. A landscape study of open-source tools for software bill of materials (sbom) and supply chain security. In 2025 IEEE/ACM 3rd International Workshop on Software Vulnerability Management (SVM), pages 37–45. IEEE Computer Society, 2025.
[8] Jacopo Bufalino, Agathe Blaise, and Stefano Secci. Orca: Unveiling obscure containers in the wild. In Proceedings of the 2025 Workshop on Software Supply Chain Offensive Research and Ecosystem Defenses, pages 74–84, 2025. [9] Jacopo Bufalino, Mario Di Francesco, Agathe Blaise, and Stefano Secci. Sbomproof: Beyond alleged sbom compliance for supply chain security of container images. arXiv preprint arXiv:2510.05798, 2025.
[19] Nasif Imtiaz, Seaver Thorn, and Laurie Williams. A comparative study of vulnerability reporting by software composition analysis tools. In Proceedings of the 15th ACM/IEEE international symposium on empirical software engineering and measurement (ESEM), pages 1–11, 2021.
[10] Gianpietro Castiglione, Shahriar Ebrahimi, and Narges Khakpour. Verisbom: Secure and verifiable sbom sharing via zero-knowledge proofs. arXiv preprint arXiv:2602.13682, 2026.
[20] Changguo Jia, Nianyu Li, Kai Yang, and Minghui Zhou. Sit: An accurate, compliant sbom generator with incremental construction. In 2025 IEEE/ACM 47th International Conference on Software Engineering: Companion 14
Proceedings (ICSE-Companion), pages 13–16. IEEE, 2025.
[30] Bowei Ning, Xuejun Zong, Lian Lian, Kan He, Yifei Sun, Yuxiang Lei, and Plamen Vasilev. Securing the dark matter: A semantic-enhanced neuro-symbolic framework for supply chain analysis of opaque industrial software. arXiv preprint arXiv:2605.07737, 2026.
[21] Ling Jiang, Junwen An, Huihui Huang, Qiyi Tang, Sen Nie, Shi Wu, and Yuqun Zhang. Binaryai: Binary software composition analysis via intelligent binary source code matching. In Proceedings of the IEEE/ACM 46th International Conference on Software Engineering, pages 1–13, 2024.
[31] Ochrona Security. Ochrona security. https:// ochrona.dev, 2021. Accessed: 2026-08-25. [32] Eric O’Donoghue, Brittany Boles, Clemente Izurieta, and Ann Marie Reinhold. Impacts of software bill of materials (sbom) generation on vulnerability detection. In Proceedings of the 2024 Workshop on Software Supply Chain Offensive Research and Ecosystem Defenses, SCORED ’24, page 67–76, New York, NY, USA, 2024. Association for Computing Machinery.
[22] Nobutaka Kawaguchi, Charlie Hart, and Hiroki Uchiyama. Understanding the effectiveness of sbom generation tools for manually installed packages in docker containers. J. Internet Serv. Inf. Secur., 14:191–212, 2024. [23] Rio Kishimoto, Tetsuya Kanda, Yuki Manabe, Katsuro Inoue, Shi Qiu, and Yoshiki Higo. A dataset of software bill of materials for evaluating sbom consumption tools. In 2025 IEEE/ACM 22nd International Conference on Mining Software Repositories (MSR), pages 576–580. IEEE, 2025.
[33] Marc Ohm, Henrik Plate, Arnold Sykosch, and Michael Meier. Backstabber’s knife collection: A review of open source software supply chain attacks. In International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment, pages 23–43. Springer, 2020.
[24] Elizabeth Lin, Sparsha Gowda, William Enck, and Dominik Wermke. Context matters: Qualitative insights into developers’ approaches and challenges with software composition analysis. In 34th USENIX Security Symposium (USENIX Security 25), pages 2165–2183, 2025.
[34] OpenSSF. Supply-chain levels for software artifacts (slsa). https://slsa.dev/. Accessed: 2026-08-24. [35] OWASP Foundation. cdxgen. https://github.com/ CycloneDX/cdxgen. Accessed: 2026-08-26.
[25] Chengwei Liu, Sen Chen, Lingling Fan, Bihuan Chen, Yang Liu, and Xin Peng. Demystifying the vulnerability propagation and its evolution via dependency trees in the npm ecosystem. In 2022 IEEE/ACM 44th International Conference on Software Engineering (ICSE), pages 672– 684, 2022.
[36] OWASP Foundation. Cyclonedx bill of materials standard. https://cyclonedx.org/. Accessed: 2026-0824. [37] OWASP Foundation. Owasp dependencycheck project. https://owasp.org/ www-project-dependency-check/, 2021. Accessed: 2026-08-25.
[26] Microsoft. Microsoft sbom tool. https://github. com/microsoft/sbom-tool. Accessed: 2026-08-26. [27] Yoonjong Na, Seunghoon Woo, Joomyeong Lee, and Heejo Lee. CNEPS: A precise approach for examining dependencies among third-party C/C++ open-source components. In Proceedings of the 46th IEEE/ACM International Conference on Software Engineering, ICSE ’24, pages 2918–2929. IEEE Computer Society, 2024.
[38] Serena Elisa Ponta, Henrik Plate, and Antonino Sabetta. Beyond metadata: Code-centric and usage-based analysis of known vulnerabilities in open-source software. In 2018 IEEE International Conference on Software Maintenance and Evolution (ICSME), pages 449–460. IEEE, 2018.
[28] National Institute of Standards and Technology. Notional reference model for devsecops. Secure Software Development, Security, and Operations (DevSecOps) Practices, 2026. Accessed: 2026-08-26.
[39] Serena Elisa Ponta, Henrik Plate, and Antonino Sabetta. Detection, assessment and mitigation of vulnerabilities in open source dependencies. Empirical Software Engineering, 25(5):3175–3215, 2020.
[29] National Telecommunications and Information Administration. The minimum ele[40] Md Fazle Rabbi, Arifa Islam Champa, and Minments for a software bill of materials (sbom). haz Fahim Zibran. Claim vs. capability: A comparative https://www.ntia.gov/report/2021/ analysis of the sbom generation tools for rust projects. minimum-elements-software-bill-materials-sbom, In Proceedings of the 40th ACM/SIGAPP Symposium 2021. July 12, 2021. on Applied Computing, pages 1712–1720, 2025. 15
[41] Kristiina Rahkema and Dietmar Pfahl. Vulnerability propagation in package managers used in iOS development. arXiv preprint arXiv:2305.10339, 2023.
[51] Santiago Torres-Arias, Hammad Afzali, Trishank Karthik Kuppusamy, Reza Curtmola, and Justin Cappos. in-toto: Providing farm-to-table guarantees for bits and bytes. In 28th USENIX Security Symposium (USENIX Security 19), pages 1393–1410, 2019.
[42] Shawn Rasheed, Max McPhee, Lisa Patterson, Stephen MacDonell, and Jens Dietrich. Hidden dependencies and component variants in sbom-based software composition analysis. arXiv preprint arXiv:2604.21278, 2026.
[52] Chengjie Wang, Jingzheng Wu, Hao Lyu, Xiang Ling, Tianyue Luo, Yanjun Wu, and Chen Zhao. A large scale empirical analysis on the adherence gap between standards and tools in sbom. ACM Transactions on Software Engineering and Methodology, 2026.
[43] Martin Rosso, Muhammad Asad Jahangir Jaffar, Alessandro Brighente, and Mauro Conti. A practical solution to systematically monitor inconsistencies in sbom-based vulnerability scanners. In Proceedings of the 41st ACM/SIGAPP Symposium on Applied Computing, pages 1739–1748, 2026.
[53] Menghan Wu, Yukai Zhao, Xing Hu, Xian Zhan, Shanping Li, and Xin Xia. More than meets the eye: On evaluating sbom tools in java. ACM Transactions on Software Engineering and Methodology, 35(7):1–30, 2026.
[44] Vadim Safronov, Ionut Bostan, Nicholas Allott, and Andrew Martin. Unibom–a unified sbom analysis and visualisation tool for iot systems and beyond. In Proceedings of the 15th International Conference on the Internet of Things, pages 86–94, 2025.
[54] Boming Xia, Tingting Bi, Zhenchang Xing, Qinghua Lu, and Liming Zhu. An empirical study on software bill of materials: Where we stand and the road ahead. In Proceedings of the 45th IEEE/ACM International Conference on Software Engineering, pages 2630–2642. IEEE, 2023.
[45] Martin Schwaighofer, Michael Roland, and René Mayrhofer. Extending cloud build systems to eliminate transitive trust. In Proceedings of the 2024 Workshop on Software Supply Chain Offensive Research and Ecosystem Defenses, pages 45–55, 2023.
[55] Yue Xiao, Dhilung Kirat, Douglas Lee Schales, Jiyong Jang, Luyi Xing, and Xiaojing Liao. JBomAudit: Assessing the landscape, compliance, and security implications of java SBOMs. In Proceedings of the Network and Distributed System Security Symposium. Internet Society, 2025.
[46] Congyan Shu, Wentao Chen, Guisheng Fan, Huiqun Yu, Zijie Huang, and Yuguo Liang. Tool or toy: Are sca tools ready for challenging scenarios? Computers & Security, page 104624, 2025.
[56] Sheng Yu, Wei Song, Xunchao Hu, and Heng Yin. On the correctness of metadata-based sbom generation: A differential analysis approach. In 2024 54th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN), pages 29–36, 2024.
[47] Tom Sorger, Eric Cornelissen, Aman Sharma, Javier Ron, Musard Balliu, and Martin Monperrus. zksbom: Privacy-preserving sbom sharing with zero-knowledge sets. arXiv preprint arXiv:2605.00076, 2026.
[57] Sheng Yu, Wei Song, Xunchao Hu, and Heng Yin. On the correctness of metadata-based sbom generation: A differential analysis approach. In 2024 54th Annual IEEE/IFIP International conference on dependable systems and networks (DSN), pages 29–36. IEEE, 2024.
[48] Murugiah Souppaya, Karen Scarfone, and Donna Dodson. Secure software development framework (ssdf) version 1.1. NIST Special Publication, 800(218):800– 218, 2022. [49] SPDX Workgroup. Software package data exchange specification. https://spdx.dev/use/ specifications/. Accessed: 2026-08-24.
[58] Lyuye Zhang, Chengwei Liu, Jiahui Wu, Shiyang Zhang, Chengyue Liu, Zhengzi Xu, Sen Chen, and Yang Liu. Drop the golden apples: Identifying third-party reuse by db-less software composition analysis. In Proceedings of the 33rd ACM International Conference on the Foundations of Software Engineering, pages 691–695, 2025.
[50] Trevor Stalnaker, Nathan Wintersgill, Oscar Chaparro, Massimiliano Di Penta, Daniel M German, and Denys Poshyvanyk. Boms away! inside the minds of stakeholders: A comprehensive study of bills of materials for software systems. In Proceedings of the IEEE/ACM 46th International Conference on Software Engineering, ICSE ’24, New York, NY, USA, 2024. Association for Computing Machinery.
[59] Lida Zhao, Sen Chen, Zhengzi Xu, Chengwei Liu, Lyuye Zhang, Jiahui Wu, Jun Sun, and Yang Liu. Software composition analysis for vulnerability detection: An empirical study on java projects. In Proceedings of the 16
31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering, pages 960–972, 2023. [60] Zhimin Zhao, Abdul Ali Bangash, Tongxu Ge, Arshdeep Singh, Zitao Wang, and Bram Adams. The state of the sbom tool ecosystems: a comparative analysis of spdx and cyclonedx. arXiv preprint arXiv:2512.21781, 2025.
17