Software Supply Chain Attacks: Risks and Defenses

Software supply chain attacks target the people, services, and components used to create and deliver software, not only bugs in the finished application. Developers, platform engineers, and security teams need to understand how trust moves from a dependency or source repository into a production release. This guide explains common attack paths, what evidence different security controls provide, and how to make dependency and build workflows harder to abuse.

What Are Software Supply Chain Attacks?

A software supply chain attack is an attempt to compromise software by exploiting a trusted part of its production or distribution process. That part might be an open-source library, a developer’s account, a source-code repository, a build runner, a package registry, or a vendor’s update service. If an attacker can influence one of those components, they may be able to reach many downstream applications through a routine update.

The defining feature is the route through trust. An organization may carefully review its own source code yet still install a compromised dependency or deploy an artifact produced by a hijacked build system. The software appears to arrive through an expected channel, so the malicious change can blend in with normal development and updates.

Supply chain security includes more than vulnerability scanning. A scanner can identify a known flaw in a package version, but it may not detect a newly published malicious package, a stolen maintainer account, or a build that was altered after source review. The NIST Secure Software Development Framework (SSDF) treats secure development as a set of practices across the software lifecycle, including protecting development environments and checking software before release.

The Problem Software Supply Chain Attacks Solve for Attackers

Compromising one target directly can be expensive. A successful upstream compromise can turn a supplier’s access or a popular component’s routine release into a distribution channel. The attacker may gain reach without separately breaking into each downstream organization.

Modern applications are assembled from many layers: direct and transitive libraries, build tools, container images, plugins, hosted services, and deployment automation. Each layer can be maintained by a different team and updated on a different schedule. Organizations often lack a complete inventory of what is included in a release, who can change it, and which build produced it. That makes it difficult to spot an unexpected component or quickly identify affected systems after a disclosure.

The same complexity creates operational trade-offs. Automatically accepting every update can admit a compromised release; rejecting all updates can leave known vulnerabilities unpatched. The goal is not to eliminate dependencies or assume every supplier is unsafe. It is to establish clear ownership, visibility, review, and recovery for the software and services that matter to a product.

How Software Supply Chain Attacks Work

A simplified delivery path looks like this:

1. A developer or automation account retrieves source code and dependencies.
2. A build system compiles, packages, or containerizes them.
3. The resulting artifact is published to a registry or release service.
4. A deployment process retrieves the artifact and runs it.

Each transition carries trust and credentials. Attackers may enter through a compromised maintainer account, a weakly protected source repository, an exposed build token, or a vulnerable service used by the pipeline. They may then change source, alter a dependency, inject code during a build, or replace a published artifact. The farther the attack gets before detection, the more consumers may receive the affected output.

Common paths include:

• Malicious or impersonating dependencies: An attacker publishes a package with a deceptive name, takes over a legitimate package account, or compromises a maintainer’s release process. Dependency confusion can also occur when a resolver selects an unintended public package instead of an internal package.
• Compromised source and developer accounts: Stolen credentials or abused permissions allow unreviewed changes to repositories, release branches, or package metadata.
• Build-system compromise: A malicious workflow, compromised runner, or overly powerful build credential can change output even when the reviewed source appears clean.
• Artifact and update tampering: An attacker modifies a package, image, installer, or update channel after its source or build has been trusted.
• Supplier compromise: A software vendor or hosted service is used as a route into customers that depend on its product or update mechanism.

These paths differ, but the core question is similar: can a consumer verify what an artifact contains, where it came from, and how it was produced? The SLSA specification describes progressive build integrity and provenance practices that help answer the origin and production questions. Provenance is evidence about a build; it does not prove that the source itself is safe.

Components and Security Controls

Effective defenses connect controls to specific risks rather than treating a single scanner as a complete solution.

An SBOM records software components and their relationships in a machine-readable format. It helps answer questions such as “Which released products include this library?” SPDX is one established SBOM format; the SPDX project documents its specifications and tooling. An SBOM is an inventory, not a safety certificate: it can help locate affected software but does not establish that listed components are benign, current, or correctly reported.

