Supply chain attacks go unnoticed because they travel through channels people trust and rarely inspect: automatic updates, valid publisher accounts and ordinary release notes. Nothing looks like an intrusion until someone compares behavior to a baseline. The gap closes with diffs, delays and monitoring.
Four blind spots
- Nobody reads the update. A dependency range or an update bot accepts a new version, tests pass, and the change merges. Tests check your behavior, not the dependency's.
- The account is valid. A takeover uses real credentials, so access logs show a normal login.
- The artifact is not the source. Reviewers read the repository. The SLSA project's examples include packages that did not match the source repository, so a clean repository does not prove a clean release.
- Transitive packages are invisible. Most projects pull in many indirect dependencies that nobody chose by name.
Why speed still helps
Pnpm's documentation says registries usually remove compromised versions within hours and that malware is usually detected quickly. That is the logic behind a short waiting period: you skip the window where a bad version is live but unflagged. It is not a guarantee, and it does not help with a poisoned version that stays quiet for a long time.
What closes each blind spot
| Blind spot | Control |
|---|---|
| Unread updates | Review dependency diffs in the pull request, including install scripts |
| Valid account abuse | Two-factor authentication, short-lived tokens, alerts on new publishers |
| Artifact differs from source | Provenance where available, rebuild checks for critical packages |
| Hidden transitive packages | A full inventory (SBOM) with continuous monitoring |
Signals worth alerting on
Pick a few cheap ones and watch them.
- A package gains an install script it did not have before.
- A new maintainer or publisher appears on a package you use.
- A release appears with no matching tag or changelog.
- A dependency makes new outbound network calls in your build.
- A version is published, then removed within a day.
A simple weekly habit
Once a week, list the dependencies that changed in your lockfiles, and skim the biggest changes. A ten minute habit finds more than a yearly review. GitHub's dependency review shows added, removed and updated dependencies with release dates in a pull request, which makes this easier. See our guide to setting up dependency review.
Where Safeguard fits
Safeguard's continuous monitoring and zero-day discovery are built to catch changes after a scan has passed, and reachability analysis helps you decide which findings need action first.
Quick check
Do passing tests mean an update is safe?
No. Tests exercise your code. A malicious dependency may behave normally under test and act only in production or on a build machine.
Is waiting for new versions enough?
It helps with fast-detected malware, but pair it with review and monitoring.
Sources
Last reviewed: 19 October 2026.
