Software Supply Chain Security

Software supply chain security addresses the risks introduced when a product incorporates code or components that the manufacturer did not write: open-source packages, commercial SDKs, licensed firmware, cloud service integrations, and build toolchain components. A supply chain attack occurs when an attacker compromises a trusted upstream component — for example, injecting malicious code into a popular open-source library — and the malicious code is then automatically incorporated into downstream products. High-profile supply chain incidents have demonstrated that a single compromised dependency can affect thousands of products simultaneously. Software Bill of Materials (SBOM) is the foundational tool for supply chain visibility.

Annex I Part I(2)(f) of the CRA requires manufacturers to address and remediate vulnerabilities, explicitly including vulnerabilities in components integrated into the product. Recital 21 acknowledges the risk posed by open-source software in supply chains and encourages manufacturers to perform due diligence on components they integrate. Article 13(5) requires manufacturers to identify and document the components their products contain — the legal basis for the SBOM obligation. Manufacturers cannot disclaim responsibility for a vulnerability in a third-party library simply because they did not write the library: the product is their product and the vulnerability is their obligation.

A robust supply chain security programme includes: (1) maintaining a complete, machine-readable SBOM in CycloneDX or SPDX format for every product release; (2) conducting Software Composition Analysis (SCA) during CI/CD pipelines to detect known vulnerabilities in dependencies at build time; (3) pinning dependency versions and verifying integrity via cryptographic hashes or signed packages; (4) establishing a policy for evaluating the security posture of new open-source dependencies before integration; (5) subscribing to vulnerability advisories for all integrated components and having a defined process for expedited patching when a critical supply chain vulnerability is disclosed. SBOM data should be updated with every product release.

The most pervasive supply chain security error is not knowing what dependencies a product contains. Manufacturers who cannot produce an SBOM cannot assess their exposure when a major open-source vulnerability is disclosed, resulting in reactive fire-fighting rather than planned remediation. A second error is treating SBOM as a one-time deliverable generated at product launch, rather than a living artefact updated with every build. Manufacturers also often neglect indirect (transitive) dependencies: a directly integrated library that itself depends on a vulnerable component is equally a risk, but transitive dependencies are frequently missing from manually maintained SBOMs.