Use the catalogue with confidence

They measure different things and should not be read as competing versions of one risk score.

• CVSS describes technical severity. It summarises characteristics such as attack vector, required privileges, user interaction and potential impact. It does not know whether your organisation uses the affected product or whether attackers are currently exploiting it.
• EPSS is a probability forecast. It estimates the likelihood that a published CVE will be exploited in the near term based on observed signals. A low probability is not proof that exploitation is impossible, and a high probability is not confirmation that exploitation has occurred.
• KEV records confirmed exploitation. A CISA KEV listing means CISA has evidence of exploitation in the wild. Absence from KEV means that this particular confirmation is not present, not that the CVE is safe.

For example, a medium-severity vulnerability can appear in KEV because attackers value its reliability or reach, while a critical vulnerability can have a low EPSS value because it is difficult to operationalise. Start with confirmed exploitation, then combine technical impact, exposure, affected product and your own business context.

No. It means an authoritative patch reference, fixed product state or vendor-authored solution was found somewhere in the retained evidence. Always read the product-specific affected and fixed rows before scheduling a change.

• Different release branches: a vendor may fix Product A 5.0 in 5.0.6 and Product A 4.4 in 4.4.9. “Patch available” does not mean that every installation should move to one shared version.
• Different products: one advisory may cover an appliance, cloud service and platform service. The appliance may require an upgrade, the cloud service may already be corrected by the vendor, and one older branch may have no fix.
• Partial structured evidence: BlackTree may find an authoritative vendor update link while the CVE record itself contains no fixed-version field. The report then links to the advisory but keeps the fixed version unverified until a product-specific release can be identified.
• Not affected branches: a bulletin can list one current branch as not affected while older branches require patches. The overall label remains “Patch available”, but the correct action differs by branch.

Use the affected product name, affected range and matching fixed row together. If any one of those is missing, confirm the release in the linked vendor advisory.

No. CSV and TXT files are read in the browser so the page can extract valid CVE identifiers. The original file is not uploaded. When you start the lookup, only the normalized CVE identifiers are sent for that request. BlackTree does not write the submitted list or generated comparison result to the catalogue database and does not retain it by default.

The result remains visible in the current browser page until you clear it, replace it or close the page. Copying a table places it on your device’s clipboard. Downloading CSV creates a file on your device. Those local copies are then governed by your browser, operating system, email application and organisation’s data-handling rules.

Use this function only for public CVE identifiers. Do not add hostnames, IP addresses, usernames, asset names, incident notes, credentials or other internal context to the uploaded file.

Each country report separates BlackTree interface text from the wording supplied by the national authority. Navigation labels, field names and explanatory notes are presented in the report language. Advisory content is preserved as the source published it so that BlackTree does not silently alter a security statement.

A Dutch authority can publish a Dutch title and remediation note while quoting an English vendor description. In that case, the English passage is still part of the Dutch source and remains English. Similarly, product names, technical terms and vendor release titles may not have a meaningful local translation.

Use the displayed source-language label and official bulletin link to verify the original context. If a passage looks inconsistent, compare it with the attached source before treating it as a translation error. BlackTree should localise its own fallback phrases, but it should not invent a translation for authority-supplied evidence.

It means the matcher did not find a sufficiently reliable relationship between the component and a product in the current catalogue. It does not prove that the component is unaffected. Work through these checks before reaching a conclusion:

1. Check exact identifiers. Compare the package URL (purl), CPE, SWID reference, package namespace and supplier name with the component’s official package or vendor page.
2. Check common aliases. Look for renamed products, former vendor names, abbreviations, repository names and differences between a package name and its marketed product name.
3. Check the ecosystem. Confirm that the package belongs to the expected ecosystem, such as npm, Maven, PyPI, NuGet, Debian or RPM. The same short name can refer to unrelated software in different ecosystems.
4. Check the version. Remove build metadata only when the package rules permit it, and verify whether the vendor uses release branches, editions or platform-specific versions that differ from the SBOM value.
5. Check authoritative evidence. Search the vendor advisory, release notes and the linked CVE record for the exact product family and affected version range.

If the component still cannot be matched, record it as unresolved and review it manually. Do not convert an unmatched result into “not affected”.

It means the matcher found a plausible relationship but not enough precise evidence to select one product or CVE automatically. This commonly happens when an SBOM contains only a short package name, when several vendors use the same name, when a project has been renamed or forked, or when the package version cannot be aligned confidently with the vendor’s release scheme.

Review every suggested candidate rather than choosing the first result. Compare the supplier, namespace, purl, CPE, repository, homepage, package ecosystem and version with the official component record. Then open the candidate CVE reports and check whether the affected product and version branch describe the component you actually have.

For example, a component called “gateway” could refer to unrelated packages in npm, Maven or a vendor appliance. A name match alone is too weak. A matching purl namespace, supplier and version range may resolve it; conflicting ecosystems or vendors should rule it out.

If the evidence remains incomplete, keep the component in manual review. An ambiguous match is not a confirmed vulnerability and is not an unaffected result.