Skip to content
Vulnerable Dependencies | Use Cases

Vulnerable Dependencies | Use Cases

Bytesafe.Dev • October 15, 2026

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 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.

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 blocking 4.17.11 Blocked, CVSS 9.8 4.18.0 Served, fixes all 7 Rule: block CVSS 9 or higher

Block versions above your CVSS and EPSS scores

Set one threshold for every team Centralize firewall rules Baseline firewall Owned by the security team Block known malware Block CVSS 7.0 or higher Hold new versions for 7 days Developers CI/CD pipelines AI agents

Set one threshold for every team

Block CVSS 7.0 or higher

Hold new versions for 7 days

Check the OS packages in container images Container firewalling node:22-alpine Served billing-api:2.8.0 Blocked Application Runtime Base image CVE-2022-37434 in an OS package

Check the OS packages in container images

CVE-2022-37434 in an OS package

Stop malicious packages that have no CVE Malware blocking billing-api arrayref proc-macro1 serde serde_derive tokio mio Blocked proc-macro1 Known malware. No CVE assigned.

Stop malicious packages that have no CVE

Known malware. No CVE assigned.

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.

Yes. Create a firewall per team or project, each with its own rules. Shared rules go on a baseline firewall that the others inherit.

The request for that version is blocked. Copies already installed or cached stay until the install.

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.

More Dependency Firewall use cases

Malicious Packages Block malicious packages and account-takeover payloads before anyone installs them.

CI/CD Pipeline Protection Route CI/CD pipelines through Dependency Firewall and enforce the same rules on every build.

AI Coding Agents Check 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 install. The trial runs 14 days.

Extracted Entities

Attack Types (1)