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.
Today 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.
Block vulnerable versions before the install
A vulnerability rule decides which versions are served. Put it on a baseline firewall that every team firewall inherits, and container images pass the same check.
Block versions above your CVSS and EPSS scores
Vulnerability blockingApply the same threshold to 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, a developer requests a time-limited exception and the security team approves or denies it. 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. 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. Teams request exceptions, which 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 ProtectionApply the same package rules to every build, with only the registry URL changed on your runners.
- AI Coding AgentsCheck every install an agent makes against the rules your security team sets.
- Policy GovernanceLet security set the dependency rules for every team and approve waivers for blocked packages.
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.