Supply chain security
By the end of this module you will be able to:
- Compare SPDX 2.3 and CycloneDX 1.5 SBOM formats and select the appropriate format for a given use case
- Apply the SLSA framework levels to assess and improve software build provenance
- Describe how Sigstore enables keyless code signing using short-lived OIDC-bound certificates
- Explain how transitive dependencies amplify supply chain risk and how SCA tooling must be configured to address it
SolarWinds Orion SUNBURST supply chain attack, December 2020
SolarWinds SUNBURST: 18,000 organisations, one trojanised build pipeline
In December 2020, CISA disclosed that the SolarWinds Orion platform, installed by approximately 18,000 organisations including multiple US federal agencies, had been compromised at the build level. Attackers attributed to Russian SVR intelligence inserted the SUNBURST backdoor into the SolarWinds build environment during the compilation phase. The resulting DLL was signed with SolarWinds' legitimate code signing certificate and distributed via the normal Orion update mechanism.
Customers installed it because the update was signed, matched the expected hash, and arrived from a trusted supplier. SUNBURST included a two-week activation delay and active checks for security tooling to avoid detection. The attack was discovered externally when FireEye identified the SUNBURST artefact after its own network was breached.
The attack exploited the foundational assumption of supply chain trust: if a signed artefact arrives from a known vendor, most security controls allow it through without further scrutiny.
The software supply chain as an attack surface
The software supply chain encompasses all components, tools, processes, and people involved in producing and delivering software: source code, build tooling, CI/CD pipelines, third-party libraries, container base images, and distribution mechanisms. An attacker who compromises any element can inject malicious code into every downstream consumer.
Supply chain attacks are effective because they subvert the trust model organisations rely on. The four primary attack surfaces are:
- Source code: direct compromise of a source repository via a malicious maintainer or a compromised developer account.
- Build environment: compromising the CI/CD pipeline or build server to modify artefacts during compilation. SolarWinds 2020 is the canonical example.
- Dependencies: publishing a malicious package to a public registry (dependency confusion, typosquatting) or compromising an existing popular package.
- Distribution: compromising the update server, package registry, or CDN used to deliver software to end users.
The NIST SP 800-161r1 C-SCRM (Cyber Supply Chain Risk Management) framework provides a risk management structure for organisations to identify, assess, and respond to supply chain risks across all attack surfaces listed above. The 2021 US Executive Order 14028 on Improving the Nation's Cybersecurity mandated SBOM production for all software sold to the US federal government, directly in response to the SolarWinds incident.
With an understanding of the software supply chain as an attack surface in place, the discussion can now turn to sbom formats: spdx 2.3 and cyclonedx 1.5, which builds directly on these foundations.
SBOM formats: SPDX 2.3 and CycloneDX 1.5
A Software Bill of Materials (SBOM) is a machine-readable inventory of all components in a software artefact, including their versions, licences, and relationships. Two formats dominate:
SPDX 2.3 (Software Package Data Exchange), standardised as ISO/IEC 5962:2021 by the Linux Foundation, is optimised for licence compliance tracking. It is the format mandated by US Executive Order 14028 for software sold to the US federal government. SPDX 2.3 supports package metadata, licence expressions in SPDX-Licence-Expression format, file-level checksums, and relationship types (CONTAINS, DEPENDS_ON, GENERATED_FROM).
CycloneDX 1.5, maintained by OWASP, is optimised for vulnerability management and supply chain security workflows. CycloneDX 1.5 adds native VEX (Vulnerability Exploitability eXchange) support for communicating whether a known CVE is actually exploitable in a given context, service dependency mapping, component provenance evidence, and the ability to embed SAST, DAST, and composition analysis results.
Most organisations generate both formats using the open-source tool Syft (Anchore): SPDX 2.3 for regulatory compliance submission and CycloneDX 1.5 for internal vulnerability management workflows. Generating both from the same build pipeline adds minimal overhead.
With an understanding of sbom formats: spdx 2.3 and cyclonedx 1.5 in place, the discussion can now turn to slsa framework and sigstore code signing, which builds directly on these foundations.
“Organizations should develop and maintain an accurate inventory of all components in their software products, including open source software, commercial software, and internally developed code. This inventory should include version information, known vulnerabilities, and licensing information.”
NIST SP 800-161r1, Section 2: C-SCRM Fundamentals
“Organizations should establish and maintain a process to identify, assess, and manage cybersecurity risks in their supply chain. This includes identifying critical suppliers and third-party service providers and assessing their security practices.”
NIST SP 800-161r1: Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, Section 2.2 (2022)
SLSA framework and Sigstore code signing
SLSA (Supply chain Levels for Software Artefacts, pronounced "salsa") is a security framework published by Google in 2023 providing incrementally stronger guarantees about the provenance of software build artefacts. It defines four levels based on provenance verifiability and tamper-resistance:
- Build L0: no provenance document; no guarantee about how the artefact was produced.
- Build L1: the build generates a provenance document attesting how the artefact was built; not signed, so tamper-evident but not tamper-proof.
- Build L2: provenance is signed by the build service and the build runs on a hosted platform (such as GitHub Actions). An artefact cannot be produced with a valid provenance signature outside the known build platform.
- Build L3: hardened build platform where the build instructions (the workflow script) cannot access the signing key. Even a compromised build script cannot produce valid L3 provenance for a tampered artefact. This is the level at which the SolarWinds attack would have been detectable: the compromised build step could not have produced a valid L3 provenance for the trojanised DLL.
Most open-source projects operate at SLSA L0 or L1. GitHub Actions supports native SLSA provenance generation; projects adopting SLSA L2 via GitHub Actions achieve signed provenance at near-zero additional overhead.
Sigstore provides keyless code signing infrastructure. Rather than long-lived signing keys (which become targets for compromise), Sigstore issues short-lived certificates bound to an OIDC identity such as a GitHub Actions workflow. The three Sigstore components are: cosign (signs and verifies container images and artefacts), Rekor (an immutable transparency log recording all signatures), and Fulcio (the CA that issues short-lived OIDC-bound certificates). The Kubernetes project adopted cosign-based signing from version 1.24 for all official release images and binaries.
With an understanding of slsa framework and sigstore code signing in place, the discussion can now turn to transitive dependency risk, which builds directly on these foundations.
Transitive dependency risk
A transitive dependency is a dependency of a dependency: if application A depends on library B, and B depends on library C, then C is a transitive dependency of A. A vulnerability in C affects A even if A has no direct reference to C in its own dependency manifest. A typical Node.js application may have hundreds of direct dependencies and thousands of transitive ones.
Log4Shell (CVE-2021-44228, CVSS 10.0) demonstrated transitive dependency risk at scale: many organisations had no idea Log4j was in their Java stack because it arrived via three or four levels of transitive dependency through other frameworks. The vulnerability affected essentially every Java application that logged user-supplied input, regardless of whether the development team had consciously included Log4j.
SCA (Software Composition Analysis) tooling must be configured to resolve the full dependency graph, not only direct dependencies. Snyk and OWASP Dependency-Check analyse the full transitive tree by default, but some teams configure them to scan only the top-level manifest, missing the majority of the attack surface. Dependency minimisation is an additional control: audit dependencies periodically for necessity, maintenance status, and community trust.
Common misconception
“Scanning only direct dependencies in a package.json or pom.xml provides adequate SCA coverage.”
Direct dependencies typically represent a small fraction of the total dependency graph. A Node.js application with 50 direct dependencies may have 1,000 to 5,000 transitive ones. Log4Shell reached thousands of Java applications as a transitive dependency, invisible in top-level manifests. SCA tooling must resolve the full dependency graph. When configuring Snyk, Dependabot, or OWASP Dependency-Check, verify that transitive dependency scanning is explicitly enabled.
Common misconception
“Software composition analysis (SCA) scanning in CI/CD is sufficient supply chain security for open-source dependencies.”
SCA identifies known CVEs in declared dependencies but has several significant gaps: it does not catch malicious packages injected through typosquatting (packages with names similar to popular libraries); it does not detect compromised maintainer accounts that push backdoored releases with no CVE yet published; it does not cover build-time dependencies consumed only during compilation; and it does not verify that the package binary matches the source code (i.e., a supply chain attack at the build or distribution stage). SCA is a necessary but insufficient control. Complement it with: pinned dependency hashes (not just version ranges), SLSA provenance verification, private mirror registries, and monitoring for unusual dependency changes in pull requests.
An organisation must satisfy two simultaneous requirements: US Executive Order 14028 compliance for a federal contract, and a continuous vulnerability management workflow using VEX (Vulnerability Exploitability eXchange) to suppress non-exploitable CVEs. Which combination of SBOM formats best satisfies both requirements?
A security architect reviews a critical open-source library's CI/CD pipeline. GitHub Actions produces a signed provenance attestation pushed to Rekor; the build runs on GitHub-hosted runners. The build workflow script has write access to the signing key used for provenance. Which SLSA level does this represent, and what must change to reach the next level?
The SolarWinds SUNBURST attack (December 2020) compromised SolarWinds' build system to insert malicious code into a signed software update distributed to 18,000 customers including US government agencies. This attack bypassed signature verification. Which supply chain security control at which SLSA level would have provided the strongest evidence that the build output did not match the expected source?
Key takeaways
- The software supply chain includes source, build environment, dependencies, and distribution. Each layer is an independent attack surface. SolarWinds exploited the build layer; Log4Shell exploited the transitive dependency layer.
- SPDX 2.3 (ISO/IEC 5962:2021) is mandated by US Executive Order 14028 for software sold to the federal government. CycloneDX 1.5 provides native VEX support for continuous vulnerability management. Generate both formats from each build using Syft.
- SLSA defines four build levels (L0-L3). L2, achievable on GitHub Actions with minimal effort, provides signed provenance tied to a specific build platform. L3 adds signing key isolation, preventing a compromised build script from forging provenance for a tampered artefact.
- Sigstore enables keyless code signing via short-lived OIDC-bound certificates (Fulcio CA), an immutable transparency log (Rekor), and the cosign CLI for signing and verification. Kubernetes adopted cosign signing from version 1.24.
- Transitive dependency scanning must explicitly cover the full dependency graph. Scanning only top-level manifests misses the majority of the attack surface. Log4Shell affected thousands of Java applications that had no direct dependency on Log4j.
You can now assess and mitigate supply chain risk. But vulnerabilities are discovered continuously - in your code and in the dependencies you rely on. How do you manage the lifecycle of vulnerabilities from discovery through remediation? Module 21 covers vulnerability management.
Standards and sources cited in this module
NIST SP 800-161r1: Cybersecurity Supply Chain Risk Management Practices
C-SCRM framework and supply chain risk management controls for federal agencies and suppliers.
SLSA framework v1.0 (slsa.dev)
Build track levels L0-L3: provenance requirements and tamper-resistance guarantees for software artefacts.
CISA Securing the Software Supply Chain (2022)
US government recommended practices for developers, suppliers, and customers to secure the software supply chain.
SPDX 2.3 Specification (ISO/IEC 5962:2021)
SBOM format for licence compliance and US EO 14028 regulatory submission.
OWASP SBOM format with native VEX support for vulnerability management workflows.