Dependency Audits Without Slowing Down Releases
The standard advice on software supply chain security — review every new dependency before it merges — assumes a review capacity most teams don’t have. Applied literally, it either gets ignored under deadline pressure or becomes a bottleneck that developers route around by vendoring code instead of adding a package. Neither outcome improves security.
Tier dependencies by blast radius, not by novelty
Not every dependency deserves the same scrutiny. A left-pad-style utility with no filesystem or network access carries a different risk profile than a package that touches auth tokens, makes outbound requests, or runs a postinstall script. Build a simple tiering rule — anything with install scripts, network access, or crypto/auth involvement gets manual review; everything else gets automated scanning only — and most of your review capacity goes where it actually matters.
Automate the boring 80%
Automated tooling (SCA scanners, lockfile diffing, typosquat detection) should catch known-bad packages, suspicious version jumps, and newly-added transitive dependencies without a human in the loop. Wire this into CI as a blocking check for the high-risk tier only — for everything else, let it flag and log rather than block, so it doesn’t become the thing engineers learn to bypass.
Audit on update, not just on add
Most supply-chain incidents involve a package that was fine when it was added and got compromised later — through a maintainer account takeover or a malicious version bump. A one-time review at add-time misses this entirely. Add a lightweight second check specifically for version bumps in your high-risk tier: does the diff match what the changelog claims, and did maintainership change hands recently? This catches the incident pattern that’s actually been showing up in real breach reports, which add-time review structurally can’t.