Software supply-chain security

Why dependencies are an attack surface

Most of the code in a modern service was not written by the team that runs it. A small web service may declare twenty direct dependencies and, through their dependencies in turn, install several hundred packages; the container it ships in adds an operating-system userland, and the pipeline that builds it runs compilers, plug-ins and CI actions written by still more people. Section 0.3 introduced dependencies as a saving in effort with a maintenance cost. This section looks at their security cost: every one of those components, and every person and system able to change them, is part of your attack surface.

A software supply-chain attack compromises something you consume in order to reach you, usually many victims at once. It can arrive in four broad ways. Malicious code from a trusted source: a maintainer's account is phished, a maintainer turns hostile, or a project is handed to a stranger. Malicious look-alikes: typosquatting publishes reqeusts next to requests; dependency confusion, demonstrated by Alex Birsan in February 2021, publishes a package on the public registry with the same name as a company's internal package and a higher version number, which some build tools then prefer. Tampering in the pipeline: the source is fine but the build system, the signing keys or the registry are compromised. Honest vulnerabilities: no attacker was involved in writing the code, but a serious bug in a widely used transitive dependency exposes everyone who ships it.

Recent years have shown how fast the first kind spreads. In March 2025 the version tags of a popular GitHub Action, tj-actions/changed-files, were moved to a malicious commit that printed CI secrets into build logs, affecting thousands of repositories that referred to the action by tag. In September 2025 a maintainer of widely used npm packages such as chalk and debug was phished through a fake npm support site, and malicious versions were published and removed within hours; later the same month a self-propagating worm, nicknamed Shai-Hulud, stole npm tokens and used them to publish infected versions of further packages.

Four incidents, told accurately

event-stream (2018). event-stream was a popular npm package, downloaded about two million times a week, whose original author no longer had time for it. In September 2018 he handed publishing rights to a volunteer who had offered to help. The new maintainer added a dependency, flatmap-stream, whose published package contained an encrypted payload that activated only inside the build of Copay, a bitcoin wallet application, and tried to steal wallets with large balances. A developer noticed the suspicious code in November 2018. Nothing in npm's model had been broken: a trusted name had simply changed hands.

SolarWinds (2020). Attackers, later attributed by the US government to Russia's foreign intelligence service, gained access to the build environment of SolarWinds, the maker of the Orion network management product. An implant (named SUNSPOT by investigators) watched for Orion builds and swapped one source file for a backdoored version during compilation, then put the original back. The resulting updates, published between March and June 2020, were built by SolarWinds' own pipeline and signed with its genuine certificate. About 18,000 customers installed them; the attackers then chose a much smaller number of government agencies and companies for follow-on intrusion. FireEye discovered the campaign in December 2020 while investigating its own breach. The lesson for architects: a signature proves who built something, not that the build was clean.

Log4Shell (2021). CVE-2021-44228, disclosed on 9 December 2021 and scored 10.0 under CVSS, was a flaw in Log4j 2, the dominant Java logging library. Log4j resolved lookups written inside log messages, including JNDI lookups that could load a class from a remote server, so an attacker who could get a string such as a username or a request header logged could run code on the server. No attacker had touched the supply chain; the damage came from how widely, and how deeply, the library was embedded. Organisations spent weeks finding where they used it, several follow-up releases were needed to close related flaws, and those with an accurate inventory answered the question in hours.

xz utils (2024). xz is a compression library used, through other libraries, by the OpenSSH server on several Linux distributions. Over about two years an account called Jia Tan contributed useful work and, helped by other accounts pressing the overworked original maintainer to accept help, became a co-maintainer. Versions 5.6.0 and 5.6.1, released in February and March 2024, contained a backdoor that would let the holder of a specific private key run commands through SSH. The malicious code was hidden in binary test files and activated by a modified build script that existed only in the release tarballs, not in the public repository. On 29 March 2024 Andres Freund, a developer at Microsoft, disclosed it after investigating why SSH logins on a test system used unusual CPU and took about half a second longer; it was tracked as CVE-2024-3094. Because it was caught early, it had reached mainly development and rolling-release distributions rather than stable ones.

Software bills of materials

A software bill of materials (SBOM) is a machine-readable list of the components in a piece of software, with versions, identifiers and the relationships between them. It does not make software safer by itself; it makes questions answerable. When the next Log4Shell is announced, a searchable store of SBOMs for every deployed artefact turns are we affected, and where? into a query.

