Software supply chains explained

A software supply chain covers everything used to create, build, and deliver software: the code developers write, the components and libraries it uses, the tools and services that produce a release, and the channels that deliver it to users. The TODO Group glossary defines it as the components, libraries, tools, and processes involved in developing, building, and publishing software. The chain ends with software a customer installs or a service a provider operates online.

A dependency is software that another piece of software relies on. A program might use a library to read image files, and that library might rely on other libraries. Those indirect dependencies form a dependency tree. The supply chain also includes the developer tools and services used around that code, such as code editors, test tools, build tools, source-code hosting services, and package repositories.

A product can combine open-source components, commercial software, in-house code, and hosted development or build services. Distribution channels belong to the chain as well. Package registries, download sites, app stores, and update services deliver releases to users. These categories identify how a component or service is supplied; none determines whether it is secure.

People and organizations are also part of the supply chain because they hold access at points where software can change or be released. Developers and maintainers can modify code, and build operators can alter build settings or the environment that creates a release. Release owners can publish updates through a registry or another distribution channel. Access to signing keys also matters because the key holder can create a signature that identifies a release as coming from that publisher. A signing key is a credential used to verify that a release came from a particular publisher. Anyone who can access code, build systems, signing keys, or release channels has a role in the software supply chain.

How software reaches users

A software release starts with source code – the human-readable instructions developers write – and dependencies, the external libraries and tools that code needs. A build turns those inputs into software a computer can run, such as an executable file, mobile app package, or container image.

Developers test the built software to find defects and confirm expected behavior. They then package it for delivery. The resulting release artifact is the specific file or image sent to users or deployed to servers. It may include compiled code and bundled dependencies, so it can look very different from the source files a reviewer inspected.

A publisher may digitally sign the artifact. The signature allows an installer, device, or deployment service to verify that the artifact came from the expected publisher and has not changed since signing. The publisher then uploads it to a package registry, download site, or container registry. A person installs it on a device, or an operator deploys it to servers that provide an online service.

Automated build and deployment pipelines connect these steps. A pipeline follows defined instructions to test code, create an artifact, sign it, publish it, and deploy it. GitHub Actions, for example, runs configured jobs and steps to automate software workflows. Access to the pipeline matters because a person who changes its instructions or uses its credentials can influence what the build produces and delivers. SLSA, short for Supply-chain Levels for Software Artifacts, provides a framework for describing build integrity and recording evidence of how an artifact was produced.

Where software supply chain attacks enter

A software supply chain attack enters wherever code, dependencies, build instructions, or updates pass from one party to another. An attacker who takes over a maintainer account can alter source code or publish a malicious release. A malicious package – or a package name designed to resemble a trusted one – can enter through a package registry. Altered build instructions can change the finished package even when the reviewed source code looks clean. A compromised registry or update service can then distribute a modified release to users.

One dependency risk is dependency confusion. A build expects an internal package but, because its registry or namespace settings are wrong, downloads a public package with the same name instead. An attacker who controls that public package can place code in the build, as OWASP describes.

What happened with xz Utils

In 2024, researchers discovered malicious code in xz Utils versions 5.6.0 and 5.6.1, tracked as CVE-2024-3094. The release tarballs, which are source archives prepared for distribution, included build scripts that activated code hidden in test files. Those files were absent from the Git repository that many reviewers inspected.

The affected versions appeared in development and testing branches of some Linux distributions. Maintainers detected the issue before the malicious versions reached most stable releases. Debian’s stable release was unaffected; Debian’s security advisory documents its response.

The xz incident shows why reviewing repository source code alone leaves gaps: source review examines the repository, while dependency checks examine imported packages. Build controls protect the steps that produce a release, and testing the final package examines what users actually receive; each control covers a different entry point in the supply chain.

What an SBOM can show

A software bill of materials (SBOM) is a formal record of the software components in a product and the relationships among them. The 2021 NTIA notice compares it to an ingredients list: it identifies what the software contains.

When a vulnerability is disclosed, a maintainer or buyer can compare the affected component with an SBOM. The NTIA notice proposed fields such as the component’s supplier, name, version, cryptographic hash, unique identifier, and dependency relationships. Names, versions, and identifiers help match a disclosed vulnerability to a component. A cryptographic hash identifies a specific file or package artifact. Dependency relationships show which components rely on others.

