arXiv CSopen access

Software Dark Matter: Gazing at Uncharted Files to Navigate SBOM Integrations

Software Dark Matter: Gazing at Uncharted Files to Navigate SBOM Integrations Abhishek Reddypalle

Dennis Roellke

Santiago Torres-Arias

Purdue University West Lafayette, Indiana, USA [email protected]

Bloomberg New York City, New York, USA [email protected]

Purdue University West Lafayette, Indiana, USA [email protected]

arXiv:2606.13966v1 [cs.CR] 11 Jun 2026

Abstract Modern software supply chains have evolved into vast, heterogeneous networks where transparency — the granular understanding of all software components — is now a critical security requirement. While Software Bills of Materials (SBOMs) have emerged as the primary mechanism for this transparency, current industry practices rely on a metadata-centric paradigm that assumes an artifact is defined solely by its package manager declarations. We posit that this assumption is fundamentally flawed, creating a systemic visibility gap we define as Software Dark Matter (SDM). SDM represents the set of security-critical files present in an artifact’s filesystem that are unaccounted for by its associated metadata. We implement a reference tool, DARKFILES, and use it to analyze four ecosystems of disjoint nature: DockerHub, Maven Central, plugin/extension marketplaces (Jenkins plugins and OpenVSX), and a real-world enterprise environment. Our research makes the following contributions: we introduce a general-purpose metric for artifact fidelity calculating SDM as the ratio of untracked files per total file count. We introduce Packaging Lag, a phenomenon where official metadata remains out-of-date across multiple versions before catching up to an artifact’s actual content. We demonstrate that SDM exposes vulnerable software invisible to SBOM-driven pipelines both by cross-referencing untracked packages against known CVE databases and through the direct discovery of three confirmed high-severity CVEs, showing that SDM is highly correlated with sensitive information including secrets and cryptographic keys.

1

Introduction

Modern software supply chains are large, complex networks that span multiple actors, organizations, jurisdictions, and ecosystems. Prior research has found that many projects have one hundred or more Open Source Software (OSS) components [20, 55, 62, 88]. This scale and heterogeneity have made software transparency, or the understanding of all software components and dependencies, a first-class software engineering and security concern [1]. For example, in December 2025, the react4shell software vulnerability affecting the react framework and next.js exposed a large number of modern web front-ends to remote code execution attacks [14]. Industry response to this incident painfully demonstrated that even five years after the similar, infamous log4shell vulnerability [9, 47, 48] there is no established automated solution to confidently determine - or reject - the presence of open source software dependencies within a software project [10, 54, 91, 93]. Conference’17, Washington, DC, USA 2026. ACM ISBN 978-x-xxxx-xxxx-x/YYYY/MM https://doi.org/10.1145/nnnnnnn.nnnnnnn

While various efforts in industry and academia have attempted to close this gap through numerous heuristics, there is no generalized model that allows a comprehensive exploration of this phenomenon. This is primarily due to the fact that these studies focus on the effect (i.e., lack of transparency) rather than explore their causes. Further, without a clear understanding of such causes, it is difficult to establish methods that address this lack of transparency. In this paper, we hypothesize that existing solutions and operational pipelines fail for systemic reasons, in particular the informational divergence between a software manifest and its physical reality: Software Bill of Materials (SBOMs) [2] have established themselves as a mechanism to provide much needed transparency regarding the software stacks provided by vendors. The guiding principle behind SBOMs is that, when software vendors disclose a comprehensive view of the software components included in their products, software consumers would be able to take adequate action to minimize their attack surface. Thus, SBOMs are increasingly treated as a foundation for software supply-chain security [25]. They are used to determine exposure during incident response (e.g., react4shell), to drive governance workflows, and importantly, justify risk claims about deployed artifacts. Unfortunately, the tools that populate SBOMs with information, often Software Composition Analysis (SCA) tools use an insufficient source of truth to establish software identity: These scanners generate post-hoc SBOMs that imply the physical presence of a component based on package manager databases and ecosystemspecific heuristics. While the approach of using tools that analyze package manager metadata has intuitive appeal, past research has suggested that they can introduce a degree of variability and inconsistency in their outcomes, resulting in dramatically different results [30, 61, 84, 87, 94]. However, this intuitive appeal is insufficient in real build and deployment workflows, for artifacts are assembled through heterogeneous origins not restricted to packages with metadata including scripts installing software outside package managers, broad copy/ unarchive steps include files without attribution, repackaging patterns (e.g., bundled dependencies and shaded artifacts) and post-deployment drift all introduce files after meta-data generation. This work is the first to quantify this security gap using a metric that goes beyond listing the missing files; we introduce Software Dark Matter. SDM is the set of security critical files actually present in an artifact’s filesystem namespace but not asserted from its SBOM. We implement this measurement by fundamentally shifting the source of truth behind our supply chain assertions: We leverage all actual files of an artifact, and to the best of our knowledge we are the first to demonstrate a filtering strategy that amplifies the

Conference’17, July 2017, Washington, DC, USA

signals in this potentially noisy approach to draw the developers attention to important files only. This strategy has resulted in findings in popular open source projects, CVE-2025-32754 in Jenkins and CVE-2025-32111 in acme.sh, with further vulnerabilities currently under coordinated disclosure. We note that SDM does not certify that an artifact is secure, instead it measures to what degree stateof-the-art software analysis (e.g., SBOM-driven) pipelines diverge from reality - what critical files they do not account for - and highlights them as suspicious. Without lightweight reachability analysis to prioritize SDM that is likely to influence behavior and surface security-relevant threats this approach would be little actionable for developers. We share Darkfiles as reference implementation for this framework. We use Darkfiles to formally study the phenomenon of SDM by answering four leading research questions. Initially, research question (RQ1) tests our hypothesis that SDM is systemic to modern software by showing its prevalence across multiple representative ecosystems. Then, research question (RQ2) affirms that SDM has security implications, and research question (RQ3 and RQ4) provides academic insights about the origins of SDM - both causal and temporal. In conclusion, this paper presents the following contributions: • Analyzes a major root cause of insufficient software transparency despite years of attention and an abundance of regulations • Identifies that real-world heterogeneous software to be oversimplified by regulators and vendors • Formalizes Software Dark Matter a general-purpose metric for artifact fidelity, and discovers the phenomenon of Packaging Lag • Evaluates these measurements on a holistic software collection from disjoint real world sources, and • Provides tangible recommendations for improvement The rest of the paper is organized as follows: Section 2 provides background on software development practices, SBOM creation, and container technologies. Section 3 defines the threat model, formally defines software dark matter and presents theoretical ideas driving Darkfiles. Section 4, Section 5, Section 6 and Section 7 show our findings in the four ecosystems we study. Finally, in Section 8 we present a strategies to eliminate SDM.

2

Background and Related Work

In industry, the state-of-the-art in software transparency is to use Software Composition Analysis (SCA) tools that programmatically aggregate dependency information as Software Bill of Materials (SBOM). While this approach is sound and complete for controlled experiments, related work illustrates its flaws in heterogeneous realworld software. This section defines how SBOMs are generated, how SCA works, and the software ecosystems and practices in which these techniques are applied.

2.1

SBOM Workflows in Supply-Chain Security

SBOMs have emerged as a practical mechanism to enhance software security through transparency due to their ability to centralize all information about a software artifact in a machine-readable format. Thus, they are integrated into vulnerability management, license

Abhishek Reddypalle, Dennis Roellke, and Santiago Torres-Arias

checks, and policy decisions by means of direct references to claims, or by studying the inventory of software components and their relationships provided within. In operational settings, SBOMs are treated as an input to automated security workflows, where they are (i) generated or collected after build, (ii) stored and distributed to downstream consumers, and (iii) ingested into vulnerability management and policy engines for remediation and compliance reporting. NIST frames SBOMs as a means to increase transparency and accelerate identification and remediation of vulnerabilities in supply chains, emphasizing their utility as an operational artifact rather than a purely documentary one [43]. As SBOMs become embedded into Continuous Integration and Continuous Delivery(i.e CI/CD), security teams increasingly rely on them for evidence regarding claims about what is present in deployed software, assess risk, and respond to incidents when new vulnerabilities emerge. Industry and policy developments have further accelerated adoption. In the United States, the U.S. Executive Order EO14028 ecosystem established SBOMs as a procurement-facing control and White House guidance has required or encouraged agencies to obtain SBOMs for certain software procurements [80–82]. Adoption surveys also suggest that SBOM generation and consumption are becoming increasingly common in practice [40, 57, 73, 76]. Similarly, in the European Union, EU’s Cyber Resilience Act (CRA) introduces lifecycle obligations around vulnerability handling and reporting, and specifies a phased applicability timeline (entered into force on 10 December 2024, reporting obligations apply from 11 September 2026, main obligations apply from 11 December 2027) [21]. Such regulatory pressures further heighten the need for measurable SBOM accuracy. Without a defensible accuracy baseline, policy requirements are difficult to enforce in practice. SBOM producers can plausibly attribute missing components to tool limitations or ecosystem-specific coverage gaps, shifting accountability to the capabilities of SBOM generators instead of the producing pipeline [44, 84]. However, as SBOMs play a crucial role in security decisionmaking, it is important to understand to what extent do SBOM-driven pipelines faithfully represent the artifacts they are used to secure?

2.2

Software Composition Analysis

Software Composition Analysis (SCA) tools mine dependency information from software artifacts and aggregate dependency information, licensing data, and known vulnerabilities into a standardized format called a Software Bill of Materials (SBOM). US federal bodies have shaped SBOM expectations at multiple levels: CISA distinguishes multiple lifecycle-aligned SBOM types—including design, source, build, analyze, and runtime/deployed SBOMs—that differ in visibility and intended use [11], while NTIA’s ’minimum elements’ guidance, issued under Executive Order 14028 [80], provides a baseline set of required data fields but does not establish what makes an SBOM accurate [2]. In practice, most SBOMs are generated postbuild as analyze SBOMs using package metadata and ecosystem heuristics [6, 28]. These limitations motivate a shift from schemaand completeness-oriented assessments toward artifact-grounded measures of SBOM accuracy for security decision-making to better achieve an SBOM’s stated mission of a comprehensive risk assessment clearinghouses.

Software Dark Matter: Gazing at Uncharted Files to Navigate SBOM Integrations

