Open-Source Supply-Chain Attacks Are Now a When, Not an If
Compromised npm and PyPI packages have made their way into CI pipelines across multiple industries this quarter. Here's what we're seeing in the field, and the controls that actually stop it before it reaches production.
What's happening
Over the last few months, several widely-used open-source packages on npm and PyPI were found carrying malicious post-install scripts. These are typically added either by compromising a maintainer's account or by publishing a typosquatted package with a name close enough to a popular dependency to get picked up by an automated install.
The payloads we've examined have followed a familiar pattern: harvest environment variables and CI secrets, exfiltrate them to an external endpoint, and, in a few cases, attempt to plant a secondary backdoor inside the build artifact itself. Because the malicious code runs during install or build, it executes with whatever access your CI runner has, often including cloud credentials, registry tokens and signing keys.
Why it matters for your organization
Most teams trust their dependency tree implicitly: a single npm install or pip install -r requirements.txt can pull in hundreds of transitive packages, almost none of which anyone on the team has reviewed. A single compromised package, even a low-level transitive dependency, has the same blast radius as a compromised build server.
The organizations that got hit hardest weren't running outdated software; they were running auto-updating dependencies with no pinning, no lockfile verification, and CI runners with broad, long-lived credentials. That combination turns a single upstream compromise into an organization-wide incident within minutes of the next build.
Aditya Thakur
DevSecOps Engineer, CipherTrivia
"CipherTrivia's Take"
"Every audit we run still finds the same gap: dependency updates are automatic, but dependency review isn't. Lockfiles get committed, sure, but few teams actually verify them against a known-good hash before a build runs, and almost none scope their CI credentials so a compromised package can't reach anything sensitive. The fix isn't exotic. It's pinning, provenance checks, and a CI runner that has no more access than the job strictly needs."
What to do now
A practical checklist we're walking clients through this month:
- Pin dependency versions and commit lockfiles, and fail builds if the lockfile doesn't match installed versions.
- Run a software composition analysis (SCA) scan on every PR, not just on release branches.
- Scope CI/CD credentials to least privilege: short-lived tokens, per-job permissions, no standing cloud admin access.
- Use a private registry mirror/proxy so new package versions are quarantined before they reach your builds.
- Generate and verify build provenance (e.g. SLSA-style attestations) for production artifacts.
Not sure if your CI pipeline is exposed?
We can review your build pipeline's dependency and credential exposure in a single session.
Schedule a Meet