Software supply chain risk
How to Prevent Supply Chain Attacks
Updated 5 Oct 2026
Nine controls reduce the risk of a supply chain attack and limit the harm when one gets through. They cover your build steps, your publishing steps and the computers where your team vibe codes.
An attacker hides one bad change inside a normal update. The rest of the update is genuine, so a list of changed files tells you nothing. For the basics, read what a supply chain attack is.
How to defend against supply chain attacks
Use all nine controls below, because each one covers a different way in.
- 1
Pin GitHub Actions to commit SHAs
A tag can move. A full commit SHA cannot.
- 2
Use trusted publishing
Replace long-lived publish tokens with short-lived credentials.
- 3
Lock package versions
Commit a lockfile and install from it. Read each update before you accept it.
- 4
Turn off install scripts you do not need
Set
ignore-scriptsto true in npm. - 5
Protect the build server and the developer computer
Give each one the fewest secrets it needs.
- 6
Scan the packages your developers pull
A registry scanner blocks a bad package at the pull request. See software supply chain security tools.
- 7
Sign and verify your own releases
Signing lets customers check who built a file.
- 8
Check what an update can do before it runs
Compare the version you trust with the new one.
- 9
Watch the installs on each computer
AI tools add packages all day, so a watcher must run on every one.
No control is complete alone. A signature proves who built a file, and a clean builder is a separate question.
Pin GitHub Actions to commit SHAs
Pin every GitHub Action to a full-length commit SHA, because a tag can be moved to different code. GitHub's documentation says that pinning to a full-length commit SHA is currently the only way to use an action as an immutable release.
Review the pinned commit before you update it.
Without a pin
Unit 42 reports what happens without a pin. In March 2025 an attacker pushed new tags to tj-actions/changed-files so that all of them pointed at the malicious commit. A workflow that used a version tag ran the bad code. See the tj-actions record.
Use trusted publishing, not long-lived tokens
Publish packages with trusted publishing, because a long-lived token can be stolen and reused. The npm documentation says that trusted publishing uses OpenID Connect from your CI workflow and removes the risk of long-lived write tokens. PyPI documents the same method.
Huntress reports that the axios attacker skipped the normal OIDC publishing workflow and published with a long-lived access token. See the axios record.
Trusted publishing is not a full fix. The TanStack postmortem describes malicious versions that went out through a trusted publisher binding, after the attacker abused the build workflow. So protect the workflow as well. See npm supply chain attacks.
Protect the build server and the developer machine
Treat the build server and the developer machine as targets, because the payloads in recent attacks went for the secrets on them. Give each machine only the secrets that its job needs.
Keep secrets out of workflows that run code from forks. Rotate every secret that a poisoned version can reach.
The Nx attack shows why
StepSecurity reports that a postinstall script read GitHub tokens, npm credentials and SSH keys. See the Nx record. The CISA developer guide also covers the security of the environments that build software.
Check what an update can do before it runs
Check each update by comparing it with the version you trust. A power is something a file can do, such as reach the internet or run a program. Vigilance needs no reputation score and no name for the attack. It asks one question. Can the new package version do something that the version before it did not?
Vigilance checks each new package version on our service. On a paid plan it swaps a bad update for the last safe version on its own. It holds unsure findings and reports them.
You do two things
Start the free 14-day trial. Then install Vigilance on each computer where your team vibe codes. It watches the installs that Claude Code, Cursor, Codex, GitHub Copilot, Devin Desktop and Gemini CLI make, and the installs a person types, through npm, pnpm, yarn, bun, pip and uv.
A registry scanner and Vigilance side by side
The two tools do different jobs. A registry scanner guards the packages your developers pull. Vigilance guards the computers where AI tools and your staff add packages.
| Question | A registry scanner | Vigilance |
|---|---|---|
| Checks a public npm or PyPI package | Yes | Yes |
| Blocks a bad package at the pull request | Yes | No |
| Watches the installs that AI tools make on each computer | No | Yes |
| Swaps a bad update for the last safe version | No | Yes, on a paid plan |
| Needs the attack to be known first | For some of its checks | No |
For owners and IT providers
Watch the installs on every computer
Your people use AI tools that add packages without a review. Three parts of Vigilance are for the person who pays for those tools.
One signed installer per computer
It runs on Mac, Windows and Linux. An IT provider can set it up for a client company with the join code from the watch.
You see every outside package
Each package that lands on your people's computers is listed, so you know what your team runs.
A bad update is swapped
On a paid plan, Vigilance swaps an update that newly gains a harmful power for the last safe version. Nobody approves each swap.
CISA guidance
CISA publishes guidance for each side of the problem. Start with Securing the Software Supply Chain: Recommended Practices for Developers.
Read the developer guide for your build and publish steps. Read the customer guide when you buy and install software from others.
CISA published this guide on 1 September 2022. It is the first of a three-part series from the Enduring Security Framework, a working group that the NSA and CISA lead. It covers security requirements planning, secure software architecture, security features, and the security of the software and its environments. Parts for suppliers and for customers followed.
Five attacks
Attacks that arrived by a route other than a public package install.
Five attacks that arrived with no public package install
- SolarWinds, 2020
- A vendor's build system
- Codecov, 2021
- An altered build script
- 3CX, 2023
- A signed vendor installer
- xz-utils, 2024
- A release archive
- polyfill.io, 2024
- A browser script tag
No developer typed npm install for any of these five. A tool that reads only the public registry sees none of them. Pin, sign and verify what you publish and buy to cover these routes.
Sources: CISA advisory AA20-352A, Codecov post-mortem, 3CX and Mandiant, the xz-utils disclosure, Sansec on polyfill.io.
Five attacks and how each one reached a company
| The attack | How it arrived | Who installed it |
|---|---|---|
| SolarWinds, 2020 | A network monitoring update, signed by the real vendor (Mandiant), that carried a backdoor in one library file. The attackers changed the code inside the vendor's own build system. CISA ordered every federal agency to disconnect the product. | IT, at government agencies and large companies |
| Codecov, 2021 | An altered upload script that ran inside build pipelines for two months. It sent the passwords and keys held in the pipeline to the attacker. | A build engineer |
| 3CX, 2023 | A desk-phone update, signed by the real vendor (BleepingComputer), that carried a backdoor. The vendor's own build server produced it. | IT, at 600,000 companies |
| xz-utils, 2024 | A backdoor hidden in the release archive of a compression library, which Linux links into remote login. One researcher found it days before it reached a stable release. | Linux vendors, in test builds |
| polyfill.io, 2024 | One script tag on more than 100,000 websites. The domain changed owner, and the new owner served malware from the same address. | A web team, years earlier |
FAQ
What is a software supply chain attack?
An attacker changes software you already trust. Then you install it yourself. The real vendor signs the update, and it arrives from your normal source. The payload is one file, or one line in one file.
Is Vigilance a package scanner?
No. A package scanner matches packages against lists of known flaws. Vigilance checks each new package version for a newly gained harmful power, before any list knows about it.
Do I need a registry scanner as well?
If your developers pull public packages, a registry scanner blocks a bad package at the pull request. Vigilance does not. It swaps a bad update for the last safe version on the computer.
Does it need an account or the internet?
Each computer needs an internet connection, because we check each new package version on our service. The free 14-day trial needs a card on file and charges nothing until you say yes.
Who sets it up, IT or the developers?
Either. You start the free trial and install Vigilance on each computer. An IT provider can set it up for a client company. See the setup page.
What does Vigilance leave to other tools?
Vigilance leaves known flaws to a CVE scanner and scores no package by popularity. It reports the update that newly gains a harmful power.
Check your next update.
Vigilance watches the packages that AI tools and your staff add to each computer. On a paid plan it swaps a bad update for the last safe version.