As SBOMs are increasingly positioned as evidence supporting these obligations, pipelines need a way to quantify what SBOMs do not capture, not only what they claim to include. Our approach is different in that, rather than inferring provenance from metadata alone, we compare the actual filesystem of the deployed artifact to SBOM claims, surfacing all files whose provenance is unclear or absent, regardless of how or why they were introduced. Comparative studies consistently find large disagreement among SCA tools run on the same project, driven by differences in detection heuristics and advisory sources. Imtiaz et al. report counts ranging from 17 to 332 vulnerable dependencies across nine tools on the same Maven/npm application and recommend against relying on any single scanner [13, 30]. In containers, Churakova & Ekstedt measure low consistency among VEX-enabled container scanners, indicating low maturity of the space [19]. Tooling reports like the Container SBOM Clarity Project similarly document inconsistent package identification and licensing in container SBOMs [51]. Broad surveys also note substantial variability and reproducibility challenges in SBOM outputs across tools and versions [28, 32, 53, 65, 70, 84, 92]. Even when tools agree on approach, output can vary across formats and versions. Balliu et al. deep-dive Java SBOM producers and highlight reproducibility/accuracy gaps, reinforcing the need for maturity before SBOMs can serve as reliable ground truth [6, 87]. Multiple formats (SPDX, CycloneDX) and identifier schemes (e.g., SWID, PURLs) introduce cross-ecosystem matching problems when not uniformly adopted [59, 63]. Melara and Torres-Arias argue that many challenges stem from the lack of a common language and shared understanding around supply-chain metadata [44]. Large-scale measurements show that many popular images contain manually installed software that common SBOM generators overlook. Kawaguchi et al. analyze 3,500+ DockerHub images and find that 51% include one or more manually installed packages; between 30–70% of these installations are missed by prominent SBOM tools, and 22.7% of actively executed packages go unidentified—including some with known CVEs [7, 33, 53, 62, 89]. Dockerfileaware/static systems like DAVS reason from Dockerfiles to locate potentially vulnerable files but assume access to build artifacts and focus on targeted vulnerability inference rather than SBOM validation [16]. In contrast, this work is proactive and CVE-agnostic, and thus complements the approaches listed above. Rather than reacting to known issues via a vulnerability database, it surfaces integrity and provenance gaps that can be acted upon even before any CVE or 0-day is disclosed.

2.3

Heterogeneous Real-World Software

Recent work shows how metadata-centric pipelines under-report or mis-attribute components when confronted with packaging indirection. Dietrich et al. show that hidden dependencies introduced via cloning or shading (e.g., class relocation, name mangling) escape mainstream SCA and surface as vulnerable “clones” missed by tools [15]. Adversarial analyses in the Maven ecosystem demonstrate that POM indirections, dependency management inheritance, and shaded/uber-JAR repackaging can confuse or mislead meta-data based SCA (e.g., Dependabot, Snyk, Grype, OSV-Scanner, OWASP Dependency-Check), yielding false-negatives and other

Conference’17, July 2017, Washington, DC, USA

Figure 1: Real world software composition with (A) buildcontext bleed-in adding unintended files (B) provenance loss due to repackaging practices stripping attributes from the code (C) divergence between used manifest and declared manifest (D) post-build drift added by runtime initialization

failure modes [31]. Recent works also highlight parser confusion attacks, where inconsistencies among toolchain parsers are exploited to conceal components or inject ambiguity into SBOMs [92]. These challenges extend beyond third-party analyzers: ecosystem and registry metadata can itself be missing, inconsistent, or incorrect, leading to provenance drift between source and published artifacts. For example, PyRadar and LastPyMile (Python) and AROMA (Java) show that even first-class metadata (e.g., the one used by a package manager) can be incomplete or wrong, which can undermine provenance and cause mismatches between sourcelevel intent and released artifacts [24, 26, 34, 37, 86]. Finally, several studies document the lack of integrity protection and poor crossecosystem meta-data hygiene in current SBOM solutions, compounding the risk of incomplete or misleading inventories [22, 59]. Further, production grade enterprise systems are compositions of applications stacked vertically and horizontally and in practice maintained by independently operating teams. One team may use multiple pipelines, and each pipeline may be used by multiple teams. Multiple pipelines may contribute to the same layer of abstraction, or one pipeline may serve multiple layers. In practice, these pipelines are implemented through manifest files (e.g., build specs, deploy descriptors, policy as code). The prior discussion about which SBOM types to employ must therefore scale from one pipeline to many pipelines to obtain system-wide coverage. However this is difficult in practice, existing tooling tends to center on application workflows and ecosystems with package managers, leaving gaps when artifacts are assembled by heterogeneous pipelines and adhoc steps. Container images(represented as layered OCI manifest or commonly Dockerfiles) exhibit the same multi-party, multi-pipeline structure [3]. Each Dockerfile instruction materializes as a filesystem layer, much like a CI job stage, so the final image reflects the union of decisions made across pipelines. This is precisely where discrepancies arise: images routinely ship components installed outside package managers (manual copies, curl|bash installers, compiled-from-source), or vendored/shaded artifacts carried forward from upstream layers. Finding SDM in modern systems inherently requires recursive, context-aware analysis, including across

Conference’17, July 2017, Washington, DC, USA

container layers, deeply nested infrastructure-as-code pipelines, or packaging formats like shaded JARs [8, 78]. Our approach generalizes to all these scenarios, rather than relying on a single manifest or ecosystem’s perspective.

3

Software Dark Matter

In this section we formalize the problem by defining a threat model, a definition of software dark matter, and the driving research questions for our study.

3.1

Threat Model

A vast body of work in software supply chain security focuses on a reactive threat centered around vulnerability propagation by studying how known software vulnerabilities, e.g. CVEs, or known malicious packages [49, 96] propagate on to different systems and how to manages ensure proper incident response [35, 55]. Instead, our work lies on the field of supply chain hardening, that is to proactively eliminate supply chain vulnerabilities added by natural occurrence. The SDM framework does no expect prior knowledge of vulnerabilities or malicious packages and it is not a defense against above mentioned distribution vectors [56]. Within this hardening space, we focus on unknown transparency gaps that introduce vulnerabilties. Attacker Goals & Motivation. Explicitly, we assume an attacker, or negligent user seeks to compromise a software artifact in the software supply chain by introducing underhanded changes that are not reported by SCA tools. Given the transitive nature of software supply chains, attacks are not necessarily focused on a specific victim but may exploit a given CVE on any system that’s subject to it to maximize their reach. By operating within this space, adversaries can: • Reason about vulnerabilities: Ideally the adversary finds a CVE that the system owner is not aware of and has not mitigated. • Backdoor Credentials: Extract secrets unintentionally inserted into images, such as leaked GitHub tokens or pregenerated SSH keys, which are often untracked by package managers [12, 45]. • Evade Detection: Hide malicious components, vulnerable libraries (e.g., vulnerable copies of Log4j), or persistence mechanisms Attacker Strategy. Attackers can exploit the fact that SBOMs are often incomplete because the underlying metadata is itself incomplete. As explored in the paper below, we identify four recurring patterns through which this gap manifests, each observed across multiple ecosystems. We exemplify these patterns as follows: a Build-context bleed-in. Broad copy or packaging steps pull unintended files into the artifact. In containers, the acme.sh image’s COPY ./ . captured a .git/config containing a GitHub token with push privileges (CVE-2025-32111). The same pattern appears in VS Code extensions that ship .git/, .env, and .ssh/ directories (6). b Provenance loss. Repackaging strips dependency attribution, leaving embedded code untracked. In Maven, shaded

Abhishek Reddypalle, Dennis Roellke, and Santiago Torres-Arias

uber-JARs relocate and rename classes, erasing the original package namespace and POM provenance trail (5). In VS Code extensions, JavaScript bundlers concatenate all dependencies into a single minified file, destroying per-package identity entirely (6). c Metadata divergence. A bundled dependency’s actual version disagrees with or is absent from the artifact’s declared metadata. Across our Jenkins plugin corpus, 57 plugins ship a JAR in WEB-INF/lib/ at a version that differs from what the POM declares(the SBOM reports a safe version while the physically bundled JAR is vulnerable (6)). In containers, our longitudinal analysis reveals untracked files in one release are only incorporated into official packages several versions later (4). d Post-build drift. Build-time side effects or runtime initialization produce files that persist without metadata coverage. The Jenkins ssh-agent image bakes SSH host keys generated during apt install openssh-server into the published image rather than deferring generation to runtime, enabling impersonation across container instances (CVE2025-32754, CVE-2025-32755). In enterprise environments, IaC provisioning retrieves binaries from remote hosts outside the package manager, producing files whose provenance is captured by no metadata channel (7). These patterns share a common structure: files are physically 1 present in the artifact yet absent from its declared metadata. However, they arise from distinct pipeline stages and packaging conventions, and they recur across technically disjoint ecosystems. Metadata-centric SCA tools cannot surface them by design, because these tools analyze declared state rather than physical contents. Ignoring this gap leads to a false sense of security: security teams may certify an artifact as vulnerability-free because their scanners only see tracked metadata, while high-severity risks(including those with CVSS scores up to 9.1) in the untracked files. The Darkfiles framework addresses this by alleviating an SBOM’s false-negatives, improving completeness rather than soundness.

3.2

Definition

To measure this phenomenon, we propose a general-purpose software quality metric calculated at the file level, quantifying the reach of metadata from the underlying package manager as the percentage of files not tracked by it. We first define the set of untracked files as Filesactual \ Filesasserted : files physically present in the artifact’s filesystem namespace but not asserted by its associated metadata. These files capture the raw provenance gap. However not all untracked files are equally concerning. We therefore define Software Dark Matter, SDM, as the security-relevant subset that survives a static reachability and influence filter Φ: files that are transitively reachable from an artifact’s entrypoints, or that exhibit sensitivity signals such as cryptographic key material or credentials. SDM = Φ(Filesactual \ Filesasserted )

(1)

where Φ is the static reachability filter defined in Section 3.4. Throughout this paper, when we report prevalence figures, we state explicitly 1 by physical, we refer to the fact that it is tangibly contained in the artifact, rather

than exclusively reported

Software Dark Matter: Gazing at Uncharted Files to Navigate SBOM Integrations

Conference’17, July 2017, Washington, DC, USA

Figure 2: Darkfiles analysis flow. The first passes obtain an exhaustive list of artifacts, which are then sorted into categories. Afterwards, a reachablity and influence analysis prioritizes SDM that may alter the behavior of a target artifact. • RQ3 Where does Software Dark Matter originate? What actions cause it? We identify the specific development, build, and distribution practices that produce SDM in each ecosystem, including which build stages introduce it, how it evolves, and which packaging conventions structurally obscure provenance. • RQ4 How does a project’s Software Dark Matter change over time? We identify trends in dark matter prevalence in artifacts over time, to gain insight on whether it behaves similarly to other software metrics which often increase or decrease with a project’s longevity.

