Supply chain package compromises follow a familiar playbook: an attacker gains access to a maintainer account or build system, pushes a malicious update, and waits for downstream projects to pull it. The window between compromise and detection is typically hours to days. That's enough.
March 2026 brought fresh examples:
TeamPCP / Trivy-action: Attackers force-pushed 75 of 76 trivy-action version tags, exfiltrating secrets from every pipeline that ran a Trivy scan. Stolen credentials cascaded into PyPI compromises including LiteLLM (120k weekly installs).
Axios: Malicious versions 1.14.1 and 0.30.4 lived for approximately three hours, which was long enough for real impact given the 100 million monthly downloads.
In our GitHub Actions primer we cover risks in your GitHub CI/CD, which you can address via our Hardening Guide. This post offers another complement, highlighting the defensive landscape for your use of third-party packages, regardless of where you consume them.
We'll use npm to make examples concrete, but the principles this post explores apply across ecosystems. Package management has conflicting goals: security wants lockdown, developer experience wants flexibility, maintainer sustainability wants minimal friction. These tensions aren't solvable, but the threat landscape calls for us to rebalance and make informed trade-offs.
Easy(ier) Wins for Package Security
These mitigations are individually actionable and generally high-leverage.
Minimize First
The current supply chain threat landscape and the capabilities of AI for code generation start to tilt the math on consuming third party packages. Avoid taking dependencies on simple modules such as left-pad. Custom reimplementation or forks may make sense, especially if the modules aren't doing high-risk functionality or are stable. The goal should be a shallow dependency graph, given how risk propagates via transitive dependencies.
Adopt Cooldowns
Most malicious packages are discovered and removed within days, if not hours. Waiting to install package updates lets the ecosystem's eventually consistent detection and removal mechanisms work before you're exposed. Tools like Renovate, Dependabot, pnpm, and uv all allow configurable delays. However, a challenging trade-off in implementing cooldowns is figuring out the right process to ensure you're consuming security patches promptly, especially as the time for attackers to generate exploits from patches shrinks. It's worth figuring out the right tradeoff however, given how a seven day cooldown would have prevented 90+% of recent attacks!
Lockfiles & Hashes
Lockfiles pin exact versions, while hashes verify contents. Depending on the ecosystem, various references (like tag versions) are mutable. In npm, npm install can actually modify the lockfile, which is why CI should use npm ci. Transitive dependencies are a concern here as well; neither lockfiles nor hashes ensure downstream dependency control (in the most common ecosystems). Lockfile adoption depends on the ecosystem, Go drives 99.7% adoptions through safe defaults, while npm adoption hovers around 50%.
Wrapper Tools
There are a dozen different tools that offer to wrap your npm CLI and add security, scanning for known malware, suspicious behavior, and supply chain risk signals. These tools can add resilience, but often have more limitations than they market. For example, many such tools rely on OSSF malware data for prevention, which is a lagging indicator of malware. A net-new malicious package won't be flagged until someone detects it. Cooldowns remain complementary, because they give these tools a longer lead time to detect malware. An example is DataDog's supply-chain-firewall.
Restricting Install-Time Execution
Commodity malware often targets install-time execution because it requires no user interaction beyond npm install. Disabling install scripts cuts off this common attack vector. pnpm offers granular control, while npm offers ignore-scripts. However, a blanket denial will break packages that legitimately need install scripts. Rollout requires an incremental approach. You can disable by default and allowlist the exceptions.
Organizational Controls
The previous mitigations work at the individual level, but can be rolled out across your estate. Organizations with more resources can add controls at the infrastructure layer. These fall into two categories: controls that protect the environments where code executes, and controls that govern what packages enter those environments.
Protecting the Execution Environment
Remote Developer Environments
Cloud development environments move code execution off developer laptops and into sandboxed, ephemeral infrastructure. For package security, this means malicious install scripts or import-time code executes in an isolated environment rather than on a machine with access to local credentials, SSH keys, and cloud configs. Secrets stay centralized rather than scattered across laptops. Security teams can deploy production-grade sensors and build in cloud guardrails. The case for Cloud Development Environments (CDEs) has strengthened as AI coding agents proliferate, because agents and ~/.aws don't mix.
Zero Trust Production
Zero trust production is a philosophy pioneered at Google: every change in production must be made by automation, prevalidated by software, or made via an audited break-glass mechanism. If developers don't have ephemeral credentials to production systems, malware running install scripts on their machines doesn't either. This can complement or serve as an alternative mitigation to remote developer environments. Both approaches reduce what an attacker gains from compromising a developer's machine. How do you get there? Check out my talk: The Path to Zero Touch Production.
Secure, Enterprise, or Remote Browsers
Enterprise and remote browsers, like Chrome Enterprise, isolate web activity from the local machine. A major risk both upstream and downstream of the recent supply chain attacks lies in session hijacking and cookie theft, which these tools are directly positioned against. There are a range of isolation levels available depending on the balance of usability, cost, and control desired for your organization.
Controlling What Gets Installed
The previous controls limit blast radius, controlling what an attacker gains if malicious code executes. The following options address what packages reach your environment in the first place.
Registry Pull-Through Proxies
A pull-through proxy sits between developers and the public registry, forwarding requests while providing visibility and a choke point for policy. You get an audit trail of what's being installed, caching for availability, and a single place to enforce allow/block lists. Most artifact repository tools (Artifactory, Nexus, CodeArtifact) support this mode. Anthropic's Dependant is an example of an admission controller approach, intercepting package requests and enforcing policy before installation.
Curated Registries
The same tools, configured differently: only pre-approved packages are available. Nothing from public registries reaches production without explicit review. This is high-friction but effective for critical paths. The trade-off is maintenance burden: someone has to approve packages and keep the curated set updated. You can build in balance through judicious pre-approvals based on package attributes (age, popularity, usage of trusted publishing, etc).
The Progression
Often, you can start with a proxy for visibility, understanding what's being installed before trying to control it. From there, graduate to curated registries for critical paths (production services, CI infrastructure) while allowing more flexibility for internal tooling and experimentation.
When Prevention Fails
Ultimately, the goal is to reduce exposure and avoid malware ever executing. But there are no perfect systems, and so detection should be considered to catch, with high signal, anything that slips through your controls.
Honeytokens are one strong answer: honeytokens work because attackers are focused on stealing credentials. Plant fake credentials in CI environment variables and if they're used, you know something extracted them. Grafana showed the value in this approach: when a compromised GitHub Action exfiltrated secrets, an AWS API key canary triggered on the attacker's validation call, revealing the entry point within minutes. CI/CD and source control are high-leverage deployment points for canaries. They sit on the paths supply chain attacks traverse.
Where this leaves us
As you've seen in this guide: we know the controls that can help reduce the risk of malicious packages. Cooldowns alone would have avoided exposure to most of the recent incidents. Disabling install scripts blocks commodity malware. Lockfiles with hashes prevent silent substitution. Canaries catch what prevention misses. These are practical, scalable approaches increasingly deployed in enterprises.
However, gaps remain. Open-source is a social trust problem: maintainers do their best, but aren't resourced or contractually obligated to provide supply chain security to their largest enterprise adopters. The asymmetry cuts both ways: takedowns are getting faster, but AI lowers the bar for attackers to scale exploitation. Your goal doesn't need to be perfect security. Raise the cost of attack, shrink your exposure window, limit blast radius, and preserve velocity. Practical package security: informed trade-offs, not perfection.
