To know whether a zero-day affects you, match the advisory's product and version range against an inventory of what you run and ship. Check direct and transitive dependencies, containers and vendor software, then label each system affected, not affected or unknown. The quality of your inventory sets the speed of your answer.
What the advisory has to tell you
Pull four facts from the advisory before you search: the product or package name, the affected version range, the component or feature that is vulnerable, and the conditions needed for exploitation. The last two matter later when you decide urgency.
Package names can differ between ecosystems. A library may be published under one name in one registry and another in a second. Use the identifiers in the advisory, such as a package URL or a CPE, when they are given.
Four places to look
| Source | What it answers | Typical gap |
|---|---|---|
| Software bill of materials | Which builds contain the library | Stale if not regenerated per build |
| Dependency lock files | Direct and transitive versions in a repo | Misses what is not in source control |
| Container image scans | What is inside deployed images | Old images still running |
| Asset and vendor lists | Commercial products and SaaS | Versions often not recorded |
No single source is complete. A repository scan will not find an appliance, and an asset list will not find a library bundled inside a jar file.
Handling unknown
The honest output of an exposure check has three values. Affected means a version in range is present. Not affected means you checked and it is absent or outside the range. Unknown means you could not tell.
Treat unknown as work to do. Assign each unknown system an owner and a time to answer. If a team cannot answer in a day, that is a finding about your inventory, and it belongs in the review afterwards.
Present is not the same as exploitable
A library can be in your build and never called. Reachability analysis checks whether your code can actually reach the vulnerable function. It helps you order the work, but it does not replace the list. Keep the full list, then rank it. Do not mark something not affected on reachability alone unless you can explain why to an auditor.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how one package appears in several projects, then imagine the advisory naming that package.
Where Safeguard fits
Safeguard builds an SBOM and dependency inventory from your repositories and images, and its zero-day discovery work compares new advisories to it. A free scan shows what an inventory looks like for one repository.
Quick check
What if the advisory gives no version range?
Treat every instance of the product as affected until the vendor says otherwise, and ask the vendor for the range.
Is a lock file enough?
It covers source dependencies in one repository. Add images, deployed hosts and vendor software to get a full answer.
Last reviewed: 19 October 2026.