Signatures and attestations provide different evidence. A signature can help verify that an artifact has not changed since it was signed and, depending on the signing method, identify the signer. Build provenance can connect an artifact to a source revision and build process. Neither control guarantees that the code has no vulnerability or that a legitimate signer was not compromised. Review, access controls, scanning, and recovery remain necessary.

Real-World Uses and Attack Scenarios

Consider a team that pulls a transitive package during a routine build. The direct dependency is familiar, but one of its sub-dependencies has been taken over. A lockfile can make the selected package version visible and keep installations reproducible, while dependency review and trusted update procedures help catch unexpected changes. They do not automatically establish that the locked version is safe.

In another scenario, an attacker steals a CI credential that can publish releases. The source repository may show no suspicious change, but the attacker can push an altered artifact. Restricting publishing credentials, separating build and release permissions, and verifying signed artifacts make this route harder and improve investigation evidence.

A third scenario involves a vendor update. A customer may have no control over the vendor’s build process, but can inventory deployed versions, limit the privileges of the integration, monitor vendor advisories, and prepare a rollback or isolation plan. These steps reduce impact without assuming the customer can inspect or rebuild the supplier’s source.

The same principles apply to open-source libraries, containers, plugins, desktop installers, and firmware. The precise controls vary: a package manager lockfile helps with application dependencies, while signed updates and verified firmware measurements may be more relevant to device software.

Getting Started: Practical Supply Chain Checks

Start by making the dependency resolution repeatable and reviewing known vulnerability findings. In an npm project with a committed package-lock.json, a basic local check is:

# Install the exact dependency tree recorded in package-lock.json
npm ci

# Check production dependencies against npm's known advisory data
npm audit --omit=dev

# Save the resolved dependency tree for review
npm ls --all --json > dependency-tree.json

These commands answer limited questions. npm ci follows the lockfile but does not verify that every package is trustworthy. npm audit reports known advisories in its data; it is not a detector for every malicious package or compromised release. Review unexpected dependency changes, package ownership and source, install scripts, and the advisories’ applicability before making a risk decision.

For a component inventory, Syft can generate an SPDX-format SBOM from a project directory:

syft dir:. -o spdx-json=sbom.spdx.json

This requires Syft to be installed and run in the project environment. Store the SBOM with the release it describes, and avoid treating a development checkout’s inventory as proof of the contents of a separately built artifact. If an advisory appears, use the relevant released artifact’s inventory to find affected products, then confirm findings against the actual deployment and package provenance.

For a durable workflow, apply these controls in stages:

1. Know what you use. Commit lockfiles, track direct and transitive dependencies, and maintain an SBOM for releasable products where feasible.
2. Reduce who can change and publish software. Require multi-factor authentication, use branch protections, scope tokens to a job and purpose, and keep publishing credentials out of untrusted pull-request jobs.
3. Make builds harder to tamper with. Use isolated, short-lived runners; limit network and secret access; pin critical build inputs; and retain logs and provenance.
4. Verify releases. Publish immutable artifacts, sign them, and configure consumers or deployment systems to check the expected identity and provenance.
5. Plan for compromise. Know how to revoke credentials, pause releases, identify affected versions, rebuild from reviewed source, and notify users.

The NIST SSDF is a useful framework for integrating these practices into development rather than adding them only at release time. For pipeline-specific implementation, see our DevOps pipeline security guide.

Common Misconceptions

“A dependency scanner makes the supply chain safe.” Scanners are useful for matching components against known vulnerability data. They may not identify fresh malicious code, account takeovers, build tampering, or every vulnerable configuration. Use them as one detection layer.

“An SBOM proves that software is secure.” An SBOM describes components and can accelerate exposure analysis. It does not certify code quality, prove the inventory is complete, or confirm that a release was built as intended.

“Signing an artifact proves it is harmless.” A valid signature supports integrity and signer verification. If the signer or build pipeline is compromised, a harmful artifact can still be signed. Verify the identity and provenance you expect, and protect the process that produces them.

Related Articles

• Package Management Best Practices
• DevSecOps Integration Strategies
• DevOps Pipeline Security
• Container Security Best Practices

Changelog

• First published.