Count vulnerabilities per image and per service, not per running container. Short lived containers start and stop constantly, so counting instances inflates totals and makes the number swing with traffic. Measure the image that defines them, and how long each vulnerable image version ran in production.
Why counting instances fails
If one image with 12 findings runs as 50 replicas at noon and 5 replicas at midnight, an instance based count reports 600, then 60. Nothing changed in risk. The count moved with autoscaling. Reports built this way look dramatic and tell leaders nothing.
The stable unit is the image digest, which identifies exact content. One digest has one set of findings, regardless of replicas.
What to count instead
| Unit | Why |
|---|---|
| Image digest | Stable and unique |
| Service | The owner level for fixes |
| Unique CVE per service | Removes duplicates across images and layers |
| Exposure time | How long each vulnerable digest ran |
Report unique CVEs per service for the open list, and use exposure time to show duration.
Measure exposure time
- Record deployment events with the digest and timestamps for start and stop.
- Join each digest with its findings at the time of deployment and with later findings from new disclosures.
- For each finding, compute how long a vulnerable digest was running in production.
- Report the total and the longest for known exploited items.
This produces an honest answer to "how long were we exposed?" without depending on instance counts.
Handle new disclosures
An image built last week can be affected by a CVE published today. Because containers are replaced often, the fix for this case is usually a rebuild and redeploy, not a patch in place. Track the time between disclosure and the first deployment of a fixed digest. That is the remediation time for container workloads.
Common traps
- Scanning only at build time. Findings appear after the build. Rescan running images against fresh data.
- Counting stopped containers. Remove digests that no longer run from the open list.
- Shared base layers. One base layer issue shows up in many services. Group by layer to find the single change that closes many findings.
- Unlabeled image tags. Tags move. Use digests for the join.
Present it to leaders
One number per service for unique open CVEs, one for oldest exposure time, and a short note naming shared causes such as a base image. Ask for the one upgrade that clears the most.
Where Safeguard fits
Safeguard can help with the inputs behind this. It runs SBOM and dependency scanning, reachability analysis to separate reachable findings from the rest, and policies and gates that you set. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice how monitoring keeps checking after a build, which short lived workloads need.
Quick check
Do we still scan images at build time?
Yes, to catch issues before release. Add rescans of running digests since new CVEs appear after the build.
How do we find shared causes?
Group findings by base image and layer. A single base update often clears findings across many services.
Last reviewed: 19 October 2026.
