Software Supply Chain Security: SBOMs and SLSA

The 2020 SolarWinds compromise sent a shockwave through the security industry: attackers inserted malicious code into a legitimate, digitally-signed software update distributed to 18,000 organisations including US federal agencies. The victims didn’t download malware from a suspicious source — they installed a trusted update from a vendor they had relied on for years. That’s the defining characteristic of supply chain attacks. If you want the full context, see our Complete Guide to Online Security and Privacy.

When the software itself — the update, the open-source package, the build tool — is the attack vector, traditional defences of network perimeters, email filtering, and user awareness training offer little protection. Software supply chain security is relevant at multiple levels: for organisations that consume software (which is everyone), for developers who build software using open-source dependencies, and for software vendors who distribute products to customers.

Understanding the attack surface

The software supply chain encompasses every component contributing to software reaching an end user: source code repositories, open-source packages and libraries, build systems, code signing infrastructure, distribution channels (package registries, update servers, app stores), and update mechanisms. A compromised link anywhere propagates the compromise to every downstream consumer.

The primary attack categories:

• Dependency confusion: publishing a malicious package to a public registry with the same name as a private package, exploiting the package resolver’s preference for public registries over private ones
• Typosquatting: registering malicious packages with names similar to popular legitimate ones — “reqeusts” instead of “requests”
• Malicious maintainer compromise: gaining control of a legitimate package through social engineering, credential theft, or purchasing an abandoned package
• Build system compromise: injecting malicious code during the compilation process rather than in the source
• Update channel compromise: the SolarWinds pattern — distributing malicious signed updates through legitimate update infrastructure

For organisations that consume rather than build software, the practical priorities are: downloading software only from official sources, verifying cryptographic signatures where available, keeping software updated through official channels, monitoring security advisories for supply chain compromise indicators, and maintaining least privilege so that compromised software operates with minimum access rather than administrator-level privilege.

Open-source dependency risks — the developer’s challenge

For developers building on open-source dependencies — almost every software project — active dependency graph management is the core practice. Modern applications can have hundreds or thousands of transitive dependencies (packages that direct dependencies depend on), each representing a potential risk if compromised.

Essential dependency-layer controls:

• Software Composition Analysis (SCA): tools that scan the dependency graph for known vulnerabilities — Snyk, Dependabot (GitHub-native), OWASP Dependency-Check. Command-line options: npm audit, pip-audit, mvn dependency:check.
• Lock files: pin exact dependency versions and cryptographic hashes to prevent unexpected updates from pulling in modified versions. package-lock.json (npm), Pipfile.lock (pip), Gemfile.lock (Ruby) — commit these to version control and verify them in CI.
• Private package mirrors: serve vetted versions of public packages rather than pulling directly from public registries — prevents dependency confusion attacks and provides a review checkpoint for new additions.
• Dependency review process: before adding any new dependency, evaluate: the package’s maintainer trust, download volume, last commit date, number of maintainers, and security advisory history. One-person projects with sporadic maintenance represent higher risk than actively-maintained packages with multiple contributors.

The xz Utils backdoor discovered in March 2024 illustrates the social engineering dimension: a sophisticated actor spent two years building trust as a legitimate contributor to the xz Utils project before inserting a backdoor in version 5.6.0 that would have provided remote access to any Linux system running the backdoored library. The attack was discovered by a developer who noticed unexplained SSH latency — a near-miss that revealed how far a patient, technically sophisticated attacker can penetrate a widely-used open-source project before detection.

Vendor and enterprise controls — the framework

The SBOM row has become particularly relevant following the US Executive Order on Improving the Nation’s Cybersecurity (May 2021), which requires federal agencies to obtain SBOMs from software vendors. An SBOM — a machine-readable inventory of every component in a piece of software — enables immediate identification of whether any version of a compromised component is in use when a supply chain compromise is disclosed. Without SBOMs, the Log4Shell response in late 2021 required weeks of manual dependency searching for large organisations. With accurate SBOMs, the same determination takes hours.

The developer’s supply chain security checklist

