Supply Chain Security: SBOMs, Software Attestation, and Trust in an Interdependent World

Modern software is assembled more than written. The average enterprise application pulls in hundreds of direct dependencies and thousands of transitive ones — open-source libraries, build toolchains, container base images, SDKs, cloud service client libraries. A Node.js application spawns node_modules directories with 50,000 individual files. A Java microservice carries a Maven dependency tree five levels deep. A Python data pipeline inherits packages most of the engineers on the team have never heard of. Each of those packages is a potential attack vector. Each upstream maintainer is a potential compromise point. The modern software supply chain is only as strong as its weakest link — and those links number in the thousands.

The SolarWinds attack redefined what supply chain compromise looks like at scale. Beginning in late 2019 and continuing through the first half of 2020, Russian Foreign Intelligence Service (SVR) operators — attributed as the Cozy Bear/APT29 group — gained persistent access to SolarWinds' internal build infrastructure. They injected a malicious backdoor, later called SUNBURST, into the Orion software platform's build process. SUNBURST was compiled alongside legitimate code and signed with SolarWinds' valid digital certificate. Over 18,000 SolarWinds customers installed the trojanized Orion update between March and June 2020, believing they were applying a routine patch. Among the victims: nine federal agencies including the Treasury Department, the Department of Homeland Security, and parts of the Pentagon, as well as dozens of Fortune 500 companies. The attack went undetected for nine months. FireEye discovered it in December 2020 while investigating a breach of their own tools. The fundamental security problem was not that SolarWinds built bad software — it was that the build system itself had been compromised, and no consumer of the software had visibility into how the software they were trusting had been assembled.

The strongest signal is not a single event. It is the pattern that keeps appearing across institutions.

Reporting Note

Log4Shell (CVE-2021-44228), disclosed in December 2021, exposed a different dimension of supply chain risk: the ubiquity of transitive dependencies. Log4j is a Java logging library maintained by the Apache Software Foundation. It has been embedded in Java applications for over two decades. The vulnerability — a Remote Code Execution flaw triggered by a single crafted string in a log message — existed in virtually every significant Java application: Minecraft, Apple iCloud, Amazon Web Services infrastructure, VMware vCenter, Cisco products, and countless enterprise applications whose developers had no idea Log4j was even present. The patch was straightforward; the identification problem was catastrophic. Organizations discovered they had no centralized inventory of which applications contained Log4j, which version, or in which of hundreds of microservices it appeared. Some were still hunting for Log4j instances six months after disclosure. CISA estimated that over 100 million devices worldwide were initially vulnerable.

XZ Utils (CVE-2024-3094), discovered in March 2024, revealed yet another attack vector: social engineering against open-source maintainers. XZ Utils is a compression library present in virtually every Linux distribution. Jia Tan — believed to be a sophisticated threat actor using a fabricated identity — spent approximately two years building credibility in the XZ Utils project. They submitted helpful patches, participated in community discussions, and gradually earned the trust of the primary maintainer Lasse Collin, who was dealing with personal burnout and mental health difficulties. Over this period, Jia Tan gained commit access and eventually introduced a backdoor in the build system — specifically in the configure scripts used to compile the library — that would have granted remote code execution capabilities to attackers targeting SSH servers on affected Linux systems. The attack was caught by Andres Freund, a Microsoft engineer, who noticed unusual CPU usage and latency in sshd and traced it to the modified XZ Utils. Had it reached stable releases in major distributions like Debian and Fedora, which it was just approaching, the blast radius would have been incalculable. The attack was sophisticated enough to only activate under specific conditions — on systemd-linked builds, on x86-64 systems — to avoid detection in testing environments.

Software Bill of Materials (SBOM) is the primary transparency mechanism that the industry is converging on in response to these events. An SBOM is a formal, structured inventory of all software components in a product: their names, versions, suppliers, licenses, and dependency relationships. When a vulnerability is disclosed in a library, an organization with a comprehensive SBOM can immediately query whether that library appears in any of their products, in which versions, and in which contexts. Without an SBOM, the same determination requires manual code archaeology — searching through dependency manifests, container layers, and build scripts — that may take days or weeks and remains incomplete. President Biden's Executive Order 14028, signed in May 2021 in direct response to the SolarWinds attack, mandated SBOMs for all software sold to the federal government. CISA has published minimum elements guidance that defines what an SBOM must contain to be useful.