whether a given measurement refers to the broader set of untracked files or to the reachability-filtered SDM.

3.3

Research Questions

To apply our measurement of Software Dark Matter, we examine ecosystems that excercise different parts of the modern software supply chain: (i) Container images from DockerHub, which serve as foundational base environments and are integrated into automated build workflows (ii) Maven Central artifacts, which are the primary distribution mechanism for Java libraries and undergo repackaging practices as part of their release pipelines (iii) Extension ecosystems such as Jenkins plugins and VS Code extensions, which are loaded by host applications at runtime and follow their own packaging and review processes independent of the host’s dependency graph (iv) A centrally managed enterprise Linux environment, where long-lived systems evolve through operational updates, provisioning workflows, and ongoing reconfiguration. Together, these settings capture image-based, library-based, host-mediated, and configuration-driven modes of software delivery and allow us to evaluate how SDM manifests across heterogeneous pipelines. Our approach using Darkfiles generalizes to all four ecosystems, as shown in Figure 2. We then utilize Darkfiles to investigate the following questions: • RQ1 Is Software Dark Matter a prevalent phenomenon? We quantify the extent to which the SBOM-asserted state diverges from the observed contents of an artifact, measuring the set of files present in the artifact but not accounted for by its metadata, to motivate the need for improved transparency and tooling and to validate the proper integration and usage of those tools. • RQ2 What are the security implications of Software Dark Matter? We apply the reachability and influence filter to the untracked files surfaced by RQ1 to obtain the SDM subset, and explore its potential security impact. Establishing whether SDM harbors security-relevant exposures enables stakeholders to recognize why the problem needs to be addressed and then to address these hidden risks proactively, ultimately to build better trust and compliance within software ecosystems.

Our work explicitly prioritizes identifying, measuring, and highlighting the phenomenon of Software Dark Matter rather than providing a comprehensive solution. We focus on demonstrating the existence and impact of dark matter to encourage future research and development aimed at addressing these critical gaps in current SBOM generation and management tooling.

3.4

Implementation

We implemented Darkfiles as an open-source, modular analysis tool that identifies untracked files and applies the reachability filter Φ to surface SDM. The analysis workflow proceeds through the passes illustrated in Figure 2. Unroll and Extraction. The first pass captures a complete, structured view of the target filesystem. For container images, Darkfiles pulls (i.e, downloads) and iterates over an image’s Open Container Initiative (i.e, OCI) layers to extract the files at each intermediate step. The layered filesystem architecture preserves differential changes(added, modified, or deleted artifacts) which enables per-layer analysis and correlation of untracked files with specific Dockerfile instructions. The same recursive-extraction approach generalizes to JAR archives (resolving nested JARs and transitive dependencies), extension packages, and multi-source manifest aggregation in enterprise environments similarly to Lamb et al [36]. Large Scale File to Package Index. A raw filesystem contains many routine artifacts like caches, logs, packaging-convention paths that must be distinguished from genuinely untracked files.

Conference’17, July 2017, Washington, DC, USA

Container

Package

Plugins

Enterprise

RQ1: Prevalence Power-Law shows fewer containers have high SDM, but still common Bi-Modal shows native packages either no SDM or high SDM Production grade obfuscation methods skew the analysis; source maps restore as observability side channel [redacted]

Abhishek Reddypalle, Dennis Roellke, and Santiago Torres-Arias

RQ2: Security 3 zero days reported, associated CVEs have High and Critical CVSS scores 100s of CVEs undetected by SCA tools, incl. widely used projects

RQ3: Origin File system layers like ADD and COPY introduce SDM Nesting/ Shading introduce SDM

RQ4: Half-Time SDM lags latest versions before it’s covered by meta-data, i.e. Packaging lag SDM does not change over time, supporting that it’s intentional/ systemic

about 1000 of CVEs are SBOM-invisble ; credential leak

Bundling/Vendoring dependencies introduces SDM

Not representative

Detected unused but executable turnscripts

IT automation/ Config management introduces SDM

[redacted]

Table 1: Summary of findings from Research Questions per Ecosystem