SBOM formats and changing guidance

SPDX and CycloneDX are formats for representing SBOM data. Software Identification (SWID) tags provide standardized software identification data and also appear in SBOM practice; the NTIA notice names all three.

The 2021 NTIA baseline fields were proposals submitted for public comment, not a permanent universal checklist. CISA later requested comment on updated minimum-elements guidance. Joint 2026 minimum-elements guidance is reported to replace the 2021 baseline. Before making a compliance claim, verify the current primary guidance and the requirements that apply to the product, customer, or procurement.

What the inventory cannot establish

An SBOM’s dependency information may be incomplete. The 2021 NTIA notice states that an SBOM that cannot track the full dependency graph should identify the remaining “known unknowns.” An omitted component does not prove that no additional dependency exists.

A listed component also does not prove that a product is safe or vulnerable. Vulnerability status depends on the affected version, whether the vulnerable code is present, and how the product uses the component. An SBOM identifies what requires investigation; it does not determine the result.

How to reduce software supply chain risk

Software supply chain risk rises when an organization lacks visibility into how software was developed, assembled, and delivered. NIST SP 800-161 Rev. 1, published in May 2022, frames supply chain risk as a management problem across development, integration, and deployment. Software makers need to protect their development and release paths. Buyers need to assess the products and services they acquire.

Control dependencies and access

Software makers should record selected dependency versions in lock files or equivalent records and verify package sources. They should also use private registries and namespaces for internal packages. These measures make builds repeatable and reduce dependency-substitution risk, in which a build retrieves a public package that shares the name of an internal package.

They should also restrict who can change source code, build instructions, release settings, and signing keys. Signing keys prove that a release came from the expected publisher, so they require storage and access controls equal to other production credentials. Build environments need similar protection. Reviewing the final package or executable, rather than only the source repository, helps detect changes introduced during building or packaging. The NIST Secure Software Development Framework outlines practices for protecting software development and release activities.

Record how releases were built

Build provenance is evidence of where and how a release was produced. It links a release artifact – the package or executable delivered to users – to its source and build steps. That evidence helps buyers assess whether a package matches the publisher’s stated build process.

SLSA provides a framework for describing build integrity and provenance. A SLSA level or provenance record supports verification and investigation. It does not establish that the source code is safe or that every build step was protected.

Prepare for vulnerable components

When a vulnerability is disclosed, software makers need component inventories, such as software bills of materials (SBOMs), and vulnerability records to identify affected releases, assess exposure, and prioritize updates. They should tell customers which releases are affected, what remediation is available, and what remains unknown.

Buyers should ask suppliers how they track components and protect builds and updates, and how they report vulnerabilities. Buyers also need a response plan that identifies where a product is used and determines exposure. While a fix is pending, they should update the product or limit its use.

One control cannot cover every failure

Documentation does not prevent a compromised dependency or build environment. It supports response by helping organizations locate affected products and releases. Access limits, protected build environments, and release reviews reduce opportunities to introduce or distribute unauthorized changes.

Match each safeguard to a specific failure point, and retain enough component and build information to investigate and respond.

What SBOMs and build records cannot prove

An SBOM, or software bill of materials, lists software components and their relationships. It does not prove that code is benign, that a build was free from tampering, or that the inventory is complete. Its value depends on what it captures and whether it matches the release users receive. NTIA’s 2021 proposal recognizes that dependency records can contain “known unknowns” when they cannot trace every link.

A missing dependency entry has two possible meanings: the component has no further dependencies, or the inventory failed to identify them. The gap may involve code copied into the source tree, separately downloaded files, code generated during the build, or dependencies introduced by build instructions. An SBOM helps investigate exposure, but readers also need to know how its creator generated it and which release it represents.

A source review has limits

The 2024 xz Utils incident showed why a clean source repository does not prove that a distributed release is clean. Versions 5.6.0 and 5.6.1 contained a malicious build-time modification in release tarballs that did not appear in the Git repository. Build logic extracted the payload from files presented as test data. The initial disclosure records the discovery. Reviewing source code and inspecting a packaged artifact answer different questions.

Build records and signatures add evidence within defined limits. A signature shows that an artifact has not changed since the signing-key holder signed it. Build provenance records the claimed inputs, environment, and steps used to create an artifact. Neither proves that the source was safe or that every build step and credential was trustworthy.

