Supply chain risk
Why the CRA cares
Most of the code in a modern product was not written by its manufacturer. The Regulation draws the consequence: it mandates an inventory, diligence at integration, and upstream reporting of vulnerabilities. The supply chain is the subject; the SBOM is only the instrument.
Attack typology
| Type | Mechanism | Documented case | What would have helped |
|---|---|---|---|
| Repository or maintainer compromise | Credential theft, takeover of a publishing account | ua-parser-js, Oct 2021 | Signature verification, hash pinning |
| Build chain compromise | Injection into the supplier’s build environment | SolarWinds, Dec 2020 · CCleaner, Sep 2017 | Provenance attestations, reproducible builds |
| Typosquatting | A package named close to a legitimate one | Recurring campaigns on public registries | Internal proxy registry, allow list |
| Dependency confusion | A public package outranks a same-named internal one | Research work, Feb 2021 | Reserved namespaces, explicit resolution priority |
| Malicious package published | Hostile code from the first version | event-stream, Nov 2018 | Human review of new dependencies, quarantine period |
| Mass vulnerability in a ubiquitous library | A defect in a component present everywhere | Log4Shell, Dec 2021 | Centralised SBOM: answer in minutes rather than weeks |
| Long-game social engineering backdoor | A contributor earns the project’s trust, then introduces a subtle defect | xz / liblzma, Mar 2024 | Maintainer diversity, review, reproducible builds |
| Commercial supplier compromise | A legitimate third-party product becomes the vector | 3CX, Mar 2023 · Kaseya, Jul 2021 | Segmentation, least privilege, behavioural monitoring |
| Takeover of an abandoned component | A third party takes control of a neglected project | polyfill.io, Jun 2024 | Monitoring maintainer changes |
| Hijacking a build chain step | A reused CI action is repointed to malicious code | tj-actions, Mar 2025 | Hash pinning, least-privilege tokens |
Each case is documented, dated and sourced in Reference incidents: what happened, what would have limited the damage, and the requirement the incident illuminates.
What an SBOM does and does not enable
Enables: knowing instantly which products and which shipped versions contain a given component. That is response capability, and it turns a multi-week crisis into a day’s work.
Does not enable: detecting malicious code. A hostile package that is correctly inventoried looks like any other. The SBOM answers “what is inside”, not “is it clean”.
It must therefore be complemented by provenance verification, signing, review of new dependencies and hardening of the build chain.
Countermeasures
On dependencies
- Internal proxy registry: all dependencies pass through a controlled mirror, never directly from a public repository.
- Version pinning and hash locking: the lock file is committed, and the build fails if a hash differs.
- Reserved namespaces for your internal packages, in the public registry where relevant, to prevent dependency confusion.
- Quarantine: a new dependency becomes available only after a delay and a review.
- Human review of additions and of major upgrades to sensitive dependencies.
On the build chain
The subject is covered in detail in Securing the build chain; in summary:
- Isolated runners, ephemeral, with no uncontrolled outbound network access.
- Least privilege on publishing tokens; ephemeral tokens rather than long-lived secrets.
- Separation between building and publishing.
- Provenance attestations signed by the build service, not by the commit author.
- Reproducible builds, in time, to allow independent verification.
On detection
- Monitoring maintainer and licence changes on critical dependencies.
- Behavioural analysis of install scripts, a common vector.
- Detecting gaps between build SBOM and analysed SBOM, which reveals undeclared additions.
Mapping your exposure
An exercise to run once, then maintain from the platform:
| Question | What it reveals |
|---|---|
| Which components are present in more than half your products? | Single points of failure |
| Which are maintained by one person? | Takeover or abandonment risk |
| Which have had no release for more than two years? | Abandonment candidates |
| Which are deep in the graph, out of your direct sight? | Diligence blind spots |
| Which execute code at install time? | Build chain attack surface |
| Which carry a risky licence, or one that has changed? | Legal risk |
The map does not need to be exhaustive to be useful: the ten to twenty most critical components concentrate most of the risk, and dealing with them is fundable.
The message for leadership
A supply chain attack cannot be wholly prevented. What is decided is the reaction time. Without a centralised inventory that time is measured in weeks and the response is incomplete; with one it is measured in hours and the response is exhaustive. That is the value of the arrangement, independently of any regulatory obligation.