Identifying components

TraceGuard can only report advisories for a part it can identify. This guide says which fields do the identifying, how to write them for software, operating systems, chips and firmware, how deep to go, and what to do when a part shows no findings.

Which fields identify a part

Fields are tried in this order. The first one that works decides the match.

A CPE you write in the BOM is kept as yours: TraceGuard adds CPEs from rules only to parts that have none. A rule's version range judges a part whose CPE came from the BOM only when the rule says so (Also apply to parts whose CPE comes from the BOM, see version ranges).

Versions

• Put the version in the part's version field. A part without a version but with a versioned CPE takes the version from the CPE: cpe:2.3:o:apple:ipados:15.8:… gives 15.8. Listing the same part several times, once per CPE version, keeps several parts.
• Write versions as numbers separated by dots: 15.8, 2.16.5, 10.0.2. A build suffix is fine (17.5.1 (21F90) reads as 17.5.1); v3.0, rev B or latest cannot be compared, so a version range does not apply to them and the part keeps all its advisories.
• A part with no version at all matches advisories for every version of the product. That is the safe default for hardware; for software, add the version.

How deep an HBOM should go

List the parts that run code or carry firmware, at the level advisories are filed:

Keep each part's type honest (device, firmware, hardware, operating-system, library): rules match on it, and two parts that share a name are told apart by their bom-ref and supplier, so give every part a unique bom-ref and the supplier when you know it.

What TraceGuard ignores

• CycloneDX scope (required, optional, excluded): every listed part is scanned.
• Free-text fields (description, notes) and external references: they are kept, not matched.
• Hash values: useful provenance, not identification.

"No findings": is there really nothing?

The BOM header says how many parts could be checked: No known vulnerabilities in A of M parts, and the Components tab gives every part a verdict in its Vulns column: Checked, none known, n hidden, Not identified or Identifier unknown to NVD, with the reason on hover (an assistant gets the same through the MCP tool explain_coverage). A part that could not be checked is not safe, it is unidentified. Work through the list:

1. Does the part have a purl or a CPE? If not, add one, or write an applicability rule that maps its name.
2. Is the CPE one NVD uses? apple:ipad_os matches nothing, apple:ipados does. Look the product up in the NVD CPE dictionary and copy vendor and product exactly. A rule that places a CPE no advisory uses shows Matches no advisories on the rules page.
3. Is the version readable? See Versions. Rules show Unreadable version: n when they could not read a part's version.
4. Did a rule or a decision hide it? The Findings page filter Applicability shows what rules set out of scope; Triage shows VEX decisions and exclusions. The rules page shows Range not applied: n for parts whose CPE came from the BOM.
5. Was the BOM scanned after the last change? Rules apply at the next scan; TraceGuard queues one when a rule is approved or changed, and shows Rescan pending until it finishes.

If all five hold and a part still shows nothing, no advisory names that product at that version in the sources TraceGuard reads (OSV, GitHub, NVD and the KEV and EPSS feeds). That is a real answer, and the BOM header counts it as checked.

Related

• Applicability rules and CPEs
• Inventory
• BOM types