Examples in this article are illustrative, not customer case studies. Product availability and coverage are described on the linked capability pages.
A high-severity advisory lands for a parsing library you know you use somewhere, and within minutes someone asks which of your images shipped it and whether any of them are running. This post shows how to answer from retained SBOMs and deployment links rather than a fresh scan of every repository, and how to decide what to patch first. Waiting on that scan means spending the most urgent hours of the incident generating data you should already hold.
The fastest answer to “which images shipped this CVE?” is a query, not a scan: match the advisory against the SBOMs you retained for every image, keyed by digest, follow each match to the workloads running that digest, then rank those workloads by exposure. The advisory changes your knowledge, not your artefacts.
Take a checkout service with a long release history. The current version runs in production behind the public storefront, an older build still runs in a staging cluster, and a nightly reconciliation job is pinned to an image nobody has rebuilt in a long time. Each was built from a different commit, and any of them might carry the affected library.
Re-scanning everything is the wrong first move on CVE day
The instinct is to re-scan: queue SCA across every repository and see what comes back. That works eventually, but it fails in two ways exactly when you can least afford it. It is slow, because scanning a whole estate competes with every other job in the pipeline queue. It is also incomplete, because a scan of today’s source describes today’s source.
The reconciliation job’s image was built from a branch that has since been merged and deleted, on a base image that has since been replaced. Re-scanning the repository tells you what you would build now, not what is running. The image in the cluster reflects what existed at build time, and no scan of the current tree reconstructs that faithfully.
A new CVE changes your knowledge, not your artefacts
The vulnerable code was already in every image built from it; the advisory only changes what you know. That points to the right first move. Start with the data recorded at build time. Incomplete inventories, vendored code and ambiguous advisory matches may still require new analysis.
This is why an SBOM should be treated as evidence rather than as a compliance file produced and forgotten. If every build of the checkout service produced an SBOM stored against the image digest, all three images have recorded component inventories whose coverage can be assessed. The advisory names a component and an affected version range, and matching one against the other is a query that returns in the time a query takes, not the time a scan queue takes.
Retained SBOMs turn the CVE question into a lookup
Retention is the part teams most often skip. An SBOM kept only for the latest build describes the image you are about to ship, not the ones already running. The reconciliation job is exactly the artefact that falls through: rarely rebuilt, easy to forget, still live. Keep an SBOM for every image you might still be running, index it by digest, and include the full transitive tree, since advisories often land in libraries nobody declared directly. The difference between the two questions is covered in SCA vs SBOM: what each answers.
An image match only matters once it resolves to a running workload
Knowing which images contain the library is progress, but it is not triage. An image sitting unused in a registry is a different problem from the same image serving public traffic. The component-to-image match is the first hop; the image-to-workload hop is the one that sets urgency.
That second hop needs deployment data connected to composition data, not stored beside it. If the match stops at “this image contains the vulnerable version”, someone has to cross-reference a separate cluster inventory, chase whoever owns the reconciliation job and confirm which tags are live, all while the clock runs. Binding images to workloads by digest rather than by tag removes the ambiguity, because a tag can move and a digest cannot. The mechanics are in binding images to running workloads.
Exposure, not severity alone, decides what to patch first
With the affected workloads in hand, the decision becomes order. A severity score describes a vulnerability in the abstract, not its position in your environment. The production checkout service is internet-facing and handles payment data; the staging build sits behind a private network; the reconciliation job has no inbound path but holds read access to the orders database. The same advisory carries very different weight in each.
Exposure-based ordering combines the advisory with facts only your environment can supply: whether the workload is reachable from the internet, whether the vulnerable function is reachable from an entry point, what identities and data the workload can touch, and whether compensating controls sit in front of it. Here that puts production first, the reconciliation job second because of what it can read, and staging last. None of those facts comes from the advisory, so they need to live in the same graph as the component match.
CVE readiness is built before the advisory, not during it
The real measure of readiness is whether “which of our images shipped this?” can be answered without starting a scan. That depends on three things being true beforehand: SBOMs generated and retained for every image, composition linked to deployment so a match resolves to a running workload, and an exposure model that ranks the result. With those in place, an advisory becomes a query followed by an ordered patch list. Without them, it becomes a fire drill that begins with re-scanning everything.
Key takeaways
- Retain an SBOM for every image you might still be running, indexed by digest, not only for the latest build.
- Answer “which images shipped it?” by querying stored SBOMs before you consider re-scanning.
- Resolve every image match to the workloads running it, using digests rather than mutable tags.
- Order remediation by exposure and reachability, and use severity to break ties.
How SecurityVault approaches this
SecurityVault retains generated SBOMs and associates image findings with collected workload digests. This gives incident responders an inventory starting point when a new advisory appears. Confirm affected version ranges, SBOM coverage and inventory freshness; incomplete composition or deployment evidence may require additional scanning and investigation.
Choose a historical image whose package inventory and deployment history are known. Use an advisory with an explicit affected range and compare the resulting matches with an independent inspection of the image. Check what happens when a component version is missing or a workload has not reported recently. The incident team should receive a list of supported matches and unresolved questions. That is a stronger readiness measure than a fast query alone, because speed is only useful when the scope and confidence of the answer are clear.
Explore SCA and SBOM or talk to our team about an evaluation with your engineering, security and compliance stakeholders.