You can answer quickly with scripts just if you already have a current inventory of what every service contains. The scan is the easy part. The delay comes from not knowing which repositories exist, which are deployed, and who owns them. Run a timed drill to find out.
What the question really needs
Three things, in order: a list of components per service, a way to search that list by package and version, and a map from service to owner. Missing any one turns a minutes question into a days question.
Run a timed drill
- Pick a real past advisory for a package you use.
- Start a timer. Find every repository and deployed service that includes an affected version.
- Record who you asked, which systems you searched, and what you could not see.
- Stop when you have a confident answer. Note the time.
Typical bottlenecks
| Bottleneck | Fix |
|---|---|
| Scans run weekly, data is old | Store SBOMs on every build |
| Repositories not scanned | Automate discovery |
| No search across results | Keep SBOMs in one queryable store |
| Deployed versus committed unclear | Record what is actually in production |
| Owner unknown | Maintain a service to team map |
A scripted approach
Generate an SBOM on every build, store it with the build ID and commit, and index it. A lookup by package name then returns services and versions. The CISA KEV catalog offers JSON and CSV feeds you can poll to flag advisories that are known to be exploited.
When scripts hit their limit
Scripts work well until the inventory crosses many teams and ecosystems. If your drill takes more than a day, or depends on asking people on chat, that is a measurable reason to evaluate a platform with continuous inventory.
Safeguard covers this ground with SBOM and dependency scanning, reachability analysis, policies and gates, and compliance evidence automation. Autonomous fix PRs are off by default, with every category set to Manual. You can try a free scan at gold.safeguard.sh/scan.
Practise the communication too
The technical answer is half of it. Decide who tells leadership, who tells customers, and what the message says when the answer is not yet known. Write a template with fields for the advisory, the affected services, the status and the next update time. During a real event, a prepared template saves more time than a faster query.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a new advisory is matched to an existing inventory, and compare with your drill time.
Quick check
What is the first thing to fix if the drill is slow?
Usually inventory coverage: make sure every repository produces and stores an SBOM on each build.
Do I need to scan again after an advisory?
Not if you stored SBOMs, because you can search them. Rescans cover changes since the last build.
Sources
Last reviewed: 19 October 2026.
