Cybersecurity
Software supply-chain security
How modern attacks move through dependencies, build systems, and image registries — and the defences (SLSA, sigstore, SBOMs) that block them.
Software supply-chain attacks compromise the trust chain between an open-source maintainer's laptop and your production workload. The notorious examples — SolarWinds, Log4j, the XZ backdoor — each exploited a different link in that chain.
Notifire tracks the practical defences engineering teams are deploying: SLSA provenance attestations, sigstore/cosign image signatures, deps.dev for transitive-dependency scoring, and admission controllers that refuse unsigned artifacts.
Latest briefings on Software supply-chain security
No briefings on this topic yet. Subscribe to the feed and we\u2019ll cover it as the news cycle moves.
Frequently asked questions
What is SLSA?
Supply-chain Levels for Software Artifacts — a framework that scores how trustworthy a build pipeline is. Level 1 produces provenance metadata; Level 4 means the build is hermetic, reproducible, and signed by a trusted builder. Most projects target Level 2 or 3.
Is a SBOM enough?
No. A SBOM tells you what's inside an artifact, but only matters if you can act on it: subscribe to CVE feeds against the SBOM, enforce policy on which components are allowed, and trace a specific CVE to specific running workloads in minutes. A SBOM in a drawer is decorative.
How did the XZ backdoor change supply-chain practice?
It demonstrated that a single trusted maintainer could compromise a foundational library after years of legitimate contributions. The response has been more aggressive review of maintainer identity, build reproducibility checks, and a hard look at the long tail of barely-staffed but widely-depended-on projects.