Vulnerability monitoring

Where the data comes from

boring.tools keeps its own copy of the OSV database, the open vulnerability database that aggregates GitHub Security Advisories, the Python, Go and Rust advisory databases and many more. The copy is checked for updates every five minutes.

Vulnerability matching covers these ecosystems, identified by the component’s purl type:

Components of other ecosystems are imported and listed, but don’t produce findings. The project overview shows this as Matched in CVE catalog: the number of components we have vulnerability data for.

How matching works

A component matches an advisory when the advisory lists the same package (same ecosystem and name, taken from the component’s purl) and the component’s version falls into an affected range — at or above the version that introduced the problem and below the version that fixed it. Advisories that were withdrawn are ignored.

When an advisory lists the affected versions explicitly, the version has to match one of them exactly. Otherwise ranges are compared as semantic versions (1.2.3). Versions that aren’t semantic versions — common in Maven (2.13.4.2) or Python (1.0rc1) — can only be matched against explicit version lists, not against ranges. If a component looks suspiciously clean, check its version in the SBOM.

Severity

Each finding carries the advisory’s CVSS score (CVSS v4 preferred, then v3, then v2). When an advisory only has a textual rating, we use the middle of its band.

Exploited first

A CVSS score says how bad a vulnerability could be, not whether anyone uses it. boring.tools adds three public signals to every finding with a CVE id:

The Findings tab sorts by them: exploited findings first, then by EPSS, then by CVSS. Switch to CVSS only if you prefer the plain severity order, or filter with Exploited to see just those. An exploited finding in a product also opens a CRA reporting case.

Continuous re-analysis

You don’t have to re-upload an SBOM to learn about new vulnerabilities. Whenever the vulnerability database changes, boring.tools re-analyses the latest SBOM of every artifact in every version that is in support (see Projects). New findings appear on their own; findings whose advisory was withdrawn disappear. Your triage decisions are kept.

Working with findings

The Findings tab of a project shows the latest SBOM of one artifact in the selected version. You can filter by:

• Exploited — listed in CISA KEV or ENISA EUVD
• Severity — critical to low, or unknown
• Triage status — open (not triaged yet), has an AI suggestion, or a specific status
• Dependency — direct or transitive, when the SBOM contains a dependency graph
• Search — advisory id or component name

Click a finding to open its details: the advisory text, aliases such as the CVE id, your exposure (direct or transitive, and which of your direct dependencies introduces it), and the triage form.

Fixing vulnerabilities

Fix command on the Findings tab builds copy-paste upgrade commands for the open findings of the SBOM; the details of a single finding show the commands for just that package.

• npm: for a direct dependency, the lowest version that fixes the advisory. For a transitive one, the lowest release of the direct dependency that pulls in a fixed version — the upgrade you can actually make. Packages released together under one scope (such as @angular/*) are upgraded together.
• Python (pip install) and Go (go get … && go mod tidy): the lowest fixed version.

Upgrades that cross a major version are listed separately, because they may need code changes. Packages without any fixed release are listed as having no fix yet.

Exporting

Export OpenVEX on the Findings tab downloads your triage decisions as an OpenVEX document — see Triage and VEX.