To mitigate supply chain attacks, you have to secure the parts of your software you did not write and the systems that assemble and deliver it: your dependencies, your build pipeline, and the artifacts that come out the other end. A modern application is mostly other people's code, wired together by automation you rarely audit, and attackers have learned that compromising one popular package or one build server is far more efficient than attacking each target individually. Defending against this means shifting attention from just your source code to the whole chain that produces your running software.
This is a concrete playbook, organized by the places an attacker actually enters.
Understand the attack surface first
A software supply chain attack compromises your software through something upstream of your own code. The recurring patterns are worth naming because your defenses map onto them:
A malicious or compromised dependency is the most common: an attacker publishes a package with a backdoor, takes over an abandoned one, or slips malicious code into a legitimate project. Typosquatting and dependency confusion trick your tooling into pulling a hostile package that impersonates a real one or a private internal name. A compromised build system injects malicious code during the build, so even clean source produces a poisoned artifact. And stolen signing keys or credentials let an attacker distribute malware that appears legitimately signed.
Notice that only the first of these is about a vulnerability in your code. The rest are about trust in things around it. That is why traditional appsec, focused on your source, is necessary but not sufficient.
Know what you depend on
You cannot defend what you cannot see, and most teams cannot see their full dependency tree. Direct dependencies are visible in a manifest. The transitive ones, the dependencies of your dependencies, are where the depth and the danger live, because a package you never chose can end up in your build several levels down.
The foundation is a software bill of materials (SBOM), a complete inventory of every component in your software, direct and transitive, with versions. Generate one automatically as part of your build so it stays current, and store it so you can answer, in minutes rather than days, "are we affected by the thing that just got disclosed?" When the next widely used library turns out to be compromised, the teams that recover fast are the ones who already had an SBOM and could query it. An SCA tool such as Safeguard builds this inventory and continuously checks it against vulnerability data, including the transitive components that manual review never reaches.
Manage dependencies deliberately
With visibility in place, tighten how dependencies enter and stay in your project:
- Lock versions. Use lockfiles (
package-lock.json,poetry.lock,go.sum) so builds are reproducible and a dependency cannot silently change under you. Pin, then update on purpose. - Verify integrity. Lockfiles with hashes ensure the package you resolve is byte-for-byte the one you reviewed. A changed hash is a signal to stop.
- Defend against confusion. Configure your package manager to prefer your private registry for internal names and scope private packages, so an attacker cannot publish a public package that shadows a private one.
- Vet before adding. Before pulling in a new dependency, look at its maintenance, its own dependency count, and its track record. Every package you add is trust you extend to its maintainers and everyone who can publish to it.
- Prune. Remove dependencies you no longer use. Unused code is still attack surface.
Lock down the build pipeline
The build system is high-value real estate: it has access to source, secrets, and the ability to sign and ship. Treat it like production.
Apply least privilege to CI/CD, so a build job can reach only what it needs and no more. Keep secrets in a proper secrets manager injected at runtime, never in the repo or the pipeline config. Pin your build tooling and CI actions to specific versions or digests rather than mutable tags, so an updated action cannot change behavior without your knowing. Where you can, use ephemeral, isolated build environments that start clean each run, so a compromise cannot persist across builds. And log build activity so tampering leaves a trail.
The SLSA framework is a useful reference here: it defines levels of build integrity, and even reaching its lower levels, reproducible builds and tamper-evident provenance, meaningfully raises the bar.
Verify provenance and sign artifacts
The final defense is proving that what you ship is what you built. Sign your artifacts, container images, packages, releases, and verify signatures at every consumption point, including at deployment admission. Generate provenance attestations that record how and where an artifact was built, and check them before you run it. Tooling like Sigstore has made signing and verification practical without running your own key infrastructure.
The point of provenance is to break the attacker's ability to substitute a malicious artifact for a legitimate one somewhere between your build and your users.
Put it together as continuous practice
None of these controls is one-and-done. A component that was clean yesterday can have a critical vulnerability disclosed today, and a build system that was locked down last quarter drifts. The working model looks like this:
add dependency -> vet, pin, verify hash
build -> isolated pipeline, least privilege, generate SBOM
release -> sign artifact, attach provenance
deploy -> verify signature + provenance at admission
always -> re-scan SBOM against new advisories, alert on hits
The reason to automate all of it is that supply chain risk is continuous and high-volume, exactly the profile where manual process fails. If you want a structured path through these controls with examples, the Academy works through them, and understanding how SCA fits is the natural starting point.
FAQ
What is the single most important step to mitigate supply chain attacks?
Visibility, delivered through a software bill of materials. You cannot manage risk in components you cannot see, and transitive dependencies, where much of the danger hides, are invisible without one. An accurate, continuously updated SBOM is the foundation every other control builds on.
How do I defend against dependency confusion?
Configure your package manager to prefer your private registry for internal package names, scope private packages, and verify that public packages cannot shadow private ones. This stops tooling from resolving a hostile public package that impersonates an internal name.
Are signed artifacts enough on their own?
No. Signing proves an artifact came from you and was not tampered with in transit, but it does not prove the code inside is free of a compromised dependency or a poisoned build step. Combine signing and provenance verification with dependency management and build-pipeline hardening.
How often should I re-check my dependencies?
Continuously. New vulnerabilities are disclosed daily, so a component that was safe when you added it can become risky at any time. Automate re-scanning of your SBOM against current advisories and alert on new matches rather than checking on a manual schedule.