The registry is no longer a trust zone
If you build an AI-powered SaaS today, your codebase carries hundreds or thousands of transitive dependencies you have never read. Every npm install pulls code from strangers and runs it with the same permissions as your build. In 2026, that stopped being a theoretical risk.
Sonatype's 2026 State of the Software Supply Chain report counted more than 454,600 new malicious open-source packages published in 2025 alone. The cumulative total of blocked malicious packages crossed 1.233 million, a 75% jump year over year. This is not background noise. It is an industrial production line for malware pointed straight into your pipeline.
The practical takeaway is blunt and simple: "trust the registry" was never a security strategy. It was a bet that worked while attack volume stayed low. That time is over.
What 2026 showed in practice
The numbers only land when you see the mechanics. Three patterns dominated the year.
axios as a RAT delivery vehicle
Packages impersonating axios (or trojanized versions mimicking the legitimate behavior) were used to deliver a Remote Access Trojan. The developer installs what looks like a plain HTTP client and gets a remote control channel on the dev machine or CI runner as a bonus.
Typosquats stealing CI/CD secrets
Packages with names almost identical to the real ones, one character swapped, one extra hyphen, were published to steal cloud credentials and CI/CD tokens. Microsoft documented typosquat campaigns on npm targeting exactly the secrets that sit exposed as environment variables inside the pipeline. All the package has to do is run a postinstall and read process.env.
Dependency confusion profiling dev environments
Attackers published public packages with the same name as private internal ones. The resolver pulls the higher public version, it executes, and starts profiling the dev environment: variables, internal network, project layout. That is reconnaissance before the real hit.
All three share one denominator: untrusted code executing with your build's permissions.
8 concrete actions, ordered by impact
A generic checklist helps no one. This is what a small AI SaaS team should actually do, prioritized by return on effort.
1. Lock the lockfile and use `npm ci` (today)
Start with the cheapest win. Use npm ci instead of npm install in CI and any reproducible environment. npm ci installs exactly what is in package-lock.json, with integrity verification (the sha512 hash of each tarball). If the tarball in the registry does not match the lockfile hash, the install fails. That kills silent republish-rewrite attacks. Without a committed lockfile and integrity, everything else loses its floor.
2. Dependency scanner in CI, blocking (this week)
Add a scanner that runs on every PR and fails the build on a known vulnerability or a package flagged as malicious. OSV-Scanner (backed by the open OSV database) is a direct, free starting point. The critical part: the scan must be blocking, not a report nobody reads. An alert that does not stop the merge is just noise.
3. Version cooldown and allowlist (this month)
Most malicious packages get caught and pulled within hours or days. A cooldown window, adopting no version published in the last 7 to 14 days, removes a huge slice of the risk at no real security cost. Pair it with an allowlist for sensitive dependencies: only explicitly approved versions get in. npm with a minimum-age policy already helps here.
4. Mandatory review for new dependencies (ongoing)
Adding a dependency is an architecture decision, not an npm install in the middle of a commit. Every new dependency (and every major bump) goes through human review: who maintains it, how many downloads, does it have a postinstall, what is the surface. A senior dev looking for 30 seconds catches what the automated scanner misses.
5. Keep secrets out of the build environment (this month)
The typosquat and dependency confusion attacks of 2026 targeted exactly process.env in CI. If the secret is not there, the malicious postinstall steals nothing. Get long-lived credentials out of your pipeline environment variables. Use a secrets manager with short-lived credentials, OIDC injection for cloud, and minimal scope per job. A secret that does not exist on the runner cannot leak.
6. Disable lifecycle scripts by default (this month)
Much of the payload runs in postinstall. Install with --ignore-scripts by default and enable scripts only for the few packages that genuinely need them (via an explicit allowlist). That cuts off the most common execution path for supply chain malware.
7. Generate and keep an SBOM (this quarter)
An SBOM (Software Bill of Materials, in CycloneDX or SPDX) is the inventory of what actually landed in your artifact. Without it, when the next critical CVE hits a transitive dependency, you do not know whether you are exposed or where. Generate the SBOM at build time, version it alongside the artifact, and use it to answer "do I use this package?" in minutes, not a day of hunting.
8. Provenance and signing on your releases (this quarter)
If you publish packages or images, sign them. Provenance (npm provenance via Sigstore, or signed artifacts) proves the artifact came out of your pipeline and was not swapped in transit. It is the other side of the coin: you do not want to be the next trojanized axios poisoning your own customers.
Where RET fits
Actions 1 through 6 you can start today with open tooling and process discipline. The ongoing work, scanning every change, cross-referencing vulnerability databases and malicious-package signals, separating a real finding from a false positive, is the tiring part and the one most teams let slide. AuditMySaaS's dependency scanner exists to take that weight off your CI and hand back only what matters: what is real, what is exploitable, and what to do. Good defense is the kind that keeps running after the enthusiasm fades.
Trusting the registry was never a security strategy, it was a bet that 2026's volume finally broke.