Match controls to the risk

Security checks require time and money. Organizations should prioritize them according to the software’s role, its access to sensitive systems or data, and the harm a compromise would cause. NIST’s supply-chain risk guidance treats limited visibility into how acquired technology is developed and deployed as a risk-management concern. Component inventories, access controls, artifact inspection, and vulnerability response each address different gaps.

Do not treat headline estimates of third-party code as an industry-wide fact. Vendors have published figures such as 70–90% and 80%, based on different software populations and measurement methods (Infinum, Cloudsmith). They do not establish a settled industry-wide percentage.

Protect the full release path

A software release includes more than the code written for the product. It relies on third-party components, developer tools, build services, people with access to development and build environments, and the channels that deliver the finished software. Each stage creates a different opportunity for error or compromise. Reviewing source code alone leaves gaps.

Protect the development and release path from source through distribution. Track where code and components came from, limit access to development and build environments, record how each release was built, and verify the software delivered to users. Component inventories and build records help investigators determine which releases contain an affected component after a vulnerability report.

Those records do not prove that the inventory is complete or that a build is trustworthy. NIST’s supply-chain guidance notes that limited visibility into how technology is developed and delivered makes risk harder to manage. Organizations still need to verify releases, manage access, and communicate clearly while addressing vulnerabilities.

Questions readers ask

Is open-source software unsafe?

No. An open-source license lets people inspect, use, and modify code. The license does not determine whether a component is secure. Risk depends on the code itself and whether maintainers fix defects. It also depends on how the product uses the component and how developers protect the build and release process.

Does an SBOM prevent attacks?

No. A software bill of materials (SBOM) lists the components in a product and, where available, their relationships. It helps suppliers and buyers determine whether a product includes a component affected by a reported vulnerability. The NTIA definition describes an SBOM as inventory information, not a security control. An SBOM does not stop malicious code changes, protect a build environment, or guarantee a complete inventory.

What should a buyer ask for?

Ask how the supplier identifies and verifies software components, protects development and build environments, secures releases and updates, and reports vulnerabilities. Ask how the supplier determines which products are affected and how it provides fixes or mitigations. NSA and CISA secure software development guidance addresses these areas. Contract terms and legal obligations depend on the product, supplier, and purchase agreement.

Key Takeaways

• Track the whole chain: Account for dependencies, developer tools, and build services across the whole chain. Include people with release access and distribution channels, as well as the code your developers write.
• Protect each release stage: Pin dependency versions, verify package sources, restrict access to build systems and signing keys, and inspect the final package before publication.
• Match safeguards to risks: Source review, dependency checks, build records, signatures, and artifact testing address different failure points; no single check verifies the entire release.
• Use SBOMs to investigate exposure: A software bill of materials helps identify products that include a vulnerable component, but it can be incomplete and does not prove that software is safe.
• Prepare to respond: Ask suppliers how they secure releases and report vulnerabilities, then plan how to identify affected products, apply fixes, and communicate what remains unknown.

FAQ

Is open-source software unsafe?

Open-source licensing does not determine whether software is secure. Risk depends on the code, how it is maintained and released, how it is used, and the safeguards around it.

Does an SBOM prevent software supply chain attacks?

No. A software bill of materials (SBOM) lists components and their relationships, which helps identify products affected by a vulnerability. It does not prevent malicious changes, prove that the build was protected from tampering, or guarantee that the inventory is complete.

How do I assess a software supplier’s supply chain security?

Ask how the supplier tracks software components, protects build and release access, secures updates, and reports vulnerabilities. Also ask how it will help you determine whether a disclosed vulnerability affects the software you use.

How can I reduce the risk of a dependency being substituted?

Pin dependency versions in a lock file or equivalent record and verify package sources. Configure private registries and package namespaces carefully. These steps help prevent a build from fetching a public package with the same name as an internal one.

What if an SBOM does not list every dependency?

Treat missing dependency information as an unknown, not as proof that no further dependencies exist. Ask the supplier what the inventory covers and whether it identifies dependencies it could not determine.

Can source-code review catch every supply chain attack?

No. The xz Utils backdoor affected versions 5.6.0 and 5.6.1, and build scripts in release tarballs activated code hidden in test files that did not appear in the Git repository. Reviewing source code helps, but checking the build process and final release artifact addresses different risks.