Searching every product for one vulnerability
The exposure search checks every active product against one vulnerability identifier. It queries the Open Source Vulnerabilities database and gives one verdict for each product.
You can search by CVE, GHSA or other OSV identifier. The OSV record of a CVE names no affected package. For a CVE, the search reads the packages from the records that the CVE record lists as aliases, GitHub advisories (GHSA) first. For example, CVE-2021-23337 gets the npm package lodash from GHSA-35jh-r3h4-6jhm.
Components with a CPE
Many firmware components have no package in OSV, for example BusyBox, OpenSSL or xz in a Linux image. For a CVE, the search also checks each component that has a CPE against the copy of the CVE data that CVD Portal keeps. The copy holds the NVD configurations and the affected versions that the CVE Numbering Authority (CNA) wrote. The search uses the rules of the SBOM scan, see How CPE components are checked. For example, a component with the CPE cpe:2.3:a:tukaani:xz:5.6.0:*:*:*:*:*:*:* is Affected by CVE-2024-3094.
The search never matches a component by its name alone, because a name such as zlib also names other software. A component with the product name of the CVE and no CPE makes the product Unknown, with the reason name_only. Add the CPE to that component in the SBOM.
When the copy of the CVE data is more than a day old, the search cannot check components with a CPE. A product with such components is then Unknown, with the reason cve_mirror_stale.
You can find the search in the sidebar under CRA compliance, Exposure Search. The feature requires the Compliance plan.
Verdicts
The search returns one of five verdicts for each product.
| Verdict | Key | Description |
|---|---|---|
| Affected | affected | OSV reports a component version in the product SBOM as affected, and no VEX statement clears it |
| Not affected (VEX) | not_affected_vex | Every affected component carries a VEX status of not_affected or fixed |
| Not affected (version) | not_affected_version | The package is in the SBOM with a version, and OSV reports that version outside the affected range |
| Not in SBOM | not_in_sbom | No SBOM component matches an advisory package name |
| Unknown | unknown | The product cannot be checked |
Unknown reasons
A product the search cannot check shows as unknown. The table lists the reasons in check order.
| Reason key | Description |
|---|---|
no_sbom | No SBOM reaches the product |
stale_sbom | The SBOM is more than 90 days old |
no_package_data | The OSV advisory and its aliases list no affected package, and the CVE data names no affected product |
lookup_failed | The OSV version check did not answer for this product candidates |
unversioned_components | A matching component has no version that the search can check, and no other component is affected. A tag such as latest, a range such as ^1.2 or 1.x, a Git URL and a Maven ${property} count as no version |
range_floor | A matching component gives only a version range, such as ^4.17.0 in a package.json. The search checked the lowest version of the range and found it outside the affected range. The version you ship can be inside it |
cve_mirror_stale | The copy of the CVE data is more than a day old, and the SBOM has components with a CPE. The search cannot check those components |
name_only | A component has the product name of the searched CVE but no CPE. The search cannot check its version |
VEX statements
VEX statements recorded on the SBOM settings page can clear an affected component. When an affected component has a VEX status of not_affected or fixed, the search clears that match. If all affected components have a clearing VEX status, the verdict becomes Not affected (VEX). A VEX status of under_investigation or affected does not clear a component.
Products with SBOM parts
A product SBOM can have parts, for example the device firmware and a back-end service. The search checks all parts of the product together. The Components column names the parts that ship each component, for example Shipped in firmware. A report that you start from the result keeps the part names in the reason of each affected component.
Limits
The search has three limits.
First, the search checks the SBOM that is current today. It does not check earlier product releases.
Second, the search finds only components that the SBOM lists. Supplier firmware without its own SBOM can show as Not in SBOM.
Third, a package.json or Cargo.toml manifest can give a version range, such as ^4.17.0. In a Cargo.toml, a bare requirement such as "1.2" is also a range, because Cargo reads it as ^1.2. The search checks the lowest version that the range allows. A range with no lower bound, such as <2.0.0, has no lowest version, so the component counts as having no version. The Components column shows the lowest version as 4.17.0 (from range ^4.17.0). The version you ship can be higher. When that lowest version is affected, the result is Affected. Confirm the shipped version before you start a report. When it is not affected, the result is Unknown with the reason range_floor, because a flaw that starts at 4.17.5 misses 4.17.0 but can be in the 4.17.20 you ship. Upload a CycloneDX or SPDX SBOM to check exact versions.
Starting an Article 14 report from a result
The page shows an exploitation evidence block for the searched vulnerability. It reads the local KEV table, which merges five catalogues. No KEV entry does not mean the vulnerability is not exploited. An advisory with no CVE alias shows Not checked.
An administrator sees a Start Article 14 report button on each affected product.
The created report holds the product, the advisory text, the affected components, the KEV evidence and the draft fields. The draft fields include the title, the CVE identifier and the nature of the vulnerability.
The search does not mark the vulnerability as actively exploited. It does not set the time you became aware. You record that decision on the report page. The Article 14 deadlines start only from that decision.
A second click for the same product and vulnerability opens the existing report. It creates no second report.
If a part of the report could not be saved, the page names that part and links to the report. The parts are the product link, the affected components and the Article 14 draft. Add the part by hand, or click Start Article 14 report again. A second click tries only the missing parts again. It never writes over a part that is already saved.