Applicability rules and CPEs

The scanner can only check a part it can identify. Software packages usually carry a package URL. Hardware, firmware and an operating system named in words do not. An applicability rule gives such a part an identity, most often a CPE, so its advisories can be found.

Rules live under Applicability rules in the sidebar (group Decisions). A rule applies to every project in your organization.

When you need a rule

A part that cannot be checked is not reported as safe. The scan says how many parts it could check, for example No known vulnerabilities in 4 of 6 parts, or Not assessable when it could check none (see How we count). The rules page lists these parts under Uncovered components (scans of the last 30 days), each with a Create rule button.

How a part becomes findings

At every scan, for each part in the BOM:

1. Match. TraceGuard looks for active rules with the part's name (not case-sensitive). If a rule names a type, the part's type must be the same. If a rule names a supplier, the part's supplier or manufacturer must contain that text. A part that states no type or no supplier still matches.
2. Identify. The rule gives the part its CPE or package URL. VERSION in the CPE is replaced by the part's version from the BOM. A CPE already in the BOM wins and is left as it is. A per-component override (listed on the Overrides tab) wins over both.
3. Match advisories. The scanner compares that identity with the products and versions that advisories name. Each match is a finding.
4. Version range (optional). If the rule has a version range and the part's version is outside it, the finding is marked Out of scope.
5. Count. Out-of-scope findings are kept and shown with their reason, but left out of the totals. The BOM page, the project overview and Findings say how many were left out, and how many of them are in CISA KEV or Critical. To list them, set Show to Suppressed only on the BOM's Vulnerabilities tab.

Only active (approved) rules take part. A new or changed rule applies from the next scan of each BOM; earlier scans are not rewritten. Rescan a BOM to apply it now.

What a version range can and cannot do

A range says "advisories for this part only matter between these versions". It hides findings, so it has limits:

• By default it judges only findings that came through the CPE or package URL this rule placed. A CPE written in the BOM, or one set by an override, is not put out of scope by a range unless you tick Also apply to parts whose CPE comes from the BOM in the rule dialog: then the range also judges findings on parts whose own CPE names the same vendor and product (for example a hand-written HBOM that lists ipados with its version in the CPE). Otherwise use a VEX decision or an exclusion for those.
• It judges only parts the rule matches by name, type and supplier.
• It compares the version the BOM gives the part. A part without a version takes the version from its own CPE when the CPE names one (cpe:2.3:o:apple:ipados:15.8:… gives 15.8), so the same part listed in several CPE versions stays several parts.
• If the part still has no version, or the version cannot be read in the chosen format, the range is not applied and the finding stays active.
• Rules are applied when a BOM is scanned. When you approve a rule, or change what an active rule matches or its range, TraceGuard queues a rescan of your current BOMs; until those scans finish the rules page shows Rescan pending on the rule.
• The rules page also shows, per rule, how many findings its range did not judge (Range not applied: n, because the BOM supplied the identity) and how many versions it could not read (Unreadable version: n).
• Creating or changing a range needs a written reason of at least 10 characters. The reason is shown with every finding the range marks out of scope, and in the rule's History.

A second source of out-of-scope findings is the link between an HBOM and an SBOM in the same project. See BOM types.

The rule dialog

Click New rule, or Create rule next to an uncovered component. The dialog has four parts.

1. Match — which parts the rule applies to.

2. Identify — set at least one.

3. Preview — enter a Sample version and click Preview to see the package URL, CPE and type the scanner will use for a part at that version.

4. Details

Approval and change control

Who can do what

These are the defaults. The permissions are View, Create, Update and Delete Applicability Rules, and Approve applicability rules. An owner can grant them to another role under Roles & permissions.

Statuses

To make a draft active, someone with Approve applicability rules clicks Approve. The approval records that person and the time. Nobody can approve in someone else's name. TraceGuard does not require a second person: someone who may both create and approve can approve their own rule. The History shows who did each.

An active rule cannot be rejected. To stop using it, delete it: the next scan of each BOM no longer applies it.

Editing an active rule

Some fields change what a scan does: component name, component type, supplier, CPE pattern, PURL template, type override and version range.

• Someone who may approve rules can change them. The button reads Save and re-approve: the rule stays active, the approval moves to that person, and the change applies from the next scan of each BOM.
• Someone who may edit rules but not approve them cannot change these fields on an active rule. They can still edit its notes and confidence. On a draft they can change everything; it still needs approval.
• Only someone who may approve rules can change the reason of an active rule's version range.

History and badges

Every change to a rule of your organization is in its History: Created, Edited, Approved, Re-approved, Rejected and Deleted, with who did it and, for edits, each field from and to. A deleted rule keeps its history. Rules that existed before change tracking began (18 October 2026) start with Change tracking started.

