Most shipped software is other people’s code and tooling, so a compromised dependency, build system or update channel reaches every user at once. The 2025 edition expanded the 2021 category Vulnerable and Outdated Components to cover the whole chain.
- Keep an SBOM for everything you ship, including transitive dependencies, and remove components you do not use.
- Monitor components for vulnerabilities and end of life, and choose and upgrade versions deliberately.
- Obtain components from trusted sources, prefer signed packages, and verify the provenance of your own artifacts.
- Harden repositories, CI/CD and developer workstations with MFA, least privilege, protected branches and change tracking, and roll out updates in stages.
Guides on this site
Respond to an exploited or malicious dependency
When a dependency vulnerability is being exploited, or a package version is malicious, triage gives way to incident response: find every running copy, contain it, patch and redeploy, hunt for exploitation, rotate secrets and close on deployed evidence.
Protect the path from pull request to release
Separate untrusted contribution checks from privileged release work and verify the identity of the artifact that is actually deployed.
Generate an SBOM for the software you actually release
Define the inventory boundary, compare build and artifact evidence, and connect the resulting SBOM to an immutable release.
Choose SBOM formats and identify components accurately
Separate schema versions, document references and package identities so inventory conversion and advisory matching preserve meaning.
Review SBOM changes between releases
Turn inventory differences into explainable release decisions without confusing generator changes with software changes.
Triage new dependency vulnerability findings
Turn a weekly batch of Dependabot, OSV-Scanner or npm audit findings into a short list of distinct, shipped, reachable issues, each routed to one outcome: fix, not affected, accept or escalate.
Verify artifact signatures against an explicit trust policy
Require the expected artifact, signer and release context before allowing a signed package or image to proceed.
Read SLSA provenance and verify the claim you need
Connect an artifact to its build evidence while distinguishing provenance, build assurance and source controls.
Keep untrusted CI work outside the release boundary
Review workflow authority, persistent state and artifact handoffs before contributor-controlled code reaches privileged jobs.
Investigate a suspected malicious package safely
Distinguish package substitution, publisher compromise and dangerous installation behavior while containing exposure and preserving evidence.
Use VEX without losing vulnerability evidence
Produce and consume precise vulnerability status statements tied to the product, version, justification and evidence.
Investigate build differences and improve reproducibility
Control inputs and environment, compare artifact bytes, and explain the security properties a repeatable build can demonstrate.
Review dependency health without treating a score as a guarantee
Combine security practices, maintenance, licensing and product exposure into a recorded adoption or replacement decision.
Protect package publication and the update channel
Constrain release identities, verify what consumers receive, and prepare for publisher or update-key compromise.
Stop dependency confusion and typosquatting at install time
Pin every internal package name to its real source, verify installed bytes against a lockfile, and delay or gate install scripts so a public look-alike cannot replace a private dependency.
Harden GitHub Actions against workflow and supply-chain attacks
Close the paths that give untrusted pull-request code secrets or a write token: pass context through env, keep pull_request_target away from fork code, pin actions to commit SHAs, scope GITHUB_TOKEN and OIDC, and treat artifacts as data.
Case study: the xz Utils backdoor (CVE-2024-3094)
How a multi-year maintainer takeover planted a backdoor in xz Utils release tarballs, how build-time injection hid it from the git repository, why a performance anomaly exposed it, which systems shipped it, and what it teaches about reproducible builds and maintainer health.
Case study: the Shai-Hulud npm worm (2025-2026)
How a self-replicating npm worm turned stolen tokens into hundreds of infected packages in 2025, how its 2026 successors hijacked release pipelines and trusted publishing, what npm and GitHub changed in response, and the publishing, install and response practices that stop it.
Case study: the tj-actions/changed-files compromise (CVE-2025-30066)
In March 2025 an attacker moved the version tags of a popular GitHub Action, and of a reviewdog action before it, to code that printed CI secrets into build logs. This case study traces the token chain back to one pull_request_target workflow, sizes the exposure, and shows how it was caught and which controls held.
Design firmware updates that can recover safely
Connect trusted boot, update authorization, rollback policy and end-of-life behavior to the device’s actual failure modes.
Supplier software assurance: check SOC 2 reports, SBOMs and signed updates against your use
Connect supplier claims to product scope, supported versions, release integrity and vulnerability handling before making a procurement decision.
Treat model releases as executable supply-chain inputs
Verify provenance, constrain loading and preserve the relationship between model weights, configuration and runtime dependencies.
Place each security control in the pipeline and decide what it blocks
Put secrets scanning, SAST, SCA, IaC and image scanning, DAST, fuzzing, attestation and admission control where each sees the right input, block only on findings a developer can act on, and deploy only images the pipeline has attested.
Harden container images from Dockerfile to admission
Build minimal, non-root images pinned by digest, keep secrets out of every layer, then scan, sign and verify the exact digest before it runs with dropped privileges.
Practice
- SBOM completeness lab: Find the dependencies missing from a release SBOM · Browser lab
- Signed artifact provenance lab: Reject a release from the wrong producer · Browser lab
- Actions injection lab: Flag GitHub Actions expression injection · Browser lab
- Build and verify a signed software release · Local project
- Repair a security pipeline for GitHub Actions and GitLab CI · Local project
- Recover from failed firmware updates with A/B slots · Local project
- Gate an image build on a CIS scan and a deviation register · Local project
References
List data from the publisher. A guide is listed as the main subject when the weakness or risk is what the guide is about, and as covering it when a dedicated section or worked example addresses it.