Operations & Community
Security & Supply Chain
Threat model, attack techniques, incidents, defences — and the role of the SBOM in supply-chain security.
Security & the Software Supply Chain
Modern software is mostly assembled, not written. That is efficient and it is also the largest unmanaged attack surface most organisations have.
1. Threat model
Three distinct problems get collapsed into "supply chain risk". Separate them, because the defences differ.
| Problem | Question it answers | Primary defence |
|---|---|---|
| Known vulnerability | Do I depend on something with a published CVE? | SBOM + vulnerability feed + patching |
| Unknown provenance | Is this artifact really what the project built, from that source? | Signing, SLSA provenance, reproducible builds |
| Malicious change | Did someone deliberately put bad code in? | Review, maintainer trust, monitoring, minimal dependency surface |
A fourth, non-security risk rides along: licence and maintenance risk — a dependency that is abandoned or relicensed.
2. Attack techniques
| Technique | How it works | Defence |
|---|---|---|
| Typosquatting | Publish requsts alongside requests | Private proxy with allow-listing; check download counts and age |
| Dependency confusion | Publish an internal package name publicly with a high version | Scope internal packages; pin registries per package |
| Account takeover | Phish a maintainer's registry credentials | MFA; short-lived tokens; monitor for unexpected releases |
| Malicious handover | Volunteer to take over a tired maintainer's popular package | Social, not technical |
| Long-con infiltration | Spend years becoming a trusted co-maintainer | Governance hygiene — and luck |
| Malicious install scripts | postinstall hooks exfiltrate env vars and CI secrets | --ignore-scripts; scoped, short-lived CI secrets |
| Self-replicating worms | Stolen publish tokens republish other packages | Token scoping and expiry; registry anomaly detection |
| Build/CI compromise | Attack the build system, not the source | SLSA provenance, hermetic builds, signed attestations |
| Protestware / sabotage | Maintainer weaponises their own package | Pinning, review of upgrades, fast rollback |
| Registry/mirror compromise | Compromise a CDN or mirror serving artifacts | Subresource integrity; vendor critical JS |
3. Notable incidents
| Date | Event |
|---|---|
| 2014-04 | Heartbleed (CVE-2014-0160) — an OpenSSL bug, and a funding wake-up call |
| 2018-11 | event-stream — a maintainer handed the package to a volunteer who added a dependency stealing wallet keys |
| 2020-12 | SolarWinds — build-system compromise; not itself an OSS incident but the template for "trust the pipeline" |
| 2021-12-10 | Log4Shell (CVE-2021-44228) — JNDI lookup in a ubiquitous logging library; the event that made SBOMs policy |
| 2022-03 | node-ipc / colors.js — protestware overwriting files on machines in specific countries |
| 2024-03-29 | xz (CVE-2024-3094) — "Jia Tan" cultivated trust for ~3 years and planted a backdoor in liblzma that would have given RCE via sshd. Found by a performance anomaly, not a scanner |
| 2024-06 | polyfill.io — a widely embedded CDN script served malware after the domain changed hands |
| 2025-09-15 | Shai-Hulud npm worm — post-install scripts stole tokens and self-propagated across 500+ packages |
4. If you consume open source
Do these first — high value, low cost
- Generate an SBOM in CI for every build.
- Commit lockfiles; pin versions; review dependency diffs like code.
- Turn on automated scanning (Dependabot, Renovate, Trivy, Grype, OSV-Scanner).
- Mirror through a private proxy with an allow-list for new packages.
- Verify checksums and signatures of downloaded artifacts.
- Disable install scripts where the ecosystem allows it; keep CI secrets scoped and short-lived.
- Track end-of-life: a dependency on an unsupported runtime is an unpatchable CVE waiting to happen.
Then these — more work, real payoff
- Publish and consume VEX: "this CVE is in our dependency but not exploitable here".
- Require SLSA provenance and signature verification for critical artifacts (Sigstore/cosign).
- Reproducible builds: verify the binary matches the source.
- Rank dependencies by criticality and bus factor; fund the ones you cannot replace.
- Reduce dependency count — the cheapest control is fewer dependencies.
- Have a rollback path: can you rebuild last week's artifact today?
The alert-fatigue fix is VEX, not more scanning. Most reported CVEs in a typical application are unreachable in practice. Recording why they are not exploitable is what makes the remaining alerts actionable.
5. If you publish open source
- Enable MFA on the registry and the forge. Use short-lived, automation-scoped publish tokens — never a personal token in CI.
- Require 2FA for maintainers and turn on branch protection: no direct pushes to the release branch, required reviews, signed commits.
- Sign releases and publish provenance: Sigstore/cosign, GitHub artifact attestations, GPG-signed tags.
- Publish
SECURITY.md, register as a CNA, state your disclosure policy. - Run the OpenSSF Scorecard and act on it: pinned dependencies, fuzzing (OSS-Fuzz), SAST, maintained dependencies, required code review.
- Aim for SLSA Build Level 2–3 for distributed artifacts.
- Do not accept maintainership transfers casually. The xz campaign succeeded because handing a package to a helpful stranger was normal practice.
- Publish an SBOM with each release so downstream can answer "am I affected?" in minutes.
6. Where the SBOM fits
An SBOM is the inventory layer everything else is joined against. On its own it prevents nothing; paired with vulnerability feeds, licence policy and VEX, it turns an incident into a query.
| Question | Answered by |
|---|---|
| Do we use the vulnerable component? | SBOM + vulnerability feed (OSV, NVD, GitHub Advisories) |
| Is it actually reachable in our build? | VEX + reachability analysis |
| Which licences are we shipping? | SBOM licence fields + SPDX identifiers |
| Did this artifact come from that source? | Provenance + signature, not the SBOM |
| Are we compliant with EO 14028 / EU CRA? | SBOM completeness against NTIA minimum elements |
The two standards are SPDX (ISO/IEC 5962) and CycloneDX (ECMA-424).
7. Tooling
| Job | Tools |
|---|---|
| SBOM generation | Syft, Trivy, cdxgen, SPDX SBOM Generator, ORT, CDX Gradle/Maven plugins |
| Vulnerability scanning | Grype, Trivy, OSV-Scanner, Dependency-Track |
| Signing & provenance | Sigstore/cosign, GitHub artifact attestations, in-toto, SLSA |
| Repository hygiene | OpenSSF Scorecard, Allstar, Dependabot, Renovate |
| Fuzzing & analysis | OSS-Fuzz, CodeQL, Semgrep |
| Policy & governance | Dependency-Track, GUAC, Trustify |
See also: Business models · Compliance · Tooling · Glossary