To find which devices are affected by a new CVE, search your release SBOMs for the component and the affected version range, list the releases that match, then join those releases to the device map. The result is a device list you can sort by exposure, update state, and last check-in.
Definitions
An affected range is the set of versions an advisory names as vulnerable. A release SBOM is the component list for one firmware build. A device map says which release each unit runs. The lookup is just two joins, so the work is in keeping all three accurate.
Steps
- Read the advisory for identifiers. Note the package name, ecosystem, and the first fixed version. Do not rely on the display name alone, because similar names collide.
- Query release SBOMs. Search by package identifier, not by free text. Include transitive entries and vendored copies.
- Check version against the range. Compare with the ranges in the advisory, not by eye. A version string that looks newer can still sit inside a backported range.
- List matching releases. Include releases that are no longer built but still run in the field.
- Join to devices. Count units per release, per hardware model, and per region.
- Split by exposure. Is the component used in a code path that is reachable? Is the device internet facing? Is the service even enabled in the shipped configuration?
- Decide the action per group. Update now, update in the normal cycle, mitigate by configuration, or document as not affected.
What commonly goes wrong
| Problem | Effect | Fix |
|---|---|---|
| SBOM lists a library but not the vendored copy | Missed devices | Add vendored code as components |
| Distribution backported a fix without bumping the version | False positive | Check the distribution advisory |
| Device never checked in | Unknown state | Treat as affected until proven otherwise |
| Release has no SBOM | Blind spot | Analyze the image, or flag it |
Record the answer
Write down the query you ran, the date, the number of matching releases, and the number of devices. If a customer asks later whether you checked, you have a dated answer. If the search found nothing, record that too, along with what was searched.
Practice before you need it
Run this lookup on a quiet day with a component you already know is in your firmware. Time it. Note where you got stuck: finding the SBOM, reading the version range, or getting the device counts. Teams that rehearse usually discover that the slow step is the device join, because the device record lacks the release identifier. Fix that gap first. A thirty minute drill every quarter keeps the data fresh and the people familiar with the steps.
Try it yourself
Click through it at your own pace, or open it full screen.
Click into a finding and see which builds contain the component. That is step 4 above.
Safeguard stores SBOMs and matches them against new advisories continuously, so the release list is ready when the advisory lands. Reachability analysis helps with step 6. The free scan at gold.safeguard.sh/scan shows the output on one project.
Quick check
Should I match by component name or by package URL?
Use a package identifier such as a package URL where you can. Names collide across ecosystems and vendors.
What do I do about devices that have not checked in?
Count them separately and treat them as affected until a check-in proves the release.
Last reviewed: 19 October 2026.