Darkfiles builds a compound known-files filter through three layers. A general filtering pass first removes transient noise (temporary files, logs, caches). Then, a precomputed file-to-package pass identifies files recognized by OS-level package managers: for Debian-based systems, our file2pkg module queries distribution repositories offline and generates a comprehensive SQL-based mapping database, currently spanning 5 major Debian and 6 Ubuntu distributions (∼100 GB of indexed data), providing deterministic provenance lookups far faster than per-file apt-file queries. Finally, configurable regex-based passes capture files declared or routinely produced by language-level tooling (e.g., site-packages/ for Python, node_modules/ for JavaScript, target/ and JAR layouts for Java. Paths matching these patterns are marked as known with provenance annotated as language-rule, aligning with the outputs that SBOM generators derive from manifest files such as requirements.txt, package.json, and pom.xml. This classification is not a security boundary, an attacker who places a malicious file inside a tracked path (e.g., a backdoored package in node_modules/) does not evade detection, because that file falls within the scope of conventional SCA tools, which already index and scan these locations. The filtering step is a scoping decision for Darkfiles to measure the gap that existing tooling leaves, not the space it already covers. Assertion and Surfacing. After filtering, Darkfiles produces a KnownFiles set where each path is linked to zero or more claimants (OS packages or language rules) and tagged with the pass that established the claim. Files are then sorted into two bins: tracked (claimed by at least one pass) and untracked (no claimant). For the reachability analysis: tracked files serve as traversal nodes in the call graph, while untracked files are the candidates that the analysis seeks to flag. Reachability and Influence. Not all untracked files are equally concerning, a stray log template poses less risk than an untracked shared library loaded at startup. To distinguish the two, Darkfiles

performs a static reachability analysis that identifies which untracked files can influence runtime behavior. The process begins with entrypoint discovery: identifying primary scripts, binaries, service units, or container entry commands by inspecting configuration files, manifests, and build metadata. Starting from each entrypoint, Darkfiles traverses reachable files using a conservative static call/reference graph whose edges include: • Interpreter and import chains: Following #! shebang lines, language-level imports (e.g., Python, Node.js), shell source statements, and similar inclusion mechanisms. • Binary linkage: Examining dynamic dependencies for ELF, PE, and Mach-O binaries, including interpreter paths, RPATH, LD_LIBRARY_PATH hints, and linked libraries [42]. • Configuration references: Scanning known config formats, entrypoint definitions, and manifest files for direct or indirect file-path references. When this traversal crosses from a tracked node into an untracked file, that file is classified as SDM and prioritized for review. The distinction matters since tracked files along the path are already visible to SCA tools and do not require additional attention, whereas the untracked files they reach represent blind spots that no metadata-driven pipeline would surface. For layered artifacts such as containers, Darkfiles additionally performs a deep-darkfiles analysis: it tracks files introduced in one layer and removed in a subsequent layer (e.g., via whiteout), surfacing build-time artifacts that persist in intermediate layers despite apparent deletion. Darkfiles is deliberately simple in its design. This simplicity allows it to generalize to various disjoint ecosystems with only policylevel configuration changes. Our evaluation spans thousands of artifacts across four ecosystems, a scale heavier-weight techniques would struggle with. Even with the design choice, the utility is evident given that we surfaced zero-day and thousands of previously invisible vulnerabilities. Limitations. The filtering passes in Darkfiles are configurable, allowing organizations to add custom exclusions tailored to their

Software Dark Matter: Gazing at Uncharted Files to Navigate SBOM Integrations

environments (see Section 7, where we apply this). Because the filter configuration is a policy parameter, prevalence figures reported throughout this paper represent a conservative, policy-driven lower bound rather than a definitive count. Tightening or loosening filters shifts the reported SDM percentage, so readers should interpret our numbers as a baseline under the specific filter set we describe. Our static reachability component favors precision over recall. It primarily resolves absolute paths and does not model argumentdependent exec calls or complex shell dynamics. Reachability tags should therefore be read as a conservative lower bound on the true reachable set. We prefer to miss a subset of dynamically reachable files rather than over-claim reachability.

4

Analysis of Container Ecosystems

Container images assemble software through heterogeneous pipelines like package-manager installs, ad-hoc downloads, multi-stage copies, and post-build configuration layered into a single deployable artifact. Because each mechanism can introduce files independently, the final image often contains components that no single metadata source fully describes. This makes containers a natural first target for measuring the gap between what metadata asserts and what the filesystem contains.[41, 72] The SCA tools most commonly applied to containers inherit the meta-data centric assumption discussed in Section 2: they identify packages by querying distribution databases and language-specific manifest paths, so any file installed outside those channels is invisible to the resulting SBOM. The analysis below uses Darkfiles to quantify, triage, and trace the origins of that invisible remainder. Data Collection and Methods. We analyzed Debian- and Ubuntubased images from the top 5,000 most-downloaded containers on DockerHub [18]. This collection spans minimal base images to complex multi-service applications and provides a representative cross-section of real-world container adoption. We focus on Debianfamily distributions because of their widespread usage in enterprise and open-source projects (approximately 50% of the top 5,000 images) and the availability of high-quality package metadata from which we build the file-to-package mapping infrastructure. Distribution classification relies on the os-release file in each image’s base layer [23]. Once retrieved, we apply the Darkfiles workflow of Section 3.4: each image’s layered filesystem is unrolled with per-layer context preserved, then passed through the filtering pipeline. For OS packages, file-to-package provenance is derived deterministically from official distribution mirrors, yielding stable, reproducible mappings for a given release. For language ecosystems, we apply per-language path rules that mirror how SBOM generators recognize package installations. Table 2 lists the exact regexes used for each ecosystem (those accounting for >1% of file removals) and the intent of each rule, allowing adaptation to other environments or SBOM pipelines.

4.1

RQ1: Prevalence of Untracked Files

Figure 3 shows the distribution of untracked-file percentages across the corpus. The distribution is wide: approximately 22% of images have less than 5% untracked files, yet no image has zero. Treating each container equally, the mean untracked-file percentage is 30% and the median is 21%, weighting by total file count raises the mean

Conference’17, July 2017, Washington, DC, USA

Hit-Rate %

Language

Pattern

Javascript[52] Python[64] Go[79] Node[52] Python[29] Ruby[69]

^.*node_modules/.*\check@icr 57.1909 ^/usr/(local/)?lib/python\d+.\d+/.*\check@icr 22.5072 ^/usr/local/go/.*\check@icr 10.4461 ^/(root|home/[^/]+)/.npm/.*\check@icr 1.1945 ^/(root|home/[^/]+)/.local/lib/python\d+.\d+/.*\[email protected] ^/usr/local/lib/ruby/gems/.*\check@icr 1.0417

Table 2: Language specification based ignore-patterns

to 37%. We exclude the first layer (the FROM base image or a COPY –from= multi-stage import) from these calculations because any untracked files introduced there are inherited by all downstream layers and thus attributable to the base-image supplier rather than the image author.

4.2

RQ2: Security Impact

Not all files are equally concerning. Through Darkfiles’s entrypointrooted reachability analysis (Section 3.4) we can narrow the triage set from the full untracked-file population of RQ1 to the SDM subset(files that are likely to influence runtime behavior). Across the corpus, this reachability filter reduces the triage space to approximately 1% of files on average, making manual review practical. Table 3 lists SDM files that recur across multiple images and that the reachability pass identifies as security-critical, including security-sensitive configurations and key material (e.g., sshd_config, ssh_host_rsa_key). These artifacts control environment initialization and service startup. If left untracked, they become blind spots for SBOM-based review despite being directly referenced from executable code. We further enrich the reachability triage with secret-detection signals informed by prior large-scale studies showing that container images frequently embed secrets and credentials [12, 71]. Together, the reachability, provenance, and sensitivity signals discovered the following vulnerabilities. Static SSH Host Keys in Jenkins Container Images (CVE2025-32754, CVE-2025-32755): Our analysis detected a vulnerability in the widely used Jenkins ssh-agent image. Jenkins, a leading open-source automation server with extensive enterprise usage for continuous integration and delivery pipelines, leverages the ssh-agent image to delegate workloads securely from controllers to agents. However, the ssh-agent image included pregenerated SSH host keys created during a build step that executed apt install openssh-server. These keys are intended to be generated at runtime to ensure uniqueness per deployment. However, since they were included in the image during build, identical keys are reused across every container instantiated from it. Darkfiles flagged the keys (e.g., /etc/ssh/ssh_host_rsa_key) as untracked because they are dynamically generated during package installation and do not appear in the package’s manifest. An attacker could exploit this flaw to impersonate a legitimate build agent or execute man-in-the-middle attacks by intercepting or altering build instructions, injecting malicious code, or exfiltrating sensitive credentials and build artifacts. We coordinated disclosure with the Jenkins security team, who acknowledged and patched both vulnerabilities

Conference’17, July 2017, Washington, DC, USA

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Abhishek Reddypalle, Dennis Roellke, and Santiago Torres-Arias

# Layer :2| Size :132.5 MB | Command :

RUN apt - get install ...

/ etc / ca - certificates . conf / etc / gitconfig / etc / group / etc / gshadow / etc / hosts . allow / etc / ssh / sshd_config / usr / bin / nc . traditional / usr / sbin / sysctl / var / lib / dpkg / alternatives / nc ...

Listing 1: List of files from unrolled container layers

File /opt/bitnami/scripts/liblog.sh /usr/bin/with-contenv /etc/supervisord.conf /etc/ssh/ssh_host_rsa_key /usr/sbin/enable_insecure_key

Images 63 30 28 7 13

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

{ " image ": " jenkins / ssh - agent :6.11.1" , " summary ": { " entrypoint_main ": " setup - sshd " , " roots ": ["/ usr / local / bin / setup - sshd "] , " reachable_nodes ": 6 , ... }, " callgraph ": { "/ usr / local / bin / setup - sshd ": [ "/ usr / sbin / sshd " ], "/ usr / sbin / sshd ": [ "/ lib64 / ld - linux - x86 -64. so .2" , "/ usr / lib / openssh / ssh - sk - helper " ... }

Listing 2: Callgraph

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

{ " summary ": { " layers_dir ": "..." , " num_layers ": 7 , " introduced_candidates ": 891 , " deep_darkfiles ": 266 }, " items ": [ { " path ": "/ install_acme . sh /. git / config ", " introduced_at_layer ": 2 , " removed_at_layer ": 3 , " removed_reason ": " whiteout ", " introduced_by ": "..." , " sensitivity_hint ": [ " git_config " ] } }

Listing 3: Darkfiles Deep-Report

Description & security impact Bitnami logging helper; tampering can suppress/audit-bypass logs or inject startup commands. s6-overlay env injector; can alter PATH and redirect exec before the main service. Supervisor config; can start extra daemons or change args/logging. SSH host private key; baked/reused keys enable impersonation/MITM across deployments. “Insecure key” toggle; reachable path to downgrade trust/auth (a security-off switch).

Table 3: Most frequently seen SDM in dockerhub and why it matters.

4.3

Figure 3: Untracked files in Popular DockerHub Images

promptly, issuing two separate CVEs, each receiving a CVSS score of 9.1, along with an official security advisory. Embedded GitHub Token in acme.sh Image (CVE-2025-32111): The acme.sh Docker image (over 42,000 GitHub stars [4]) contained a leaked GitHub token within its .git/config file. The token was introduced by a COPY ./ . instruction that unintentionally included the entire .git directory. Although a subsequent layer removed the file, the token persisted in Docker’s layered filesystem and was retrievable from intermediate layers. Darkfiles detected this transient but critical artifact through its deep-darkfiles analysis. The token granted unauthorized access to the project’s GitHub resources, enabling an attacker to trigger CI workflows, tamper with source code, or modify release artifacts. Upon disclosure, the maintainers eliminated unnecessary file copies in their Dockerfile. The CVE received a CVSS score of 8.7. These cases demonstrate that SDM surfaces concrete, exploitable vulnerabilities not merely theoretical gaps in widely deployed containerized environments.

RQ3: Causal Origins

Alongside the corpus-wide findings from RQ1 and the CVEs from RQ2, we identify three recurring origin categories for untracked files in containers. Ad-hoc materialization. Commands such as curl | bash, manual COPY operations, and unarchiving steps install software outside any package manager, producing binaries that never appear in an SBOM. Build-context bleed-in and ephemeral retention. Broad operations like COPY ./ . or rm -rf on sensitive directories cause two related problems: they pull unintended files into the image, and they leave residual artifacts in intermediate layers even when a later instruction deletes them. Post-build drift. Runtime initialization (e.g., first-run scripts that generate SSH keys, as in CVE-2025-32754/32755) and operational configuration changes introduce files after SBOM generation.

4.4

RQ4: Temporal Origins

To understand how Software Dark Matter evolves over time, we conducted a time series analysis of representative container image that consistently popular on DockerHub. Intuitively, most popular images are minimal, single-layer base images, such as Alpine or BusyBox. Instead, we illustrate our findings on the rare case of widely used more complex application that leverages a multi-layer build process and includes a variety of application-specific packages. In fact, it is based on Alpine and includes BusyBox - and with over 4.8 billion downloads it still ranks among the top 10 on DockerHub. Figure 4 shows that the proportion of Software Dark Matter can vary significantly between different versions. Our time series analysis considers a horizon looking back 5 years from today to when the project last changed its base image - coincidentally, when it switched to Alpine. In particular, the number of tracked files tends to increase over time as the size of packages increases. We

Software Dark Matter: Gazing at Uncharted Files to Navigate SBOM Integrations

observe a trend of files initially identified as dark in one version being gradually incorporated into packages in subsequent official releases. This suggests that the development and packaging of the project lag behind the content of the published container images. Meanwhile, each new release introduces fresh untracked files, creating a continuous cycle in which the metadata never fully converges with the artifact. Packaging Lag demonstrates that even projects with active packaging efforts can exhibit persistent SDM simply because the upstream packaging cadence trails the imagepublication cadence.

Conference’17, July 2017, Washington, DC, USA

5.1

Figure 5: % Untracked in suspicious maven projects

Figure 4: Packaging lag of a representative container project - grafana/grafana over 3 years(2021-24)

5.2 5

Analysis of Language Package Ecosystems

Native language package ecosystems are one of the core building blocks of the aforementioned container images. There is an abundance of programming language specific package manager implementations, s.a. npm for JavaScript and pypi for Python. We choose to study the the popular Java dependency management system Maven. Java Maven is along lived ecosystems that focuses on enterprise applications and provides clear guidelines on meta-data release, e.g., POM files, semantic versioning and use of a centralized repository, Maven Central. It’s maturity suggests absence of SDM and best in class SCA tool support, which makes it an ideal subject for our study.[74, 75] Data Collection and Methods. Our evaluation confirms that Maven Central projects employ great dependency management conventions. We did not find any SDM in the top 1,000 Maven Central Projects. So, we refined our filter to collect all packages that indicate dependency bundling. Matching package names on a keyword list (e.g., -embedded-, -internal-, -thirdparty-, etc.) yield a dataset of 4,889 latest packages (e.g, 0.6% of 803,000 Maven Central projects[77]). For each artifact we: (1) downloaded the JAR, source code, declared poml.xml (2) classify its files as: expected-external if they matched a declared dependency’s package roots, self/metadata if they belonged to the project itself, or untracked if no provenance. This mirrors the core SDM definition used throughout the paper, measuring divergence between asserted provenance and observed artifact contents(Java bytecode and Maven metadata here). To better support Maven practices, we identify untracked dependencies based on nesting and shading indicators (See Section 5 on RQ3).

RQ1: Prevalence of Untracked Files

SDM is prevalent in maven projects. We found indicators of SDM in 0.6% of latest Maven Central packages. The actual prevalence of SDM follows a binomial distribution: Either a package does not hide dependencies, e.g., 80.4% hide <10%, or it hides most of its dependencies, e.g., 10.6% hide >90%. Treating each dependency equally, the mean number of dependencies is 11.91 and the mean number of untracked dependencies is 5.67. We do not uncompress untracked dependencies to files because the volume of files is meaningless when a whole package is untracked. In our dataset, artifacts contain on average 11.91 dependencies, with roughly 5.67 hidden dependencies files per artifact.

RQ2: Security Impact

Maven is a popular ecosystem and shading and nesting are wellknown parts of it. Hence not every untracked package is a security concern, and we can expect competitive SCA tools to implement custom heuristics to find shaded dependencies beyond analyzing the project meta-data. Figure 6 shows the distribution of CVEs found in the untracked dependencies. In absolute numbers, Darkfiles identified 5,098 instances of untracked JARs at versions with known CVE associations.

5.3

RQ3: Causal Origins

SDM in Maven projects is primarily driven by attempts to solve to version conflicts. We identify that projects either shade or nest their dependencies. In practice, shading is achieved by one of three methods: (1) using the maven-shade-plugin (2) using the mavenshade-plugin + renaming/ relocating (3) not using the maven-shadeplugin, but revealing shading by naming convention (e.g. using gradle toolchain and cross publishing to Maven Central). Nesting is achieved bye one of three methods: (1) using the maven-assemblyplugin (2) using a framework like Spring Boot (3) Manually copied *.jar files in the file tree.

5.4

RQ4: Temporal Origins

Unlike containers, where SDM often arise from ad-hoc scripts or manual installs, Maven artifacts highlight a structural issue in the Java ecosystem: shading is intentional. SBOMs derived from POM metadata will systematically miss these embedded classes. Prior work has shown that "hidden" or outdated components can persist deep inside released artifacts for ecosystem- and architecturespecific reasons, including shading/ cloning and build-system indirections [15, 46, 60]. These studies often use fingerprinting or

Conference’17, July 2017, Washington, DC, USA

Figure 6: % SDM in suspicious maven projects

clone-style matching to rediscover vulnerable embedded components/classes post hoc.

Abhishek Reddypalle, Dennis Roellke, and Santiago Torres-Arias

VS Code extensions. We collected metadata for the top 3̃,000 extensions on Open VSX prioritized by download count, downloading and scanning each .vsix artifact. Each extension’s declared dependency set was extracted from its root package.json. To identify undeclared bundled packages, we used four complementary signals: shipped node_modules/ subtrees (which retain per-package package.json files giving exact identity), webpack *.LICENSE.txt sidecars (from which version strings can be speculatively extracted for ∼10% of bundled packages) and and sourcemap paths in 5̃70 extensions. Root-level lock files were present in 1̃00 extensions but contributed little additional signal, as most appeared to be stale artifacts from upstream repositories rather than authoritative records of the bundled content.

6.1 6

RQ1: Prevalence of Untracked Files

Analysis of Extensions Ecosystems

We now turn to a class of artifacts absent from the prior analyses: Extensions, also referred to as plugins or add-ons. Similar to to containers and native packages, extensions are distributed via registries, most commonly Marketplaces. This naming difference highlights the difference in intend between these ecosystems. Extensions require a host process/ platform they extend with non-standard features, and these non-standard features are commonly monetized. In conclusion, extensions are high stake and should be held to highest project management and security hygiene standards, making them another ideal target for our study. Recent studies have examined the behavioral security of CI plugins[27, 38] and IDE extensions[39], identifying over-privileged and vulnerable bundled artifacts. Our analysis is complementary, rather than studying what extensions do, we measure what they contain that is invisible to metadata-driven analysis. We study two instances: Jenkins plugins (.hpi archives loaded into a CI/CD server JVM) and VS Code extensions (.vsix archives loaded into a developer’s editor via the Open VSX registry [17]). Both physically bundle third-party code whose identity is absent from any registry-facing manifest, making metadata-driven SCA underperform when analyzing these artifacts. The two platforms occupy opposite ends of the privilege spectrum and therefore pose different risks when SDM is present. Jenkins plugins execute server-side with access to build secrets, signing keys, and downstream deployment pipelines which means a single vulnerable bundled library can yield remote code execution on the build host. Jenkins also exposes a classloader inheritance mechanism whereby Plugin 𝐴 can load classes from Plugin 𝐵’s bundled JARs at runtime, without any copy appearing in 𝐴’s own archive, an SDM propagation channel invisible to every existing SBOM model. VS Code extensions execute client-side on the developer’s workstation, with access to the local file system, source code, and stored credentials. This can result in harm including credential theft, source-code exfiltration, and lateral movement into organizations. The same finding (a bundled dependency with a known vulnerability), therefore carries different exploitation paths depending on the platform. Data Collection and Methods. Jenkins plugins. We collected all 2066 plugins from the Jenkins Update Center; 1891 contained at least one nested JAR. Darkfiles, configured for the nesting and shading heuristics (Section 5) recovered 1501 JARs across 425 plugins that lacked standard metadata.

Jenkins plugins. After full transitive dependency expansion, the mean untracked percentage across 1102 plugins is 10.0% (median 0%). A total of 1737 untracked JAR instances remain across 318 plugins, and 74 plugins have a majority of their bundled JARs untracked. An additional 57 plugins bundle a JAR at a version that differs from what their POM declares making the SBOM not merely incomplete but actively misleading. VS Code extensions. Among the 1,249 analyzed extensions, the majority that ship dependencies do so without declaring them: fewer than 2% populate the npm bundledDependencies field, and the VSIX manifest carries no structured record of bundled code. Critically, we can only positively assert bundled file provenance for the subset of extensions that ship raw node_modules/ directories, source maps with pnpm-style versioned paths(source maps from extensions built with pnpm embed the package version directly in the content-addressed store path), or webpack license comments—a small fraction of the ecosystem. For these, every undeclared package is individually identifiable yet invisible to any metadata-driven SCA tool. The majority of extensions, however, use a JavaScript bundler (webpack, esbuild, rollup) that concatenates all dependencies into a single minified output, destroying per-package attribution entirely. Recovering provenance from these artifacts would require "unbundling" by segmenting the minified bundle into per-module spans and matching each against fingerprints (e.g., locality-sensitive hashes such as TLSH [85]) computed over the full npm package corpus which is a substantially harder problem than Maven shading, where .class files retain their original package namespaces, and one we scope as future work. Our prevalence figures for openvsx is therefore a conservative lower bound restricted to the observable fraction of the registry.

6.2

RQ2: Security Impact

Jenkins plugins. Cross-referencing all resolved JARs against a database of 20 widely-exploited library families identified 648 vulnerable JAR instances across 381 plugins, covering approximately 200,000 installations. Of these, 54.6% are invisible or misleading to SBOM-based scanners: either entirely absent from declared dependency metadata or declared at a safe version while the physically bundled JAR is vulnerable. The most affected libraries include Apache HttpClient (189 plugins), jackson-databind (140 plugins), and SnakeYAML (31 plugins, CVSS Critical).

Software Dark Matter: Gazing at Uncharted Files to Navigate SBOM Integrations

Beyond direct bundling, the classloader inheritance graph exposes 80 additional vulnerable JAR instances affecting 48 plugins whose archives contain no copy of the vulnerable JAR. Among the 33 plugins uniquely surfaced through this channel are highinstallation maintained plugins such as sonar (50,476 installs) and pipeline-maven (26,768 installs). Notably, plugins marked adoptthis-plugin or deprecated which account for 33 of 84 CRITICAL instances despite serving only ∼12% of the install base remain depended upon by actively maintained downstream plugins, propagating their untracked vulnerabilities across the plugin graph with no active maintainer to remediate. VS Code extensions. Among 187 extensions with identifiable untracked packages, we found 1259 packages matching known CVEs (132 CRITICAL, 619 HIGH, 508 MODERATE/LOW), all absent from the extension’s declared dependencies. We identified a top-downloaded extension [redacted] that ships 88 untracked packages against only 14 declared, including dependencies at versions affected by high-severity CVEs such as prototype pollution and denial-of-service vulnerabilities. The extension’s architecture suggests a plausible attack surface through which these untracked vulnerabilities could be exploited. We are currently in coordinated disclosure with the extension’s maintainers and withhold identifying details until remediation is complete. Beyond vulnerable packages, our file-level enumeration surfaces build-context bleed-in invisible to advisory-driven scanning: extensions shipping .claude/ and .copilot/ directories (AI-assistant session data and cached credentials), .env files, .ssh/ directories, and residual .git/ histories, a parallel to CVE-2025-32111 (Section 4), now distributed through a trusted extension marketplace. Responsible Disclosure. We have reported all vulnerabilities identified to the affected parties. For Jenkins plugins, disclosures were coordinated with the Jenkins security team, including plugins maintained by the Jenkins project itself. For VS Code extensions, we contacted the individual extension maintainers. Disclosures are currently under review and patches are expected in upcoming releases. At the time of writing, disclosures remain under review and identifying details are withheld pending remediation. If accepted we will update this section with full details.

6.3

Conference’17, July 2017, Washington, DC, USA

no dependency information; and (4) JavaScript bundlers erase perpackage attribution, requiring the corpus-scale unbundling approach described in RQ1 to recover provenance.

6.4

RQ4: Temporal Origins

Figure 7: Jenkins plugin: update cadence of dark vs. tracked JARs across versions Jenkins plugins. Consistent with the Maven analysis, SDM in Jenkins plugins does not disappear over time. Figure 7 illustrates this through a plugin(most dark jars amongst the most popular), Jenkins Artifactory with 153 versions from 2.8.0 to 4.0.8. It has tracked dependencies such as docker-java and jackson-databind receive frequent version bumps, while untracked ones such as netty-codec are updated measurably less often. However, the untracked dependencies are updated, which implies that plugin maintainers are aware of their existence and perform at least some dependency hygiene on them. This reinforces the Maven finding that SDM is not accidental but systemic: developers knowingly embed and maintain these dependencies, yet the artifacts they produce offer no metadata through which downstream consumers could discover, audit, or respond to vulnerabilities in them. The producer has visibility but the consumer is blind and no amount of SBOM tooling applied at the consumer side can close that gap without cooperation from the producer’s build pipeline. VS Code extensions. For causal inference, we used source maps as a sidechannel that provides sufficient information, but we were not able to conduct a longitudinal analysis of VS Code extensions on this data source.

RQ3: Causal Origins

Jenkins plugins. Untracked JARs in Jenkins originate primarily from pre-Maven-era artifacts (which lack standard coordinates and are unresolvable by any declarative SBOM tool), split-modular Maven projects whose sub-module JARs are not enumerated by the parent POM, and JARs placed directly into WEB-INF/lib/ to pin a version or incorporate a vendor SDK outside Maven’s resolution. The common thread is that all three paths bypass Maven’s dependency model, so build-time SBOM tools which consume the Maven model as their source of truth never see these files. VS Code extensions. SDM in VS Code extensions compounds from four failures: (1) the .vsixignore exclusion mechanism is opt-in and widely omitted, sweeping developer credentials and tooling state into the artifact; (2) the bundledDependencies field in package.json (npm mechanism explicitly designed for it) is populated by fewer than 2% of extensions; (3) the VSIX manifest records

7

Analysis of Enterprise Systems

The preceding sections measured SDM in public container images, Maven artifacts, and extension marketplaces. To test whether the phenomenon generalizes to fully managed infrastructure, we apply Darkfiles to production hosts at a large software company (~9,000 engineers) that operates organization-wide SCA integration, persisted CI metadata, and deploys on a commercial Linux distribution under a maintenance agreement. In this setting where every file on managed hosts is expected to be accounted for, SDM serves as a proxy for provenance-coverage gaps in the deployment pipeline. We adapt the Darkfiles workflow as follows. The asserted state is derived by aggregating OS-level package metadata and stored CI-generated SBOMs. Proprietary application bundles installed in locked-down directories via the managed pipeline are trusted and excluded. The observed state is inventoried at fleet scale from the

Conference’17, July 2017, Washington, DC, USA

enterprise EDR file tables [] (paths, types, permissions, timestamps, hashes), replacing Darkfiles’s own crawler. We apply the standard exclusions from Section 5 (transient paths such as /dev, /run, caches, logs, and UI assets), normalize paths and symlinks, align asserted and observed views, and compute per-host diffs of untracked, missing, and hash-mismatched files. After de-duplicating untracked files across hosts, we traced their provenance using the company’s internal VCS and configuration repositories. Infrastructure-as-Code (IaC) and configurationmanagement frameworks are designed to declaratively specify system state, translating high-level infrastructure requirements into reproducible deployments. However, our analysis revealed that these systems are the dominant source of SDM inline with Rahma et al work [66–68]. Provisioning runs routinely retrieve and place external artifacts(binaries, scripts, and configuration fragments) from remote hosts outside the package manager’s purview, producing files whose provenance is captured by no metadata channel. Most notably, we detected downloads originating from abandoned hosting infrastructure that had subsequently been taken down, rendering the provenance trail for those files entirely unverifiable. SDM further included operational tooling for telemetry and monitoring: scripts critical to fleet operations yet invisible to the SBOM-driven governance pipeline. These findings confirm that SDM persists even under best-practice enterprise conditions (RQ1) and that its primary origin in managed environments is post-deployment drift like provisioning workflows, IaC-driven fetches, and out-of-band operational changes that introduce files after build-time SBOM generation (RQ3). The security implication (RQ2) is that SBOM-driven governance cannot assume completeness at build time. It requires a continuous reconciliation loop to detect drift in long-lived infrastructure. Following our report, the company responded by packaging previously untracked files, eliminating unnecessary bloat, and integrating Darkfilesstyle validation into their provisioning pipeline, demonstrating that SDM analysis yields actionable remediation even in mature, centrally managed environments.

8

Eliminating Software Dark Matter

Software Dark Matter is ultimately a consequence of the informational gap between what a build pipeline produces and what its metadata captures. Across the ecosystems we studied, SDM consistently traces back to a small number of pipeline stages – a careless copy instruction, a shading plugin, a provisioning script that fetches binaries out-of-band – yet these stages are precisely the ones invisible to metadata-centric tooling. Once surfaced, each instance of dark matter presents maintainers with a concrete choice: fold it into the SBOM, remove it, or accept it as a known gap. The key insight is that this triage does not require new tooling per artifact type. The same provenance-and-reachability workflow generalizes from container layers to shaded JARs to bundled extensions to enterprise hosts. A “Darkfiles-before-SBOM” step in the build pipeline converts dark matter from an undisclosed omission into an explicit quality signal: either the provenance gap is resolved before the SBOM is published, or it is labeled as an open issue that warrants attention. Over time, this feedback loop also improves tooling itself,

Abhishek Reddypalle, Dennis Roellke, and Santiago Torres-Arias

as engineers can identify recurring patterns of metadata loss and build targeted fixes into their pipelines and generators. Addressing SDM instance by instance, however, is insufficient. The root cause is that current SBOM generation is decoupled from supply chain processes: tools reconstruct provenance after the fact from metadata that was never designed to be complete. Eliminating dark matter systematically requires tightly coupling transparency metadata generation to the build itself, so that provenance is captured at the point of creation rather than inferred later. Efforts like SBOMit [58] point in this direction by leveraging higher-fidelity build attestations, such as those produced by in-toto [83] and its Witness [90] implementation, to produce SBOMs grounded in what the build actually did.[5, 50] Similarly, Debian’s buildinfo ties package contents to a reproducible build record. Contemporary work like LastPyMile [86], PyRadar [24], and CovSBOM [95] has independently identified step-specific instances of divergence between artifact contents and declared metadata. The SDM framing unifies workstream under a single theoretical framework, and that Darkfiles provides the measurement infrastructure to evaluate whether these emerging approaches succeed in closing the gap.

9

Conclusions

In this paper, we introduced Software Dark Matter (SDM), a generalpurpose metric that quantifies the divergence between the files physically present in a software artifact and those asserted by its metadata. We measured SDM using Darkfiles, a modular analysis tool that combines exhaustive file extraction, a large-scale file-to-package index, and a static reachability filter to surface the security-relevant subset of untracked files. We evaluated Darkfiles across disjoint ecosystems - DockerHub containers, Maven Central artifacts, Jenkins plugins, VS Code extensions, and a production enterprise environment – and demonstrated that SDM is not an edge case but a prevalent, structurally rooted phenomenon arising from recurring patterns: build-context bleed-in, provenance loss through repackaging, metadata divergence, and post-build drift. We observed "Packaging Lag", in which metadata trails artifact contents across multiple releases before converging. The security implications are concrete: SDM harbors CVEs invisible to SBOMdriven pipelines, and our analysis led to the zero-day discovery of three confirmed high-severity vulnerabilities in widely deployed projects. These findings show that incomplete SBOMs do reduce transparency and cause a false sense of security on deployed software. SBOMs remain the most promising mechanism for supply chain transparency, but the tools that populate them rely on metadata that was never designed to be complete. Addressing SDM requires both filesystem-grounded validation integrated into build pipelines and a rethinking of development practices to minimize divergence between what is built and what is declared. We release Darkfiles as open-source infrastructure to support this effort.

References [1] Synopsys: 84% of codebases contain an open source vulnerability, April 2021. URL https://venturebeat.com/entrepreneur/synopsys-84-of-codebases-containan-open-source-vulnerability/. [2] National telecommunications and information administration software bill of materials multistakeholder process, 2022. URL https://ntia.gov/page/softwarebill-materials.

Software Dark Matter: Gazing at Uncharted Files to Navigate SBOM Integrations

[3] Oci image manifest specification, 2024. URL https://github.com/opencontainers/ image-spec/blob/main/manifest.md. [4] acmesh-official. acmesh-official/acme.sh: A pure unix shell script implementing acme client protocol. https://github.com/acmesh-official/acme.sh, 2026. GitHub repository (README and project metadata). Accessed: 2026-02-06. [5] Paschal C. Amusuo, Kyle A. Robinson, Tanmay Singla, Huiyun Peng, Aravind Machiry, Santiago Torres-Arias, Laurent Simon, and James C. Davis. Ztdjava: Mitigating software supply chain vulnerabilities via zero-trust dependencies. In Proceedings of the IEEE/ACM 47th International Conference on Software Engineering, ICSE ’25, page 1294–1306. IEEE Press, 2025. ISBN 9798331505691. doi: 10.1109/ ICSE55347.2025.00148. URL https://doi.org/10.1109/ICSE55347.2025.00148. [6] Musard Balliu, Benoit Baudry, Sofia Bobadilla, Mathias Ekstedt, Martin Monperrus, Javier Ron, Aman Sharma, Gabriel Skoglund, César Soto-Valero, and Martin Wittlinger. Challenges of producing software bill of materials for java. IEEE Security & Privacy, 21(6):12–23, November 2023. ISSN 1558-4046. doi: 10.1109/msec.2023.3302956. URL http://dx.doi.org/10.1109/MSEC.2023.3302956. [7] Jacopo Bufalino, Mario Di Francesco, Agathe Blaise, and Stefano Secci. Sbomproof: Beyond alleged sbom compliance for supply chain security of container images, 2025. URL https://arxiv.org/abs/2510.05798. [8] Reproducible Builds. diffoscope: in-depth comparison of files, archives, and directories, 2025. URL https://diffoscope.org/. Accessed: 2025-09-12. [9] Cybersecurity and Infrastructure Security Agency. CISA Log4j (CVE-2021-44228) Vulnerability Guidance, August 2022. URL https://github.com/cisagov/log4jaffected-db. original-date: 2021-12-13T14:59:54Z. [10] Cybersecurity and Infrastructure Security Agency. Apache Log4j Vulnerability Guidance | CISA, 2026. URL https://www.cisa.gov/uscert/apache-log4jvulnerability-guidance. [11] Cybersecurity and Infrastructure Security Agency (CISA). Types of software bill of materials (sbom), 2023. URL https://www.cisa.gov/resources-tools/resources/ types-software-bill-materials-sbom. Accessed: 2025-09-12. [12] Markus Dahlmanns, Constantin Sander, Robin Decker, and Klaus Wehrle. Secrets revealed in container images: An internet-wide study on occurrence and impact. In Proceedings of the 2023 ACM Asia Conference on Computer and Communications Security, ASIA CCS ’23, page 797–811, New York, NY, USA, 2023. Association for Computing Machinery. ISBN 9798400700989. doi: 10.1145/3579856.3590329. URL https://doi.org/10.1145/3579856.3590329. [13] 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, 2022. doi: 10.1109/TSE. 2021.3101739. [14] Lachlan Davidson. React2shell (cve-2025-55182), 2025. URL https://react2shell. com/. Accessed: 2026-02-06. [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, page 77–87, New York, NY, USA, 2024. Association for Computing Machinery. ISBN 9798400712401. doi: 10.1145/3689944.3696165. URL https://doi.org/10.1145/ 3689944.3696165. [16] Phuc Doan and Souhwan Jung. Davs: Dockerfile analysis for container image vulnerability scanning. Computers, Materials & Continua, 72:1699–1711, 02 2022. doi: 10.32604/cmc.2022.025096. [17] Eclipse Foundation. Open VSX registry. https://open-vsx.org. Accessed: 202602-06. [18] Ecosyste.ms. Dependency metadata for docker images. URL https://docker. ecosyste.ms/packages?order=desc&sort=downloads. [19] Yekatierina Churakova Mathias Ekstedt. Vexed by vex tools: Consistency evaluation of container vulnerability scanners, 2025. URL https://arxiv.org/abs/2503. 14388. [20] Robert J. Ellison, John B. Goodenough, Charles B. Weinstock, and Carol Woody. Evaluating and Mitigating Software Supply Chain Security Risks. Technical report, CARNEGIE-MELLON UNIV PITTSBURGH PA SOFTWARE ENGINEERING INST, May 2010. URL https://apps.dtic.mil/sti/citations/ADA522538. Section: Technical Reports. [21] Content EU Directorate-General for Communications Networks and Technology. Cyber resilience act, 2025. URL https://digital-strategy.ec.europa.eu/en/policies/ cyber-resilience-act. [22] Marcel Fourné, Dominik Wermke, William Enck, Sascha Fahl, and Yasemin Acar. It’s like flossing your teeth: On the importance and challenges of reproducible builds for software supply chain security. In 2023 IEEE Symposium on Security and Privacy (SP), pages 1527–1544, 2023. doi: 10.1109/SP46215.2023.10179320. [23] freedesktop.org. os-release: Operating system identification. freedesktop.org specification, n.d. URL https://www.freedesktop.org/software/systemd/man/ latest/os-release.html. Accessed 2026-02-06. [24] Kai Gao, Weiwei Xu, Wenhao Yang, and Minghui Zhou. Pyradar: Towards automatically retrieving and validating source code repository information for pypi packages. Proc. ACM Softw. Eng., 1(FSE), July 2024. doi: 10.1145/3660822. URL https://doi.org/10.1145/3660822.

Conference’17, July 2017, Washington, DC, USA

[25] 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. [26] Pronnoy Goswami, Saksham Gupta, Zhiyuan Li, Na Meng, and Daphne Yao. Investigating the reproducibility of npm packages. In 2020 IEEE International Conference on Software Maintenance and Evolution (ICSME), pages 677–681, 2020. doi: 10.1109/ICSME46990.2020.00071. [27] Yacong Gu, Lingyun Ying, Huajun Chai, Chu Qiao, Haixin Duan, and Xing Gao. Continuous intrusion: Characterizing the security of continuous integration services. In 2023 IEEE Symposium on Security and Privacy (SP), pages 1561–1577, 2023. doi: 10.1109/SP46215.2023.10179471. [28] Andreas Halbritter and Dominik Merli. Accuracy evaluation of sbom tools for web applications and system-level software. In Proceedings of the 19th International Conference on Availability, Reliability and Security, ARES ’24, New York, NY, USA, 2024. Association for Computing Machinery. ISBN 9798400717185. doi: 10.1145/3664476.3670926. URL https://doi.org/10.1145/3664476.3670926. [29] Christian Heimes. PEP 370: Per user site-packages directory, 2008. URL https: //peps.python.org/pep-0370/. Accessed 2026-02-06. [30] 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). ACM, oct 2021. doi: 10.1145/3475716.3475769. URL https://doi.org/10.1145/2F3475716.3475769. [31] E. Ivanova, N. Stakhanova, and B. Sistany. Adversarial analysis of software composition analysis tools. In N. Mouha and N. Nikiforakis, editors, Information Security. ISC 2024, volume 15258 of Lecture Notes in Computer Science, pages 146–165. Springer, Cham, 2025. doi: 10.1007/978-3-031-75764-8_9. URL https: //doi.org/10.1007/978-3-031-75764-8_9. [32] Omar Javed and Salman Toor. An evaluation of container security vulnerability detection tools. In Proceedings of the 2021 5th International Conference on Cloud and Big Data Computing, ICCBDC ’21, page 95–101, New York, NY, USA, 2021. Association for Computing Machinery. ISBN 9781450390408. doi: 10.1145/ 3481646.3481661. URL https://doi.org/10.1145/3481646.3481661. [33] Nobutaka Kawaguchi, Charles Hart, and Hiroki Uchiyama. Understanding the effectiveness of sbom generation tools for manually installed packages in docker containers. Journal of Internet Services and Information Security, 14(3):191–212, August 2024. ISSN 2182-2069. doi: 10.58346/JISIS.2024.I3.011. URL https://jisis. org/article/2024.I3.011/71288/. Accessed: 2025-04-08. [34] Mehdi Keshani, Tudor-Gabriel Velican, Gideon Bot, and Sebastian Proksch. Aroma: Automatic reproduction of maven artifacts. Proc. ACM Softw. Eng., 1 (FSE), July 2024. doi: 10.1145/3643764. URL https://doi.org/10.1145/3643764. [35] Piergiorgio Ladisa, Henrik Plate, Matias Martinez, and Olivier Barais. Taxonomy of Attacks on Open-Source Software Supply Chains, April 2022. URL http: //arxiv.org/abs/2204.04008. arXiv:2204.04008 [cs]. [36] Chris Lamb and Stefano Zacchiroli. Reproducible builds: Increasing the integrity of software supply chains. IEEE Software, 39(2):62–70, 2021. [37] Jasmine Latendresse, Suhaib Mujahid, Diego Elias Costa, and Emad Shihab. Not all dependencies are equal: An empirical study on production dependencies in npm. In Proceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering, ASE ’22, New York, NY, USA, 2023. Association for Computing Machinery. ISBN 9781450394758. doi: 10.1145/3551349.3556896. URL https://doi.org/10.1145/3551349.3556896. [38] Xiaofan Li, Yacong Gu, Chu Qiao, Zhenkai Zhang, Daiping Liu, Lingyun Ying, Haixin Duan, and Xing Gao. Toward understanding the security of plugins in continuous integration services. In Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, CCS ’24, page 482–496, New York, NY, USA, 2024. Association for Computing Machinery. ISBN 9798400706363. doi: 10.1145/3658644.3670366. URL https://doi.org/10.1145/3658644.3670366. [39] Elizabeth Lin, Igibek Koishybayev, Trevor Dunlap, William Enck, and Alexandros Kapravelos. Untrustide: Exploiting weaknesses in vs code extensions. 01 2024. doi: 10.14722/ndss.2024.24073. [40] Linklaters. Eu omnibus i: Csrd and cs3d amendments finalised: what do you need to know?, 2025. URL https://sustainablefutures.linklaters.com/post/102ly34/euomnibus-i-csrd-and-cs3d-amendments-finalised-what-do-you-need-toknow. [41] Peiyu Liu, Shouling Ji, Lirong Fu, Kangjie Lu, Xuhong Zhang, Wei-Han Lee, Tao Lu, Wenzhi Chen, and Raheem Beyah. Understanding the security risks of docker hub. In Computer Security – ESORICS 2020: 25th European Symposium on Research in Computer Security, ESORICS 2020, Guildford, UK, September 14–18, 2020, Proceedings, Part I, page 257–276, Berlin, Heidelberg, 2020. Springer-Verlag. ISBN 978-3-030-58950-9. doi: 10.1007/978-3-030-58951-6_13. URL https://doi. org/10.1007/978-3-030-58951-6_13. [42] man-pages project. ld.so(8) — linux dynamic linker/loader. man7.org Linux manpages, n.d. URL https://man7.org/linux/man-pages/man8/ld.so.8.html. Accessed 2026-02-06.

Conference’17, July 2017, Washington, DC, USA

[43] Angelika Maratos, Evan Lubinsky, Jessica Methman, Jill Surti, and Leo Peele. Supply chain security: The role of sboms and vex in cyber risk mitigation. IT Lab: Summer Security Intensive, 2025. [44] Marcela S. Melara and Santiago Torres-Arias. A viewpoint on software supply chain security: Are we getting lost in translation? IEEE Security & Privacy, 21(6): 55–58, 2023. doi: 10.1109/MSEC.2023.3316568. [45] Michael Meli, Matthew R. McNiece, and Bradley Reaves. How bad can it git? characterizing secret leakage in public github repositories. Proceedings 2019 Network and Distributed System Security Symposium, 2019. URL https://api. semanticscholar.org/CorpusID:142503706. [46] Amir M. Mir, Mehdi Keshani, and Sebastian Proksch. On the effect of transitivity and granularity on vulnerability propagation in the maven ecosystem. In 2023 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER), pages 201–211, 2023. doi: 10.1109/SANER56733.2023.00028. [47] National Vulnerability Database. NVD - CVE-2021-44228, 2021. URL https: //nvd.nist.gov/vuln/detail/CVE-2021-44228. [48] National Vulnerability Database. NVD - CVE-2021-45046, 2021. URL https: //nvd.nist.gov/vuln/detail/CVE-2021-45046. [49] Shradha Neupane, Grant Holmes, Elizabeth Wyss, Drew Davidson, and Lorenzo De Carli. Beyond typosquatting: An in-depth look at package confusion. In 32nd USENIX Security Symposium (USENIX Security 23), pages 3439–3456, Anaheim, CA, August 2023. USENIX Association. ISBN 978-1-939133-37-3. URL https://www.usenix.org/conference/usenixsecurity23/presentation/neupane. [50] Zachary Newman, John Speed Meyers, and Santiago Torres-Arias. Sigstore: Software Signing for Everybody. In Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, CCS ’22, pages 2353–2367, New York, NY, USA, 2022. Association for Computing Machinery. ISBN 978-1-4503-9450-5. doi: 10.1145/3548606.3560596. URL https://doi.org/10.1145/3548606.3560596. [51] nexB Inc. Container sbom clarity project: Public report. Technical report, nexB Inc., November 2024. URL https://nexb.com/sca-containers/. [52] npm, Inc. Folders (npm documentation). https://docs.npmjs.com/cli/v10/ configuring-npm/folders/, 2026. Describes local installs in ./node_modules and cache in ~/.npm. Accessed: 2026-02-06. [53] 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. ISBN 9798400712401. doi: 10.1145/ 3689944.3696164. URL https://doi.org/10.1145/3689944.3696164. [54] Department of Homeland Security Cyber Safety Review Board. Review of the December 2021 Log4j Event, July 2022. URL https://www.cisa.gov/sites/default/ files/publications/CSRB-Report-on-Log4-July-11-2022_508.pdf. [55] 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. doi: doi.org/10.1007/978-3-030-526832\_2. [56] Chinenye Okafor, Taylor R. Schorlemmer, Santiago Torres-Arias, and James C. Davis. Sok: Analysis of software supply chain security by establishing secure design properties. In Proceedings of the 2022 ACM Workshop on Software Supply Chain Offensive Research and Ecosystem Defenses, SCORED’22, page 15–24, New York, NY, USA, 2022. Association for Computing Machinery. ISBN 9781450398855. doi: 10.1145/3560835.3564556. URL https://doi.org/10.1145/3560835.3564556. [57] Open Source Software Security Foundation (OpenSSF). Improving risk management decisions with sbom data, 2025. URL https://openssf.org/resources/ improving-risk-management-decisions-with-sbom-data/. [58] OpenSSF Foundation. Openssf sbomit project, 2025. URL https://sbomit.dev. Accessed: 2025-09-12. [59] Can Ozkan, Xinhai Zou, and Dave Singelee. Supply chain insecurity: The lack of integrity protection in sbom solutions, 2025. URL https://arxiv.org/abs/2412. 05138. [60] Ivan Pashchenko, Henrik Plate, Serena Elisa Ponta, Antonino Sabetta, and Fabio Massacci. Vulnerable open source dependencies: counting those that matter. In Proceedings of the 12th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement, ESEM ’18, New York, NY, USA, 2018. Association for Computing Machinery. ISBN 9781450358231. doi: 10.1145/3239235.3268920. URL https://doi.org/10.1145/3239235.3268920. [61] Arun Azhakesan Philippe Ombredanne. Sca for containers: The good, the bad and the truth. URL https://osseu2024.sched.com/event/1ej58/sca-for-containersthe-good-the-bad-and-the-truth-arun-azhakesan-siemens-healthineersphilippe-ombredanne-aboutcode. [62] Gede Artha Azriadi Prana, Abhishek Sharma, Lwin Khin Shar, Darius Foo, Andrew E. Santosa, Asankhaya Sharma, and David Lo. Out of sight, out of mind? how vulnerable dependencies affect open-source projects. Empirical Softw. Engg., 26(4), July 2021. ISSN 1382-3256. doi: 10.1007/s10664-021-09959-3. URL https://doi.org/10.1007/s10664-021-09959-3. [63] Package URL (purl) Authors. Package url (purl) specification, 2025. URL https: //github.com/package-url/purl-spec. Accessed: 2025-04-08.

Abhishek Reddypalle, Dennis Roellke, and Santiago Torres-Arias

[64] Python Software Foundation. site — site-specific configuration hook (python standard library). https://docs.python.org/3/library/site.html, 2026. Gives example installation prefix /usr/local leading to /usr/local/lib/pythonX.Y and site-packages layout. Accessed: 2026-02-06. [65] Md Fazle Rabbi, Arifa Islam Champa, Costain Nachuma, and Minhaz Fahim Zibran. Sbom generation tools under microscope: A focus on the npm ecosystem. In Proceedings of the 39th ACM/SIGAPP Symposium on Applied Computing, SAC ’24, page 1233–1241, New York, NY, USA, 2024. Association for Computing Machinery. ISBN 9798400702433. doi: 10.1145/3605098.3635927. URL https: //doi.org/10.1145/3605098.3635927. [66] Akond Rahman, Chris Parnin, and Laurie Williams. The seven sins: Security smells in infrastructure as code scripts. In 2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE), pages 164–175, 2019. doi: 10.1109/ ICSE.2019.00033. [67] Akond Rahman, Md Rayhanur Rahman, Chris Parnin, and Laurie Williams. Security smells in ansible and chef scripts: A replication study. ACM Trans. Softw. Eng. Methodol., 30(1), January 2021. ISSN 1049-331X. doi: 10.1145/3408897. URL https://doi.org/10.1145/3408897. [68] Akond Rahman, Shazibul Islam Shamim, Dibyendu Brinto Bose, and Rahul Pandita. Security misconfigurations in open source kubernetes manifests: An empirical study. ACM Trans. Softw. Eng. Methodol., 32(4), May 2023. ISSN 1049-331X. doi: 10.1145/3579639. URL https://doi.org/10.1145/3579639. [69] Ruby Documentation. module gem. https://ruby-doc.org/3.4/stdlibs/rubygems/ Gem.html. Accessed: 2026-02-06. [70] Pranet Sharma, Zhenpeng Shi, Sevval Simsek, David Starobinski, and David Sastre Medina. Understanding Similarities and Differences Between Software Composition Analysis Tools . IEEE Security & Privacy, 23(01):53–63, January 2025. ISSN 1558-4046. doi: 10.1109/MSEC.2024.3410957. URL https: //doi.ieeecomputersociety.org/10.1109/MSEC.2024.3410957. [71] Hequan Shi, Lingyun Ying, Libo Chen, Haixin Duan, Ming Liu, and Zhi Xue. Dr. docker: A large-scale security measurement of docker image ecosystem. In Proceedings of the ACM on Web Conference 2025, WWW ’25, page 2813–2823, New York, NY, USA, 2025. Association for Computing Machinery. ISBN 9798400712746. doi: 10.1145/3696410.3714653. URL https://doi.org/10.1145/3696410.3714653. [72] Rui Shu, Xiaohui Gu, and William Enck. A study of security vulnerabilities on docker hub. In Proceedings of the Seventh ACM on Conference on Data and Application Security and Privacy, CODASPY ’17, page 269–280, New York, NY, USA, 2017. Association for Computing Machinery. ISBN 9781450345231. doi: 10.1145/3029806.3029832. URL https://doi.org/10.1145/3029806.3029832. [73] Sonatype. 9th state of the software supply chain. https://www.sonatype.com/ state-of-the-software-supply-chain, 2023. [74] César Soto-Valero, Amine Benelallam, Nicolas Harrand, Olivier Barais, and Benoit Baudry. The emergence of software diversity in maven central. In 2019 IEEE/ACM 16th International Conference on Mining Software Repositories (MSR), pages 333– 343. IEEE, 2019. [75] César Soto-Valero, Nicolas Harrand, Martin Monperrus, and Benoit Baudry. A comprehensive study of bloated dependencies in the maven ecosystem. Empirical Software Engineering, 26(3):45, 2021. [76] 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. ISBN 9798400702174. doi: 10.1145/3597503.3623347. URL https://doi.org/10.1145/ 3597503.3623347. [77] The Apache Software Foundation. Maven central repository, 2025. URL https: //search.maven.org/. Accessed: 2025-09-12. [78] The Apache Software Foundation. Maven shade plugin – apache maven, 2025. URL https://maven.apache.org/plugins/maven-shade-plugin/. Accessed: 202509-12. [79] The Go Authors. Download and install (the go programming language). https:// go.dev/doc/install, 2026. States the installer installs Go to /usr/local/go. Accessed: 2026-02-06. [80] The White House. Executive order on improving the nation’s cybersecurity. The White House Briefing Room - Presidential Actions, May 2021. URL https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/ 12/executive-order-on-improving-the-nations-cybersecurity/. [81] The White House. Enhancing the security of the software supply chain through secure software development practices. The White House Briefing Room, Sep 2022. URL https://www.whitehouse.gov/wp-content/uploads/2022/09/M-2218.pdf. [82] The White House. Update to memorandum m-22-18, enhancing the security of the software supply chain through secure software development practices. The White House Briefing Room, Jun 2023. URL https://www.whitehouse.gov/wp-content/uploads/2023/06/M-23-16-Updateto-M-22-18-Enhancing-Software-Security.pdf. [83] Santiago Torres-Arias, Hammad Afzali, Trishank Karthik Kuppusamy, Reza Curtmola, and Justin Cappos. in-toto: Providing farm-to-table guarantees for bits and

Software Dark Matter: Gazing at Uncharted Files to Navigate SBOM Integrations

bytes. In 28th USENIX Security Symposium (USENIX Security 19), pages 1393–1410, Santa Clara, CA, August 2019. USENIX Association. ISBN 978-1-939133-06-9. URL https://www.usenix.org/conference/usenixsecurity19/presentation/torresarias. [84] Santiago Torres-Arias, Dan Geer, and John Speed Meyers. A Viewpoint on Knowing Software: Bill of Materials Quality When You See It . IEEE Security & Privacy, 21(06):50–54, November 2023. ISSN 1558-4046. doi: 10.1109/MSEC.2023. 3315887. URL https://doi.ieeecomputersociety.org/10.1109/MSEC.2023.3315887. [85] TrendMicro. Tlsh - trend micro locality sensitive hash. https://github.com/ trendmicro/tlsh, 2026. [86] Duc-Ly Vu, Fabio Massacci, Ivan Pashchenko, Henrik Plate, and Antonino Sabetta. Lastpymile: identifying the discrepancy between sources and packages. In Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, ESEC/FSE 2021, page 780–792, New York, NY, USA, 2021. Association for Computing Machinery. ISBN 9781450385626. doi: 10.1145/3468264.3468592. URL https://doi.org/10.1145/3468264.3468592. [87] 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 Trans. Softw. Eng. Methodol., January 2026. ISSN 1049-331X. doi: 10.1145/3788692. URL https://doi.org/10.1145/3788692. Just Accepted. [88] Jeff Williams, David Lindner, Brian Glas, Katharine Watson, Patrick Spencer, Mark Mullins, Pauline Logan, and Joe Coletta. 2021 State of Open-Source Security Report. Technical report, 2021. URL https://www.contrastsecurity.com/hubfs/ DocumentsPDF/2021-Contrast-Labs-Open-Source-Security-Report.pdf. [89] Laurie Williams, Giacomo Benedetti, Sivana Hamer, Ranindya Paramitha, Imranur Rahman, Mahzabin Tamanna, Greg Tystahl, Nusrat Zahan, Patrick Morrison, Yasemin Acar, Michel Cukier, Christian Kästner, Alexandros Kapravelos, Dominik Wermke, and William Enck. Research directions in software supply chain security. ACM Trans. Softw. Eng. Methodol., January 2025. ISSN 1049-331X. doi: 10.1145/3714464. URL https://doi.org/10.1145/3714464. Just Accepted.

Conference’17, July 2017, Washington, DC, USA

[90] Witness Project. Witness documentation (witness.dev). https://witness.dev. Project documentation describing Witness attestation and verification capabilities. Accessed: 2026-02-06. [91] 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 International Conference on Software Engineering, ICSE ’23, page 2630–2642. IEEE Press, 2023. ISBN 9781665457019. doi: 10.1109/ ICSE48619.2023.00219. URL https://doi.org/10.1109/ICSE48619.2023.00219. [92] Sheng Yu, Wei Song, Xunchao Hu, and Heng Yin. On the correctness of metadatabased sbom generation: A differential analysis approach. In 2024 54th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN), pages 29–36, 2024. doi: 10.1109/DSN58291.2024.00018. [93] Nusrat Zahan, Elizabeth Lin, Mahzabin Tamanna, William Enck, and Laurie Williams. Software bills of materials are required. are we there yet? IEEE Security & Privacy, 21(2):82–88, 2023. doi: 10.1109/MSEC.2023.3237100. [94] 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 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering, ESEC/FSE 2023, page 960–972, New York, NY, USA, 2023. Association for Computing Machinery. ISBN 9798400703270. doi: 10.1145/3611643.3616299. URL https://doi.org/10.1145/3611643.3616299. [95] Yunze Zhao, Yuchen Zhang, Dan Chacko, and Justin Cappos. Covsbom: Enhancing software bill of materials with integrated code coverage analysis. In 2024 IEEE 35th International Symposium on Software Reliability Engineering (ISSRE), Naples, Italy, 2024. IEEE. URL https://ssl.engineering.nyu.edu/papers/covsbom_ issre_2024.pdf. [96] Markus Zimmermann, Cristian-Alexandru Staicu, Cam Tenny, and Michael Pradel. Small world with high risks: A study of security threats in the npm ecosystem. In 28th USENIX Security Symposium (USENIX Security 19), pages 995–1010, Santa Clara, CA, August 2019. USENIX Association. ISBN 978-1-939133-06-9. URL https: //www.usenix.org/conference/usenixsecurity19/presentation/zimmerman.