Advisory sources
Advisory and exploit-prediction data used by the vulnerabilities selector function.
The vulnerabilities selector function matches package versions against the Bytesafe advisory dataset.
The firewall uses advisory data for the supported package ecosystems, except Conda; see Ecosystem coverage. Operating system feeds are not listed here because container image firewalling is not implemented yet.
Advisory sources
| Source | URL | Used for |
|---|---|---|
| National Vulnerability Database (NVD) | nvd.nist.gov | CVE metadata, CVSS scores, publication dates, and modified dates. |
| GitHub Advisory Database (GHSA) | github.com/advisories | Package advisories from GitHub's advisory database. |
| GitLab Advisory Database | gitlab.com/gitlab-org/advisories-community | Package advisories from GitLab's advisory database. |
| Go Vulnerability Database | pkg.go.dev/vuln | Go module advisories. |
The European Vulnerability Database (EUVD) is planned as an additional source. It is not used by the firewall today.
EPSS is attached separately from advisory data:
| Source | URL | Used for |
|---|---|---|
| FIRST EPSS | first.org/epss | Exploit probability and percentile by CVE. Rules compare against probability, not percentile. |
Dataset format
The firewall downloads a prebuilt dataset that Bytesafe builds from the sources above, caches it on disk, and loads it when the process starts. Self-hosted deployments need outbound HTTPS access to fetch it; see Deployment models.
The dataset has two record types:
- Advisories: one affected package from one source, including ecosystem, package name, vulnerable ranges, patched versions, timestamps, source, and withdrawn status.
- Vulnerabilities: one vulnerability ID, including title, description, CVSS data by vendor, severity by vendor, CWE IDs, references, and EPSS.
Withdrawn advisories are ignored during matching.
Ecosystem coverage
Advisory matching follows the supported package ecosystems, except Conda: the dataset has no Conda advisories, and the vulnerabilities selector function is not supported for Conda firewalls in the beta.
Version matching uses each ecosystem's native version scheme. Package names are normalized before matching according to each ecosystem's rules.
CVSS score
A rule like maxCvssScore: 7.0 compares against one score per vulnerability:
If the effective vendor provides a numeric CVSS score, the firewall uses it. If not, the firewall maps the vendor severity label to a score:
| Severity | Score used |
|---|---|
| CRITICAL | 10 |
| HIGH | 8.9 |
| MEDIUM | 6.9 |
| LOW | 3.9 |
If the vulnerability has no score and no severity, it counts as 10.
Vendor priority
When multiple vendors report data for the same vulnerability, the firewall chooses the effective vendor in this order:
- NVD
- GHSA
- Go Vulnerability Database
EPSS score
Each vulnerability can carry an EPSS score from FIRST. EPSS has two values:
probability: likelihood of exploitation, 0 to 1.percentile: ranking compared with other CVEs, 0 to 1.
The selector's maxEpssScore compares against probability.
Both thresholds must be exceeded for a match: CVSS score must be greater than maxCvssScore, and EPSS probability must be greater than maxEpssScore. Details and examples are in Block vulnerable packages.
Freshness and score changes
Advisory data changes after publication. A CVE often appears with a provisional CVSS score that is revised once analysis completes: 7.5 can become 10, a critical can be downgraded, and an advisory can be withdrawn entirely. EPSS probabilities are recalculated as exploitation data comes in.
The firewall stores no verdicts. Every download request is evaluated against the advisory dataset the firewall currently has loaded, so score changes take effect in both directions:
- Score drops below your threshold: the
vulnerabilitiesrule stops matching, and the next request for the package passes. Nothing needs to be reset. An exception created while the package was blocked stops being consulted, because exceptions are only checked after the rule matches. - Score rises above your threshold: the rule starts matching, and the next request is blocked. This applies even if the same version was downloaded through the firewall before; the firewall's artifact cache does not bypass rule evaluation.
- Advisory withdrawn: it is excluded from matching entirely.
Two things bound how quickly a change shows up:
- The dataset is versioned and timestamped. A running firewall loads it once at process start; if the cached dataset exists, the firewall reuses it, otherwise it downloads a fresh copy. A score change reaches a firewall when it loads a dataset that contains it.
- Only requests that reach the firewall are evaluated. A version already sitting in a client's local package manager cache, or in a repository manager cache in front of the firewall, is served from there without a new firewall decision.
Other package signals
- Malware detection combines package-content findings with dedicated malicious-package intelligence. It does not use the vulnerability dataset described on this page. See Block malware.
- Deprecated and unlisted status comes from upstream registry metadata. See Block deprecated packages.
Related
- How-to: Block vulnerable packages
- Reference: Selector functions, Rules and selectors