• ☐ SCA tool integrated into CI pipeline — scans run on every pull request
• ☐ Lock files committed to version control and verified in CI
• ☐ Dependency review process documented and enforced for new additions
• ☐ Private package registry configured for at least npm/PyPI/Maven dependencies
• ☐ Code signing configured for published artifacts
• ☐ SBOM generated as part of the build process
• ☐ Build pipeline secrets (API keys, signing keys) stored in secrets manager, not environment variables
• ☐ MFA and hardware security keys required for all accounts with repository or pipeline access
• ☐ Signed commits enforced for main branch (git commit signing with GPG or SSH key)
• ☐ Branch protection rules on main: require PR review, require status checks to pass, restrict force push

The social engineering dimension — what technical controls can’t prevent

Several high-profile supply chain compromises have involved sophisticated social engineering of project maintainers rather than technical exploitation. The xz Utils case involved a sophisticated actor spending two years building trust as a legitimate contributor before inserting the backdoor. This pattern — patient, sophisticated social engineering rather than technical exploitation — is a category of attack that code scanning and dependency pinning cannot prevent.

Protecting against this in open-source projects requires community practices: multiple maintainer review for significant changes, build reproducibility to allow independent verification, transparent change logs, and treating unusual urgency or pressure to merge changes as a red flag. For organisations with internal development teams, the same principles apply to CI/CD pipeline management — pipeline administrators with broad access to build systems and deployment keys should have hardware security key authentication and privileged access management applied with the same rigor as other high-privilege accounts.

Our guide on the zero trust security model covers the least privilege access principles that software supply chain security implements at the pipeline and build system level. For CISA’s software supply chain security guidance including SBOM practices and vendor security questionnaire templates, CISA’s software supply chain security resources provide authoritative guidance aligned with the US Executive Order requirements that are increasingly becoming commercial standards.

Regulatory drivers — what organisations are now required to address

Supply chain security has moved from a voluntary best practice to a regulatory requirement in several jurisdictions:

• US Executive Order 14028 (May 2021): requires federal agencies to only procure software that provides an SBOM and meets NIST Secure Software Development Framework (SSDF) requirements. Because federal procurement drives commercial practice, SSDF requirements are increasingly appearing in commercial contracts as well.
• EU Cyber Resilience Act: introduces mandatory cybersecurity requirements for products with digital elements sold in the EU, including supply chain security requirements for CE-marked products. Software vendors selling into the EU market will need SBOM generation, vulnerability disclosure processes, and documented security testing as part of product compliance.
• NIST Secure Software Development Framework (SSDF, SP 800-218): a set of practices for secure software development that addresses supply chain security throughout the development lifecycle — widely referenced in US government contracts and increasingly in commercial procurement questionnaires.

For organisations building commercial software products, understanding these requirements and implementing the underlying practices not only achieves compliance but also produces the stronger security posture the regulations are designed to require. You might also run into Network Security Basics.

Consuming vendor software securely — if you’re not a developer

Most organisations are primarily software consumers rather than builders. For these organisations, the supply chain security practise is about vendor management rather than code practices:

• Request SBOMs from critical software vendors. For software that is critical to operations or handles sensitive data, asking for an SBOM is now standard practice. If a vendor cannot produce an SBOM, that’s a signal about their security maturity worth factoring into procurement decisions.
• Apply updates through official channels only. Never install software updates from sources other than the official vendor website, official app stores, or the software’s own built-in update mechanism. Third-party “update packages” are a common malware delivery vector that mimics update channel compromise.
• Monitor vendor security advisories. Subscribe to security mailing lists or RSS feeds for critical software vendors. Supply chain compromises are disclosed through these channels; acting quickly on disclosure reduces exposure time.
• Apply least privilege to installed software. Applications that run with administrator or root privileges have much broader potential impact if they are compromised in a supply chain attack. Review which applications run with elevated privileges and restrict where possible.
• Verify cryptographic signatures before deployment. For software distributed with signatures (most major open-source projects, many commercial packages): verify the signature against the published key before installation. This step catches distribution-level modifications even when the build itself was legitimate.

Software supply chain security is ultimately about trust — trust that the software you’re running is what its publishers intended, and that the publishers themselves haven’t been compromised. The controls in this guide address both the technical mechanisms that verify that trust and the processes that reduce the likelihood of that trust being misplaced. The most important insight from SolarWinds, xz Utils, Log4Shell, and similar incidents is that supply chain trust, once violated, affects every downstream consumer simultaneously — making prevention worth significantly more than remediation at scale. Related: Cloud Security Best Practices.