Two dominant SBOM formats have emerged. SPDX (Software Package Data Exchange), originally developed by the Linux Foundation and now an ISO standard (ISO 5962:2021), focuses on license compliance alongside security. It represents dependencies in a graph format and supports multiple serialization formats including RDF, TV, and JSON. CycloneDX, developed by OWASP, is purpose-built for security use cases and has become particularly popular in DevSecOps workflows. It supports richer vulnerability and attestation metadata and has native integrations with many scanning tools. Most organizations that take SBOMs seriously are generating both formats — CycloneDX for security workflows and SPDX for license compliance and regulatory submission. Tools like Syft, Grype, Trivy, and Microsoft's SBOM Tool generate SBOMs from container images, source code, and binaries. The challenge is not generation but consumption: having an SBOM is only valuable if you have systems to ingest it, correlate it against vulnerability databases, and surface actionable results.

Software Supply Chain Levels for Software Artifacts (SLSA, pronounced 'salsa') is a Google-originated framework that addresses the SolarWinds attack vector directly — not the software contents, but the integrity of the build process itself. SLSA defines four levels of increasing assurance. Level 1 requires that the build process is scripted and provenance is generated — a record of what inputs produced which output. Level 2 requires that the build service is hosted and the provenance is signed. Level 3 requires that the build environment is hardened so it cannot be tampered with during a build — no persistent state, no network access to arbitrary destinations. Level 4 (the highest, rarely achieved) requires two-party review of all code changes and hermetically sealed builds with fully declared dependencies pinned to cryptographic hashes. Many large open-source projects are now working toward SLSA Level 2 or 3. The provenance attestations generated by SLSA-compliant build systems allow consumers to cryptographically verify that a software artifact was built from a specific source commit by a specific build process — exactly the transparency that would have caught the SolarWinds SUNBURST injection.

Sigstore is the open-source infrastructure that makes cryptographic artifact signing practical. Developed by Google, Red Hat, and Purdue University and now hosted under the OpenSSF, Sigstore provides a keyless signing approach that removes the key management burden that previously made signing impractical. When a developer signs an artifact with Sigstore's Cosign tool, the signature is linked to their identity via an OIDC token (from GitHub, Google, Microsoft, etc.) and logged to Rekor — a public, tamper-evident transparency log. Anyone can verify that a signed artifact corresponds to a specific identity and was signed at a specific time. The npm, PyPI, and Maven Central ecosystems are actively integrating Sigstore. The Sigstore project announced in October 2022 that all Python packages released by major projects like CPython itself would be signed using Sigstore. This provides downstream consumers with verifiable proof of origin that goes beyond simple checksums.

Dependency confusion and typosquatting attacks exploit the mechanics of how package managers resolve dependencies. In February 2021, security researcher Alex Birsan demonstrated dependency confusion by registering public packages under names that matched private internal packages used by Apple, Microsoft, PayPal, Tesla, and Shopify. When the companies' build systems checked both internal and public registries, the public package — at a higher version number — was installed instead of the intended internal one. All affected companies paid Birsan bug bounties; the technique had already been used maliciously. Typosquatting registers packages with names similar to popular ones — 'requests' vs 'request', 'lodash' vs 'loadash' — and hopes developers make typing errors. In 2023, researchers found over 186,000 suspected typosquatting packages on PyPI. Both attack types are countered by strict namespace conventions for private packages, private registry isolation with the public registry as a fallback only for explicitly approved packages, and automated scanning for suspicious newly-published packages that match internal naming patterns.

Build pipeline hardening goes beyond SLSA to encompass the entire set of trust assumptions in a CI/CD workflow. GitHub Actions, which has become the dominant CI platform, has a permission model that, if misconfigured, allows pull requests from forks to execute workflows with access to secrets. The 'pull_request_target' trigger, specifically, executes in the context of the base repository with write permissions — a vector that has been exploited in attacks against dozens of open-source projects. Hardening requires scoping workflow permissions to minimum necessary, pinning third-party Actions to exact commit SHAs rather than mutable tags, reviewing Actions from external authors before use, and separating workflows that require secrets from those that process untrusted code.

