Dependency Firewall early access: 50% off the base fee. See pricing

Block versions with known vulnerabilities

Keep package versions with known vulnerabilities out of your builds. A vulnerability rule checks each requested version against advisory data and blocks the ones above the CVSS and EPSS scores you set.

How vulnerability blocking works

  1. 1Set the scores you accept

    Add a vulnerability rule with a maximum CVSS score, for example 8.9 to block critical vulnerabilities. Add a maximum EPSS score to block only the ones that are also likely to be exploited.

  2. 2Each download is checked

    The firewall checks the requested version against advisory data. A version with a vulnerability above both scores is not served, and the install fails.

  3. 3A block comes with the advisory

    The log entry names the vulnerability behind the block. Its page shows the scores, the exploitation status and the versions that fix it.

What decides a vulnerability block

Severity and likelihood together
CVSS measures severity and EPSS the probability of exploitation. A vulnerability has to exceed both, so a severe finding that is unlikely to be exploited does not stop a build.
Current scores on every request
The firewall stores no verdicts. A score raised above your thresholds blocks the next request, and a score lowered below them lets the version through again.
Log first
A rule can log without blocking. Run it for a week, see what it would have stopped, then switch on block.
Exceptions for accepted risk
When a team needs a blocked version, add an exception with a reason and an expiry date. The thresholds stay the same for everyone else.
Block CVSS 9 or higher
{  "id": "block-critical-vulnerabilities",  "executionPhase": "download",  "selector": {    "function": {      "name": "vulnerabilities",      "options": {        "maxCvssScore": 8.9,        "maxEpssScore": 0.0      }    }  },  "ruleEffect": { "block": true, "log": true }}

Questions

What happens when a new CVE is published for a version we already use?

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

What about a vulnerability nobody has scored yet?

A vulnerability with neither a CVSS score nor a severity label crosses no threshold, so the rule does not block on it.

Does it cover container images?

Yes. On a container firewall the same rule checks the OS packages installed in each image, matched against the advisories of the image's distribution.

Can internal packages be left out?

Yes. Scope the rule to external upstreams, and packages from your own registry are not checked by it.

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.