Software Supply Chain Attack: How to Prevent One

A software supply chain attack happens when an adversary compromises something you depend on, such as a library, a build tool or a vendor, instead of attacking you directly. You prevent one by knowing exactly what you depend on, vetting new packages, locking versions, hardening your build, and watching for change.

Key takeaways

• Attackers target what you trust, so the defense starts with an inventory of everything you pull in.
• Most prevention is cheap habit: lockfiles, review of new dependencies, and disabled install scripts.
• Your build pipeline is part of the supply chain, so protect its credentials as carefully as production.
• You cannot stop every attack, so plan for fast detection and a rehearsed response.

What is a software supply chain attack?

It is an attack on the products and services your software relies on, rather than on your own code. NIST's glossary, citing CNSSI 4009, defines a supply chain attack as "an incident where an adversary exploits vulnerabilities in the product or service supply network of the intended target."

The glossary adds that attacks can happen at any stage of a system's life and may aim to steal or alter data, disrupt operations, or set up later access. For a software team, the supply network includes open source packages, container base images, CI services, build plugins, and vendors with access to your systems.

Where do these attacks actually enter?

They enter wherever your software accepts something you did not write. Four entry points cover most of what teams face:

• Dependencies. A malicious package, a hijacked maintainer account, or a lookalike name. Install-time scripts run before anyone reads the code.
• Build and CI. Stolen pipeline tokens, unpinned actions, or a tampered build step that changes the artifact after review.
• Artifacts and images. A base image or binary that is not what its name suggests.
• Vendors and updates. A trusted supplier ships a compromised update through the normal channel.

Each one has a different control, which is why a single scanner is not a full answer.

How do I prevent a software supply chain attack?

Work through the controls in this order, because each step makes the next one easier.

1. Build an inventory. List every direct and transitive dependency with versions. You can scan a dependency file for free in the browser at gold.safeguard.sh/scan. It needs no login, the file stays on your machine, and it covers up to 100 dependencies.
2. Commit lockfiles and install from them. npm ci installs exactly what the lockfile records, so a new malicious release cannot slip in on its own.
3. Vet new dependencies before adding them. Check the name, the publisher, the release history and the install scripts. Our guide on how to check if an npm package is safe walks through it.
4. Turn off install scripts by default. In npm, the ignore-scripts setting is false by default, so you have to set it. Allow scripts only for packages that need native compilation.
5. Verify provenance where it exists. npm audit signatures checks registry signatures and provenance attestations of downloaded packages.
6. Harden the pipeline. Give CI jobs the minimum token permissions, pin third party actions to a full commit, and keep secrets out of build logs.
7. Generate an SBOM for every release. An inventory tied to each build is what lets you answer "are we affected?" in minutes. See how to create an SBOM step by step.
8. Monitor continuously. New advisories and newly flagged malicious packages arrive after you ship, so recheck your inventory on a schedule.

Does provenance mean a package is safe?

No. The npm documentation says provenance "does not mean a package is free of malicious code." It gives you a verifiable link between a package, its source and its build instructions, so you can audit them and decide whether to trust it.

Treat provenance as one signal. A package with provenance from an unfamiliar publisher still deserves the checks in step 3.

How do I know if a vulnerable or malicious package is already in my project?

Match your inventory against known advisories and known malicious packages. The npm CLI's npm audit sends package names and versions to the registry and reports known vulnerabilities, but it is a database check. A brand new malicious package has no advisory yet, so combine it with behavior checks such as reviewing install scripts.

The Gold registry lists packages with their CVEs, CISA KEV status and malicious package flags, which helps you see whether something you already use has been called out.

A prevention checklist you can apply today

Use this as a pass or fail list for one repository.

• Lockfile committed and CI uses a locked install command
• Install scripts disabled by default
• No dependency added without a named reviewer
• CI tokens scoped to the least access needed
• Third party actions and base images pinned
• SBOM produced on every release
• Someone owns the response when an advisory lands

If you fail more than two, start at the top of the list.

Frequently asked questions

Sources

• NIST CSRC glossary: supply chain attack
• npm Docs: npm audit
• npm Docs: generating provenance statements
• npm Docs: reporting malware in an npm package
• Safeguard Gold dependency scan

Last reviewed: 19 October 2026.