Malicious Packages
Keep malicious packages out of your builds and off developer laptops. Malware, hijacked releases, install scripts and look-alike names are each caught by a rule that runs before the install. Dependency Firewall also shows who installed a version that was flagged later.
A malicious release is live before anyone has flagged it
A malicious version is often live on the public registry for hours before a feed flags it. A build that resolves it in that time installs it like any other version.
- Maintainer accounts get taken over
- A stolen token is used to publish a new patch version of a package you already depend on. A caret range in package.json picks it up on the next fresh install.
- Malware rarely gets a CVE
- A malicious package is not a vulnerability, so it usually has no CVE and no CVSS score. It is reported as a malware advisory, often hours or days after it was published. A check that matches on CVEs does not flag it.
- Malicious code runs with the developer's access
- It runs when the package is imported or built, and during the install where scripts are allowed. It can read tokens, SSH keys and cloud credentials on that machine.
- Scanners read the lockfile afterwards
- SCA tools report the package after the install. By then it is on the machine and may already have run.
What stops a malicious package
A malicious version is unknown when it is published and reported hours or days later. Each stage has its own rule.
Hold a release nobody has reported yet
Release delayBlock a version with a malware finding
Malware blockingApply both rules to every team and agent
Centralize firewall rulesScan every layer of a container image
Container firewalling
- Install scripts
- A separate rule blocks packages that run code during the install, such as an npm postinstall script.
- Trust downgrades
- On npm, a release published with weaker provenance than the version before it is flagged.
- Publish scanning
- Packages you publish through the firewall are scanned for malware and secrets before they reach an upstream registry.
- Dependency confusion
- A public package under one of your internal names is never served, whatever its version number.
Only the registry URL changes for each package manager. Nothing is installed on developer machines.Supported ecosystems
Every block has a record
Open a blocked request to see what was asked for, by whom and from which upstream. The rule that matched is listed below it. If the block was wrong, add an exception from the same view.
Find who pulled a package before it was flagged
Observations record the first and last time each package version passed through a firewall. When a version you already served turns out to be malicious, search for it and see which firewalls downloaded it and when.
Who works with it
- Security teams
- Put malware and delay rules on a baseline firewall that team firewalls cannot weaken. When a version is flagged later, Observations show which firewalls served it.
- Developers
- Keep using npm, pip and mvn. A blocked version fails the install, and the log says which rule stopped it.
- Platform engineers
- Change one registry URL per runner image or developer setup. Nothing to install on laptops.
Questions
Which rules should we start with?
A release delay and the malware rule at known malware. The delay holds every new version while findings catch up, and the malware rule blocks what is already known.
Does vulnerability blocking cover malware?
No. Vulnerability rules act on CVEs with a CVSS or EPSS score, and a malicious package usually has no CVE. The malware rule covers it at the effort you choose, from known malware signatures to a deep scan of the package content. A release delay holds the versions nobody has reported yet.
What if malware is found in a package we already installed?
Observations track the first-seen and last-seen date of every package version and which firewalls it passed through. Search for the package to see more details.
Are the packages we publish checked too?
Yes, when you publish through the firewall. Add the malware rule for uploads, and what you ship is held to the standard of what you install.
More Dependency Firewall use cases
All use cases- Vulnerable DependenciesStop packages with known CVEs at the firewall before they land in a build.
- CI/CD Pipeline ProtectionRoute CI/CD pipelines through Dependency Firewall and enforce the same rules on every build.
- AI Coding AgentsCheck every install an agent makes against the rules your security team sets.
Try it on one registry
Point one package manager at Dependency Firewall and check the log after the next install. The trial runs 14 days.