Rules marked TraceGuard catalog are maintained by TraceGuard and read-only. Clone to org makes an editable copy, which starts as a draft. Your organization's rule wins over a catalog rule for the same part.

CPEs

Which fields identify a part in the first place, and how deep an HBOM should go, is in Identifying components.

A CPE names a product the way advisories name it. TraceGuard uses the CPE 2.3 formatted string: 13 fields separated by colons.

cpe:2.3:a:openssl:openssl:3.0.13:*:*:*:*:*:*:*

Only part, vendor, product and version matter for a rule. Fill the other fields with *.

VERSION, * or a fixed version

• VERSION is replaced at scan time by the part's version from the BOM. Only the leading number is used: 17.5.1 (21F90) becomes 17.5.1. No version, or one that does not start with a digit (v3.0, rev B), gives *. Use VERSION when the BOM's version is the version of that product.
• * means any version: advisories for every version of the product are reported. It is normal for hardware CPEs, and for a hardware part you map to the same product as software in an SBOM of the same project: TraceGuard then judges the part's findings at the software version the SBOM declares (see BOM types).
• A fixed version, such as 17.5, gives every matching part in every project that version, whatever its BOM says. Use it only when the part always implements exactly that version, and say so in the notes.

Examples:

The supplier in the last row keeps the rule off another part that is also called bluetooth, such as a chip from a different supplier.

Finding the name advisories use

TraceGuard knows which vendor and product names the vulnerability database actually attaches advisories to, and how many. The same names drive the CPE field in the component editor (Components tab → edit a part) and the CPE pattern field of the rule dialog:

1. Type a product name, such as ipad, iPad OS or nrf52840. The list shows the matching vendor:product names with the number of advisories that use each one, most-used first. ipad offers apple:ipados (thousands of advisories) before apple:ipad_os (a few dozen) and the hardware name apple:ipad.
2. Pick one. The CPE is built with the part's version (or VERSION in a rule) and * in the other fields.
3. Paste or type a full CPE instead and the line under the field says whether its vendor:product is known (with the advisory count), sparse (most advisories use another name, offered with one click), filed under another part (a, o, h), or unknown (no advisory uses the name, so it matches nothing).

The counts come from the database the scanner runs, so "unknown" means exactly that no finding can come from this name today. The dictionary is reloaded whenever the scan worker updates its database. Agents get the same answers from the MCP tool suggest_cpe.

Looking up a name on the NVD website

When a product is not in the list at all, or you want to read the advisories yourself:

1. Open the NVD CPE dictionary search and search a keyword, such as openssl, ipados or nrf52840.
2. Read vendor and product from a result's CPE name. In cpe:2.3:o:apple:ipados:17.5:*:*:*:*:*:*:* the vendor is apple and the product ipados.
3. If a product has two names, use the one advisories are filed under. Open a few recent advisories for the product on NVD and look at the CPEs they list, or paste each name into the CPE field and compare the counts.
4. Put vendor and product in the pattern, VERSION or * as the version, and * in the other fields.
5. Click Preview with a sample version. After the next scan, check the rule's Hits (30d) and whether it shows Matches no advisories.

Common mistakes

Matches no advisories

After each scan, TraceGuard checks every part that only a CPE identifies (no package URL): it looks the same CPE up again at any version, keeping update and edition. If no advisory names that product at all, the part is flagged matches no advisories. You see it on your organization's rule that placed the CPE (Matches no advisories), on the BOM's Components tab and in the import notes on the BOM's Overview. A BOM with more than 500 distinct CPEs of this kind is not checked.

It means one of two things:

• The name is wrong. The vendor or product is misspelled, is a rarely used alias, or does not exist in NVD. Fix the CPE.
• Nobody has reported a vulnerability for this product. Some parts are named correctly and simply have no advisories. Keep the rule and say so in the notes.

The part still counts as covered, because both cases look the same to the scanner. The flag tells you to check which one it is.

Checklist before you save a rule

• The component name is exactly the name in the BOM.
• If two parts share that name, the type or supplier tells them apart.
• Vendor and product come from the NVD dictionary, not from memory.
• The version is one field: VERSION for software whose BOM version is the product version, * for hardware or a part mapped to an SBOM's software.
• No fixed version, unless every project's part really is that version.
• Preview with a real version from your BOM shows the CPE you expect.
• A version range only if you know the advisories outside it do not apply, with a reason someone else can check.
• Notes say where the CPE comes from.
• After the next scan: Hits (30d) is above zero and Matches no advisories is explained.

Related

• Triage & decisions — VEX decisions and exclusions.
• BOMs & version history — rescan a BOM and see what changed.
• Vulnerabilities & scanning — how scans run.
• BOM types — HBOM and SBOM in one project.
• Glossary — CPE, applicability rule and other terms.