Complete common vulnerability tasks

Investigate one record

1. Enter the identifier.

   Use a CVE, EUVD, supported WID-SEC or supported patch advisory identifier. Search automatically covers all years.

2. Open the full report.

   Start with urgency, exploitation reality, product-specific affected ranges and remediation status.

3. Check provenance.

   Open the vendor, authority or official CVE source behind the finding.

4. Validate inventory.

   Match the product branch and version against your actual asset before changing it.

Build an email-ready multi-CVE assessment

1. Open Multi-CVE lookup.

   Go to the lookup tool ↗ and paste CVE identifiers, or upload a TXT or CSV file.

2. Review unmatched identifiers.

   Correct typing errors and confirm that newly reserved identifiers have been published.

3. Review affected and fixed columns.

   Product names remain attached to their version ranges. A vendor-authored solution is shown when structured evidence supplies it.

4. Choose the destination.

   Copy for email and Copy for spreadsheet now use the same normal row-and-column table, field order, values and CVE links. Download CSV uses the same columns in a file.

Check inventory applicability with SBOM and VEX files

Use this workflow when you already have a software bill of materials and want a bounded first-pass comparison with the public catalogue. The matcher is deliberately conservative and keeps uncertain component relationships visible.

1. Prepare supported JSON files.

   Use CycloneDX 1.4, 1.5 or 1.6, or SPDX 2.2 or 2.3. You may select more than one file. Optional VEX input can use CycloneDX VEX, CSAF 2.x or OpenVEX. Each file must be 5 MB or smaller.

2. Open Inventory applicability.

   Go to the dedicated matching workspace ↗ from the More menu and choose the SBOM plus any optional VEX JSON files. File parsing happens in the browser before anything is submitted.

3. Check the parsed-file summary.

   Confirm the filenames, detected formats, component counts and VEX statement counts. If a file cannot be parsed, correct its JSON or export it again in a supported version.

4. Run the match.

   BlackTree sends normalized component identifiers and optional VEX statements for this request. Original files are not uploaded. The result is not written to the catalogue database or retained by default.

5. Interpret each component state.

   Matched means a sufficiently strong relationship was found. Review match means the relationship is ambiguous. Unmatched means no reliable relationship was found and is not proof that the component is unaffected.

6. Resolve unmatched components.

   First compare exact purl, CPE, SWID, namespace and supplier values with the official package record. Then check former product names, vendor changes, repository names, abbreviations and the difference between package and marketing names. Confirm the package ecosystem and normalize the version only according to that ecosystem’s rules. Finally, search the vendor advisory and release notes for the exact product branch. Keep the result unresolved if those checks do not establish a reliable relationship.

7. Open candidate CVEs.

   Each suggested CVE opens its complete report in a new tab. Check the matched product, version, match method, confidence, vendor status and any applied VEX statement.

8. Export or clear.

   Export result JSON if you need a point-in-time record. Use Clear local data to remove the selected file state and displayed result from the browser session.

Prioritise remediation

Use this workflow to decide what should be investigated and changed first. BlackTree can organise the public evidence, but the final priority also depends on what your organisation runs, how it is exposed and what a failed change would affect.

1. Begin with confirmed exploitation.

   Review Known Exploited and “Patch now” records before relying on severity alone. A CISA KEV entry means that exploitation has been observed in the wild. Confirm whether the affected product is present, then treat an exposed matching system as an urgent investigation even when its CVSS score is not the highest in your queue.

2. Confirm that the product and version apply.

   Match the report’s exact vendor, product, edition, platform and affected version range to your inventory. Do not assume that similar product names share the same vulnerability. For example, an appliance, cloud service and platform service can have different affected ranges even when one bulletin covers all three.

3. Check how an attacker would reach it.

   Read the attack vector, required privileges and user-interaction fields. Then add facts from your environment: whether the service is internet-facing, reachable from user networks, protected by authentication, restricted by a firewall or disabled entirely. A remotely reachable unauthenticated flaw normally deserves faster attention than one requiring local access and an existing privileged account.

4. Consider technical and business impact together.

   Use CVSS to understand the possible effect on confidentiality, integrity and availability. Add the importance of the affected system, the sensitivity of its data, the number of users or customers involved, and the recovery options available. A medium technical score on a critical identity service can matter more to your organisation than a critical score on an isolated test system.

5. Use EPSS to rank work that is not already confirmed exploited.

   EPSS estimates the probability of near-term exploitation. It can help decide which non-KEV items to investigate first, particularly when the queue is large. Do not interpret a low value as “safe”, and do not let a high value override proof that the affected product is absent or the vulnerable feature is disabled.

6. Verify the fix for the exact product branch.

   Read each affected row beside its matching fixed row. Do not apply one aggregate version number to several products or release branches. If BlackTree links to an authoritative vendor update but cannot verify the fixed version from structured data, open the vendor advisory and confirm the target release, prerequisites, restart requirements and known exceptions.

7. Account for change risk and temporary controls.

   If the verified patch cannot be deployed immediately, check whether the vendor provides a workaround or mitigation. Restrict exposure, disable the affected feature or apply access controls only when those actions are safe and supported. Record that a temporary control reduces risk but does not necessarily remove the underlying vulnerability.

8. Record the decision and review it again.

   Document the evidence used, affected assets, chosen action, owner, target date and any accepted exception. Reopen the live CVE report and vendor advisory before deployment because severity, exploitation evidence and fixed-version guidance can change after the first assessment.

Use country guidance

1. Enable the relevant language.

   Select a national source from the report language controls.

2. Read the source-language label.

   The surrounding interface is localised, while authority text remains unchanged.

3. Compare affected mappings.

   Authority product information and the product-aware CVE mapping are shown together when both exist.

4. Read the complete source fields.

   Review every published note, product state, score, remediation, threat, flag, acknowledgement, reference and source-metadata field retained from the advisory.

5. Open the official advisory.

   Use the authority link for the complete national instruction and its latest revision. Structured source data opens separately when available.

Review what changed after publication

1. Open Recent changes.

   Choose the last 24 hours or last seven days. The count covers material record changes, not every source refresh.

2. Open a changed CVE.

   The report opens at its change history. Read the before and after values and the attributed source.

3. Recheck remediation.

   A new fixed version, vendor statement, exploitation status or affected range can change operational priority. Reopen the latest vendor source before acting.