Third-party risk management extends supply chain thinking beyond software to the entire ecosystem of vendors, cloud providers, and technology partners. SaaS applications have direct access to corporate data. Cloud providers run infrastructure that business processes depend on. Managed service providers have administrative access to customer environments. Each relationship introduces risk through the vendor's own security practices, their subprocessors, and the operational dependencies your organization has on their availability. Mature third-party risk programs tier vendors by criticality — a payroll processor or cloud infrastructure provider is Tier 1; a travel booking tool is Tier 3 — and apply proportional assessment rigor. Tier 1 vendors receive in-depth questionnaire review, security documentation review (SOC 2 Type II reports, penetration test summaries, security control certifications), and contractual requirements including breach notification timelines, security incident sharing, and right-to-audit clauses.

Open Source Security Foundation (OpenSSF) Scorecard provides automated security assessment for open-source projects that organizations can use to evaluate the security hygiene of their dependencies before adopting them. Scorecard runs automated checks across 20 categories including: Branch Protection (are main branches protected against force-pushes?), Code Review (is every commit reviewed by a human?), Dependency Update Tool (is a tool like Dependabot or Renovate updating dependencies automatically?), Maintained (has the project been actively maintained in the last 90 days?), SAST (do automated static analysis tools run on every commit?), and Signed Releases (are release artifacts cryptographically signed?). Projects receive a score from 0-10. Google publishes Scorecard results for over one million open-source projects. Organizations can incorporate Scorecard thresholds into their dependency adoption policies: new dependencies below a score of 7 require security review; dependencies below 5 require waiver approval.

Vulnerability management for the software supply chain requires integration between SBOMs, vulnerability databases, and remediation workflows. The National Vulnerability Database (NVD) and CVE program provide the foundational vulnerability catalog. Package-specific databases like GitHub Advisory Database, OSV (Open Source Vulnerabilities), and vendor-specific databases provide faster, more accurate matching to package names and versions than NVD alone. Tools like Grype, Trivy, and Snyk correlate SBOM component lists against these databases and output prioritized vulnerability lists. The prioritization challenge is real: a large application might have hundreds of vulnerabilities in its dependency tree, but most are unexploitable in context. EPSS (Exploit Prediction Scoring System) scores predict the probability that a vulnerability will be exploited in the wild within the next 30 days — providing a more accurate prioritization signal than CVSS severity alone. Reachability analysis tools like Snyk's and Google's OSV-Scanner attempt to determine whether a vulnerable code path is actually called by the application, further filtering noise.

The regulatory landscape for software supply chain security is hardening. The US Cyber Trust Mark for IoT devices requires SBOM disclosure as a condition of certification. The EU Cyber Resilience Act, finalized in 2024, requires SBOM generation for products placed on the EU market with 'digital elements' — encompassing most software and connected devices. FDA guidance for medical device cybersecurity requires SBOMs as part of premarket submissions. NIST SP 800-218 (Secure Software Development Framework) provides guidance for software producers. Together, these requirements are creating pressure that is accelerating SBOM adoption beyond early adopters into mainstream software development practice.

The practical implementation path for organizations new to supply chain security involves several sequential steps. First, gain visibility: implement SBOM generation for all internally developed software and request SBOMs from critical software vendors. Second, integrate vulnerability correlation: connect SBOMs to vulnerability scanning in the CI/CD pipeline so every build produces a current vulnerability picture. Third, establish policy: define what constitutes an acceptable vulnerability profile for a deployment, automate pipeline gates that enforce it, and create exception workflows for cases where remediation requires time. Fourth, harden build infrastructure: implement branch protection, pin third-party CI actions, restrict secret access, and begin working toward SLSA Level 2 for critical software. Fifth, extend to vendors: incorporate SBOM requests and security attestation requirements into vendor contracts and evaluate vendor SLSA maturity as part of procurement. None of these steps are simple. All of them are necessary.

The supply chain threat is not a problem that gets solved and stays solved. It evolves continuously. New attack patterns emerge: malicious code injected into legitimate projects through compromised maintainer accounts, malware hidden in test dependencies that get executed in CI environments but not production, timing attacks that insert malicious code briefly to hit a specific organization's build window. Staying ahead requires continuous monitoring — of dependency behavior, of package registry activity for suspicious new releases of libraries you depend on, of threat intelligence about campaigns targeting development toolchains. Organizations that navigate this landscape successfully treat supply chain security as a first-class engineering discipline, not a compliance checkbox. They fund dedicated supply chain security roles, integrate security tooling at every stage of the development lifecycle, and maintain vendor risk programs proportional to the criticality of those relationships. The supply chain will never be perfectly secure — but it can be managed with the same rigor applied to every other security domain.