Two formats dominate. SPDX, from the Linux Foundation, began as a licence-compliance format; version 2.2.1 is the international standard ISO/IEC 5962:2021, and SPDX 3.0 (2024) adds profiles for security, builds and AI. CycloneDX, an OWASP project designed for security use cases, is standardised by Ecma International as ECMA-424; version 1.7 was released in October 2025. Both can identify components with a package URL (purl), such as pkg:npm/express@4.21.2, which is what vulnerability databases match against. The companion idea of VEX (Vulnerability Exploitability eXchange) lets a supplier state that a listed vulnerable component is not exploitable in its product, for example because the vulnerable function is never called, which cuts the noise for customers.

Policy pushed SBOMs into the mainstream. US Executive Order 14028, Improving the Nation's Cybersecurity, signed on 12 May 2021, set out software supply-chain measures for software sold to the federal government, including providing purchasers with an SBOM; the National Telecommunications and Information Administration then published the minimum elements of an SBOM (supplier, component name, version, other unique identifiers, dependency relationships, author of the SBOM data and a timestamp). US policy has since moved away from uniform mandates: in January 2026 the Office of Management and Budget's memorandum M-26-05 rescinded the earlier requirement for suppliers to attest to secure development practices, leaving agencies to set risk-based requirements and to ask for SBOMs where they choose. In the EU, the Cyber Resilience Act described below makes an SBOM part of the technical documentation for products with digital elements.

Generate SBOMs during the build, from what was actually resolved and packaged, rather than from the manifest a developer wrote; store them alongside the artefact, keyed by its digest; and feed them to a service that re-checks every stored SBOM when a new vulnerability is published.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "metadata": {"timestamp": "2026-10-20T09:14:02Z",
               "component": {"bom-ref": "orders-service", "type": "application",
                             "name": "orders-service", "version": "4.12.0"}},
  "components": [
    {"bom-ref": "log4j-core", "type": "library", "name": "log4j-core",
     "group": "org.apache.logging.log4j", "version": "2.24.3",
     "purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.24.3",
     "hashes": [{"alg": "SHA-256", "content": "9f2c..."}]},
    {"bom-ref": "jackson-databind", "type": "library", "name": "jackson-databind",
     "version": "2.18.2",
     "purl": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.18.2"}
  ],
  "dependencies": [
    {"ref": "orders-service", "dependsOn": ["log4j-core", "jackson-databind"]}
  ]
}

SLSA: levels for build integrity

SLSA (Supply-chain Levels for Software Artifacts, pronounced salsa) is a framework, now maintained under the Open Source Security Foundation, that describes incremental levels of protection against tampering. Version 1.0 (2023) defined a Build track; version 1.2 restructured the specification into several tracks and added a Source track. The central artefact is provenance: a signed statement, usually in the in-toto attestation format, of which build platform produced an artefact, from which source revision, with which build definition and parameters. A consumer verifies provenance against expectations such as built by our CI from the main branch of github.com/fooddelivery/orders.

The Source track has four levels: version control (L1), continuous, immutable history with provenance for each revision (L2), continuously enforced technical controls such as protected branches (L3), and two-party review of every change to protected branches (L4). For most organisations the realistic target is Build L3 on a shared, well-run build platform plus Source L3 or L4 for important repositories; the levels say what a platform must guarantee, and a platform team can meet them once for every service.

Signing and provenance with Sigstore

Signing artefacts has long been possible, but managing long-lived signing keys was so burdensome that few open-source projects did it, and stolen keys were themselves a risk. Sigstore, launched in 2021 and now part of the Open Source Security Foundation, makes signing cheap through keyless signing. A CI job proves its identity to Fulcio, Sigstore's certificate authority, with an OpenID Connect token; Fulcio issues a certificate valid for a few minutes that names that identity, such as a specific workflow in a specific repository; the tool signs the artefact and records the signature in Rekor, a public append-only transparency log; the ephemeral private key is then discarded. Verifiers check the signature, the identity in the certificate and the log entry, instead of trusting a key that might have leaked.

The cosign tool applies this to container images and other artefacts, and package ecosystems have adopted the same ideas: npm can publish packages with provenance statements linking them to the source repository and build (2023), and PyPI supports trusted publishing from CI without long-lived tokens (2023) and attestations based on Sigstore (2024). At deployment, an admission controller in Kubernetes, such as Sigstore's policy controller or Kyverno, can refuse any image that is not signed by the expected identity or lacks the expected provenance. Remember SolarWinds: signing and provenance prove where something came from; only build isolation, review and detection make what came out trustworthy.

