To answer "are we affected?", search an inventory of every project, build and deployed artifact for the named component and version range, then confirm exposure on each hit by checking where it runs. Record what you checked and when. Speed depends on having the inventory before the report arrives.
Why this question is hard
Reports name a package and a version range. Your risk sits in transitive dependencies, container images, developer machines and CI runners that nobody listed. After the xz report, CISA's guidance was to downgrade to an uncompromised version, hunt for malicious activity and report findings. Each step presumes you can find the version first.
The steps
- Pin down the indicator. Exact package names, version ranges and any file hashes the source gives. Use the primary source, such as the vendor or a government advisory, not a social post.
- Query your inventory. Search software bills of materials and lockfiles for the component, including transitive paths.
- Check deployed builds. A repository may be clean while an older image in production is not. Match against what is running.
- Include the toolchain. Developer laptops, CI images and build caches can hold the component too.
- Confirm exposure. Is the affected version installed, loaded, and reachable? Record yes, no or unknown.
- Act. Remove or roll back, rotate credentials reachable from affected environments, and watch for the behavior described in the source.
- Write down the answer. Date, scope checked, method, result and owner.
What counts as evidence
| Claim | Evidence |
|---|---|
| Not in any repository | Inventory search with timestamp |
| Not deployed | Image or host scan results |
| Not exposed | Version check plus configuration check |
| Remediated | New build and redeploy record |
Where answers go wrong
- Searching direct dependencies only.
- Trusting a manifest range instead of resolved versions.
- Forgetting archived but still running services.
- Closing the question with no record, then being asked again by a customer.
Make the next one faster
Generate a bill of materials per build, store them in one searchable place, and keep a list of what is deployed. Test the search once a quarter with a known package.
Try it yourself
Open the demo and run the kind of lookup you would do on report day: find a component and see which projects hold it.
Click through it at your own pace, or open it full screen.
Quick check
Is a clean repository enough to say we are not affected?
No. Check deployed artifacts, container images and build tooling as well.
What should the written answer contain?
The indicator you searched for, the scope, the method, the date, the result and an owner.
Where Safeguard fits
Safeguard offers SBOM and dependency scanning and asset discovery, which support building this inventory. Try the free scan on one project.
Sources
Last reviewed: 19 October 2026.
