Block vulnerable packages

Block package downloads with known vulnerabilities above CVSS and EPSS thresholds.

The vulnerabilities selector function checks each requested package version against known vulnerability data and matches when a vulnerability exceeds your thresholds. With a block effect, the download is stopped before the package reaches the developer or build.

Add the rule

In the dashboard, open the firewall, go to Rules, and create a rule:

Execution phase: download
Selector function: vulnerabilities
Max CVSS score: for example 9.0
Max EPSS score: for example 0.5
Effect: block and log

As JSON:

{
  "executionPhase": "download",
  "selector": {
    "function": {
      "name": "vulnerabilities",
      "options": { "maxCvssScore": 9.0, "maxEpssScore": 0.5 }
    }
  },
  "ruleEffect": { "block": true, "log": true },
  "description": "Block critical vulns with high exploitation probability"
}

To apply the JSON without the dashboard, use the export, edit, import round trip described in config import.

How the thresholds work

The rule matches when a vulnerability exceeds both thresholds:

CVSS measures severity, 0 to 10.
EPSS estimates the probability the vulnerability is exploited in the wild, 0 to 1.

The fields are named "max" because they state the highest score you are willing to accept. A vulnerability has to come in above both numbers to match, and the comparison is strict: with the thresholds above, a vulnerability scoring exactly 9.0 does not match.

Requiring both keeps the false positive rate down. A CVSS 9.8 finding with an EPSS of 0.01 is severe on paper but unlikely to be exploited; a CVSS-only policy would block it and generate exception churn. With the example above, only vulnerabilities that are critical and likely to be exploited are blocked.

Where the advisory data and scores come from is in Advisory sources, including how a score is chosen when vendors disagree and what happens when a vulnerability carries no score at all.

When a score changes

Scores move after publication. A CVE can start at 7.5 and be raised to 10 once analysis completes, a critical can be downgraded, and an advisory can be withdrawn. The firewall does not store verdicts; it evaluates each download request against its current advisory data, so a decision is never sticky:

A score lowered below your thresholds means the package passes on the next request. There is nothing to reset, and an exception created during the block is simply no longer consulted.
A score raised above your thresholds means the next request is blocked, even if the same version installed fine yesterday.

When a changed score becomes visible to a firewall, and which caches can serve a version without a new decision, is covered under Freshness and score changes.

Roll out with log first

On an existing codebase, a new blocking rule can break builds the same day. Start with log only:

"ruleEffect": { "block": false, "log": true }

Watch the logs for a week, see what would have been blocked, handle the real cases, then switch on block. Nothing is enforced in the meantime: a log-only rule records the match and serves the package.

Scope the rule if needed

The selector function combines with the other selector fields. To apply the rule only to external packages, leaving your internal packages to their own process:

"selector": {
  "internal": "external",
  "function": { "name": "vulnerabilities", "options": { "maxCvssScore": 9.0, "maxEpssScore": 0.5 } }
}

When a needed package is blocked

The blocked install error contains a request ID; the matching log entry shows the vulnerability details behind the decision. If you decide to accept the risk, create an exception with a documented reason such as not_exploitable and an expiry, rather than loosening the thresholds for everyone.