Search your archive of per release SBOMs for the component name and affected version range, list the firmware images that match, then map those images to device models and fielded units. The speed comes from having exact versions stored per image before the advisory arrives.
What you need in place first
The routine only works if three things exist before the news breaks.
- An SBOM for every released firmware image, stored in one place and searchable.
- A map from each image version to the device models and hardware revisions that run it.
- A rough idea of how many units are in the field on each image, even if only from update server logs.
If any are missing, build them in that order. The first is the most valuable.
The search routine
- Read the advisory. Note the component name, the affected versions and the fixed version. Check which identifier the advisory uses and which your SBOMs use, such as a package URL or a vendor name.
- Search every SBOM for the component. Match on name variants, because a library may be listed as its short name or as a vendor path.
- Compare versions against the affected range. Beware of backported fixes where the version number looks old but the patch is present, and of forks with local numbering.
- List matching images. For each, note whether the vulnerable feature is compiled in.
- Map images to models using your table. Then list the units reachable by update.
- Decide per image: fix, mitigate, or document that it is not affected.
Pitfalls
| Pitfall | What to do |
|---|---|
| The library is vendored and renamed | Search by file hash or distinctive strings as well as name |
| A transitive copy inside a vendor SDK | Search the SDK component list, and ask the supplier |
| An SBOM generated from source, not from the shipped image | Compare with the image's real contents for the critical components |
| Old images no longer built | Keep their SBOMs anyway, since units remain in service |
Communicating the result
Customers want a short, honest answer. For each model, say affected, not affected with a reason, or under investigation, and give a date for the next update. A machine readable VEX document is a good companion, and a plain table works for people.
Avoid guessing. If you have not confirmed that a model is clear, say it is under investigation.
Try it yourself
Open the vulnerability management demo and follow how a finding is traced to the assets it affects. The same shape applies to images and models.
Click through it at your own pace, or open it full screen.
Safeguard keeps SBOM and dependency data searchable across projects and monitors for new advisories. Mapping firmware images to device models and fielded units is data your team keeps. You can try a free scan to see how component data is presented.
Quick check
What if my SBOMs are stored as files in a folder?
A search over the files works, and a script is enough to begin with. A database makes repeat searches faster.
Is a version match enough to call a model affected?
No. Check that the vulnerable code is compiled in and whether a backport applied. Until then, say under investigation.
Last reviewed: 19 October 2026.