Lockfiles, pinning and automated updates

A manifest such as package.json or pyproject.toml states acceptable version ranges; a lockfile (package-lock.json, poetry.lock, uv.lock, go.sum, Cargo.lock) records the exact versions resolved, usually with a cryptographic hash of each. Committing the lockfile and installing from it in CI (npm ci, pip install --require-hashes) means that every build uses the same reviewed bytes, and that a package republished with different content fails the hash check. Pinning applies to build tooling too: refer to CI actions by full commit hash, not by a tag that its owner, or an attacker, can move, which is exactly what made the tj-actions incident spread; refer to base images by digest.

Pinning without updating creates the opposite risk: old versions accumulate known vulnerabilities and upgrades grow too large to attempt. Update bots such as Dependabot and Renovate open small, frequent pull requests that CI tests automatically. A useful refinement is a minimum release age, waiting a few days before adopting a routine new version, because most malicious releases are detected and pulled within hours or days; security fixes are exempt and fast-tracked.

Software composition analysis (SCA) tools, such as OWASP Dependency-Check, Trivy, Grype or commercial services, match your dependencies against vulnerability databases. Their weakness is noise: hundreds of findings, most in code paths you never call. Prioritise with exploit data (is it in the CISA Known Exploited Vulnerabilities catalogue, what is its EPSS score?), with reachability analysis where your tools offer it, and with exposure (is the service internet-facing?). Section 8.8 covers vulnerability management as a process.

Containers and build integrity

A container image carries an operating-system userland as well as your code, and every package in it is part of the supply chain. Start from minimal base images (distroless, Alpine, or slim distribution images), which contain fewer packages to be vulnerable; rebuild images regularly so that base-image fixes arrive even when your code has not changed; scan images in CI and again continuously in the registry, because new vulnerabilities are published against old images every day; and deploy images by digest so that what was scanned is what runs.

The build system is the most valuable target in the chain because it touches everything, as SolarWinds showed. Run builds on ephemeral runners that are created for one job and destroyed afterwards, so that an attacker cannot persist between builds. Make builds hermetic, with all inputs declared and fetched by hash and no network access during compilation, so that undeclared inputs cannot slip in. Keep long-lived secrets out of CI by using OIDC federation to obtain short-lived cloud credentials for each job, and give each pipeline the least privilege it needs, so that a pull request from a fork cannot reach the deployment credentials. Protect the release path with branch protection and two-person review. Finally, reproducible builds, where the same source always produces bit-for-bit identical output, let independent parties rebuild and compare; the Reproducible Builds project and distributions such as Debian have made most of their packages reproducible, and a mismatch is strong evidence of tampering.

The EU Cyber Resilience Act

The Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, sets horizontal cybersecurity requirements for products with digital elements placed on the EU market: hardware and software products, including their remote data processing solutions. It entered into force on 10 December 2024 and applies in stages. The rules on notifying conformity assessment bodies apply from 11 June 2026. The reporting obligations in Article 14 apply from 11 September 2026: a manufacturer must report an actively exploited vulnerability or a severe incident affecting the security of its product with an early warning within 24 hours of becoming aware, a fuller notification within 72 hours and a final report later (for a vulnerability, within 14 days after a corrective measure is available; for a severe incident, within one month), through the single reporting platform run by ENISA, the EU cybersecurity agency. Most other obligations apply from 11 December 2027.

The essential requirements in Annex I are architectural as much as procedural: products must be designed with an appropriate level of security, delivered with a secure default configuration, limit attack surfaces, protect the confidentiality and integrity of data, minimise data, and be able to log security events and receive security updates. Manufacturers must identify and document components, including by drawing up an SBOM covering at least top-level dependencies, handle vulnerabilities through a coordinated disclosure policy, and provide security updates for a support period that should normally be at least five years unless the product is expected to be used for less. Fines for breaching the essential requirements or the manufacturers' obligations can reach EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher.

Scope matters. Free and open-source software developed or supplied outside a commercial activity is outside the CRA, and a lighter regime applies to open-source software stewards that support such software for commercial use. Pure software as a service is generally outside the CRA unless it is the remote data processing solution of a product; cloud and other digital service providers may instead fall under the NIS2 Directive. Whether a particular product is in scope, and which conformity route applies, is a legal question for each organisation; the architectural consequence is that SBOMs, vulnerability handling, update mechanisms and security logging become evidence that has to exist, not good intentions.