The Package Firewall is a policy proxy in front of 25 package registries. From the VDB console you set the thresholds, order your upstream mirrors, and review a full decision log of every package that passed, was blocked, or errored.
Security policies you control
Block by vulnerability severity
Every dependency request is checked against the Vulnetix VDB for known CVEs. If the highest CVSS v3 score on any CVE for that exact version meets or exceeds your threshold, the download is blocked before it reaches your machine.
Block by exploitation probability
EPSS, the Exploit Prediction Scoring System, measures how likely a vulnerability is to be exploited in the wild within the next 30 days. A CVE with CVSS 7.5 and EPSS 0.97 is more dangerous than one with CVSS 10.0 and EPSS 0.01. Scores update daily from FIRST.org.
Block by exploit availability probability
Coalition ESS reports Exploit Availability Probability: the likelihood that working exploit code becomes publicly available for threat actors to reuse. It answers whether an exploit is likely to be easy to find and operationalise, not just how severe the CVE is.
Block known malicious packages
blockMalware rejects any dependency flagged as a known malicious package before the module metadata even downloads. The VDB aggregates malware intelligence from OSSF Malicious Packages, OSV.dev malware advisories, and researcher-submitted samples, de-duplicated against a single corpus.
Block end-of-life dependencies
End-of-life packages accumulate unpatched CVEs: their maintainers have stopped issuing security fixes, so any new vulnerability becomes a permanent exposure. blockEol prevents teams from introducing EOL dependencies before they become a liability.
Block CISA Known Exploited Vulnerabilities
CISA KEV inclusion isn't a prediction, it's confirmation: these vulnerabilities are being actively exploited right now. US federal agencies must patch within 2–3 weeks of KEV listing; blockKev applies that same standard to your dependency pipeline automatically.
Block weaponized exploits
A weaponized exploit is attack code that is mature, reliable, and ready for adversarial use, no expertise required. Honeypot intelligence tracks when PoC code graduates from a researcher's lab to an operational weapon, the kind that powers ransomware and mass exploitation.
Block actively exploited vulnerabilities
blockActive blocks dependencies with confirmed active exploitation in the wild. CrowdSec tracks real attack traffic across millions of sensors globally; when a dependency's CVE shows up in live attack data, the proxy blocks it immediately.
Block when exploit code exists
A published proof-of-concept drastically lowers the barrier to exploitation: attackers can follow a recipe. The window between PoC publication and mass exploitation is measured in hours, not days. blockPoc closes that window for your dependency pipeline.
Block everything a compromised maintainer publishes
blockBadActors matches the maintainer behind a package, by registry account identity or by the GPG or SSH key their releases are signed with, against the Vulnetix threat-actor graph, and blocks that maintainer's whole catalogue. No CVE and no malware verdict are required. It also applies when a CVE itself carries threat-actor attribution: state-sponsored groups, ransomware operators and supply-chain specialists.
Delay newly published versions, carefully
Fast-follow supply chain attacks publish a malicious version seconds after a legitimate one, timed to catch automated upgrade scripts before the community notices. cooldownDays creates a time buffer, a hopeful freshness guard rather than proof of safety.
Avoid being first on a release
versionLag: N blocks a version unless at least N newer versions have been published. It is release-count-based rather than time-based, but it still only guesses that later releases create more scrutiny. It does not prove the older version is safe.
Your call overrides ours, in both directions
Signals decide the overwhelming majority of packages; for the rest your team keeps a per-ecosystem deny-list and allow-list, scoped to an exact version or a whole package. The deny-list is enforced in every mode, and wins when a package appears on both. An allow entry waives every policy-derived block but never exact-version malware, a known-bad artefact hash or a malscan verdict. Every change writes an append-only audit row, each entry records when it last stopped or permitted real traffic, and a review queue surfaces waivers nobody has re-approved or used.
Roll it out without stopping the line
Warn mode downgrades every block to a logged advisory that still names the reason and the status that would have been returned, so you can measure the blast radius against a live build fleet before committing. Enforce applies the policy, and is the default. Allow-list-only inverts the default so a package with no allow entry is not installable, and falls back to normal enforcement when the list is empty rather than halting every build. Set any of them organisation-wide or per ecosystem.
Across every ecosystem
Go, the pkg.go.dev API and Arch/AUR are free for the community; language, container and OS registries unlock on Pro and Enterprise. 25 registries are supported: