Vulnerable Dependencies
Keep package versions with known CVEs out of your builds. Set the CVSS and EPSS scores you accept per firewall, and new advisories apply to the next install without a rule change.
CVEs are found after the install
Package managers pick the newest version that matches a range. They do not check advisories, so the vulnerable version is in the lockfile before a scanner runs.
- The ticket arrives after the merge
- A scan finds the CVE once the code is reviewed and merged. Fixing it means reopening finished work.
- Each team draws the line somewhere else
- One project blocks CVSS above 7, another only critical findings, a third has no check at all.
- Exceptions live in chat
- An approved exception has no expiry and no link to the package it covers.
What keeps vulnerable versions out
A vulnerability rule decides which versions are served. A baseline applies it to every team, and container images pass the same check.
Block versions above your CVSS and EPSS scores
Vulnerability blockingSet one threshold for every team
Centralize firewall rulesCheck the OS packages in container images
Container firewallingStop malicious packages that have no CVE
Malware blocking
- Exceptions expire
- When a team needs a blocked version, an admin adds a time-limited exception from the block details. It goes into the audit log.
- Log before you block
- A rule can log without blocking. Run it for a week to see what it would stop, then switch on block.
- Security fixes skip the delay
- With a release delay on, a version published as a fix for a known vulnerability can be let through at once.
Only the registry URL changes for each package manager. Nothing is installed on developer machines.Supported ecosystems
Developers see why a version was blocked
Each package version lists its advisories with CVSS, EPSS and the version that fixes each one. The rules read the same data, so the reason for a block and the version to move to are on the same page.
Stricter rules for production
Run a firewall per team or environment. Each one inherits the baseline and can add stricter rules of its own, so production can block CVSS above 7 while the baseline blocks critical vulnerabilities only. A firewall cannot weaken or switch off a rule it inherits.
Who works with it
- Application security
- A CVSS or EPSS threshold on the baseline applies to every team firewall. Exceptions carry an expiry date and go into the audit log.
- Developers
- See the rule and the advisory at install time, before code review.
- Platform engineers
- Keep firewall configurations as JSON in Git and deploy them through the API, with rollback.
Questions
Can we set different thresholds per team?
Yes. Create a firewall per team or project, each with its own rules. Shared rules go on a baseline firewall that the others inherit.
What happens when a new CVE is published for a package we already use?
The next request for that version is blocked. Copies already installed or cached stay until the next install.
Does a vulnerability rule stop malware?
No. Vulnerability rules act on CVEs with a CVSS or EPSS score, and a malicious package usually has no CVE. Add a malware rule and a release delay for that.
Malicious packagesMore Dependency Firewall use cases
All use cases- Malicious PackagesBlock malicious packages and account-takeover payloads before anyone installs them.
- 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.