How to triage the findings a container scanner produces
You will not reach zero, and a programme whose goal is zero will be abandoned within a quarter. A container scanner enumerates every package present in an image and reports every known vulnerability associated with each version, whether or not your code can reach it. The number it produces is a property of your base image and the vulnerability databases, not a measure of your exposure. Triage is the work of turning that inventory into a small list of decisions, and it is the entire job.
Why is the finding count not a risk measure?
Because scanning is inventory matching. The tool reads package manifests inside the image, resolves versions, looks them up in vulnerability databases and reports every match. It does not know whether your application loads the affected library, whether the vulnerable code path needs local access you never grant, or whether the package is a build-time artefact that never executes in production. Severity scores compound this, because a published base score describes the worst plausible case across all deployments of that component rather than yours.
The consequence is that the count moves for reasons unrelated to your engineering. A quiet week upstream lowers it, a newly published advisory in a common library raises it across every image at once, and neither event tells you anything about whether your service got safer. Reporting that number to a board as a security metric guarantees a conversation about the wrong thing.
What the count is genuinely useful for is detecting neglect. If the total for a given image has not changed in four months, that image has not been rebuilt in four months, and that is a real finding about your pipeline rather than about a package.
Which signals actually separate the findings that matter?
Six, and none of them is severity on its own. Used together they reduce a list of thousands to a shortlist a team can work through in an afternoon, which is the only outcome that keeps the programme alive.
| Signal | What it tells you | Where it comes from | How to use it |
|---|---|---|---|
| Fix availability | Whether anyone can do anything today | The scanner, from distribution and ecosystem advisories | Split the list in two before anything else, it is the strongest filter |
| Known exploitation | That attacks using this are observed in the wild | The CISA Known Exploited Vulnerabilities catalogue | Treat as an escalation trigger regardless of base score |
| Exploitation likelihood scoring | A probability estimate rather than a worst case | EPSS, published by FIRST | Use to rank within the fixable pile, not as a pass or fail line |
| Reachability or loaded at runtime | Whether your process ever touches the code | Reachability analysis in the scanner, or runtime insight from the cluster | The single largest reducer of volume when your tooling supports it |
| Exposure of the workload | Whether an attacker can reach the service at all | Your own architecture, not the tool | Rank internet-facing services first, batch internal ones |
| Layer of origin | Whether the fix is a rebuild or a code change | Image layer metadata | Routes the finding to the right owner, which is most of triage |
What closes thousands of findings at once?
Rebuilding on a current base image, automatically and on a schedule. Most operating system findings in a container image have already been fixed upstream and appear only because the image was built months ago, so a weekly rebuild resolves them in bulk with nobody reading a report. This converts a triage problem into a pipeline problem, and pipeline problems are the ones this discipline is good at solving.
The multiplier is base image consolidation. If forty services build on four different bases, a single upstream fix becomes four separate decisions. If they build on one internally maintained base, one rebuild propagates everywhere and your finding count becomes a function of a pipeline you control. This is the highest-return structural change in container security and it is organisational rather than technical.
After that, a smaller base. Packages you never install cannot be reported, so minimal and distroless images carry a fraction of the surface of a general-purpose distribution image. The cost is real: no shell and no package manager breaks debugging habits and any script that expected them, so this is a migration rather than a flag.
How do you record a decision not to fix?
Formally, with a stated reason and an expiry date, and in a format the pipeline can read. Ad hoc suppressions in a scanner's web interface are lost when the tool is replaced and invisible to code review. Suppressions stored next to the code, containing who decided, on what grounds, and when the decision lapses, survive both.
The standard mechanism for asserting that a vulnerability does not affect a product is VEX, which carries statuses along the lines of not affected, affected, fixed and under investigation, plus a justification when you claim not affected. Its value is that the justification is structured and checkable later rather than a note saying this is fine. Confirm your scanners and registry consume VEX documents before committing to produce them, because support varies.
Expiry is the part that keeps the list honest. A team facing a blocked release will suppress a finding they know is irrelevant, correctly, and if that suppression is permanent then a year later nobody can say whether it still applies. Short expiries force a cheap re-decision instead of an expensive archaeological exercise.
Where should the deadline clock start?
At fix availability, not at discovery. A policy that says critical findings are remediated within seven days of detection will be breached constantly through no fault of any team, because plenty of findings have no patch for weeks. Starting the clock when a fixed version becomes available produces a target the team can actually hit, and it means your compliance figure measures your responsiveness rather than the upstream ecosystem's.
Set different clocks by exposure rather than by severity alone. An internet-facing service with a fixable finding in a loaded library deserves a short deadline. An internal batch job with the same finding in a library it never calls deserves the next scheduled rebuild. Applying one number to both is what produces policies that everyone quietly ignores.
Where a regulator or a customer contract specifies a remediation deadline, that deadline overrides your internal design, and the terms differ by jurisdiction and sector. The US federal catalogue of known exploited vulnerabilities, for example, carries binding due dates for federal agencies and is used voluntarily as a prioritisation input by everyone else. Confirm which obligations bind you before building policy around someone else's.
Why does the scanner go quiet after three months?
Because installation is a day of work and triage is permanent, and the triage job is usually unassigned. Findings route to a channel, the channel gets muted, and the platform keeps reporting into a room nobody is in. Every container security tool that has been abandoned was abandoned this way, and the failure is in the operating model rather than the product.
The second cause is that nobody owns the tool itself. Scanners need database updates, credential rotation, registry integration changes when the registry moves, and version upgrades that change finding identifiers. When a rescan silently stops covering half the registry, the dashboard still looks healthy. Put the platform in a service catalogue with a named owner and a check that alerts when the last successful scan of any repository is older than a threshold.
The test to run this week: pick three images running in production, and for each one find the date of the last successful scan and the date the image was built. If either date is older than a month, you have found the real problem, and it is not a vulnerability.
Common questions
- How do you prioritise container vulnerability findings?
- Filter on fix availability first, since nothing else can be acted on today. Escalate anything listed in the CISA Known Exploited Vulnerabilities catalogue regardless of its base score. Rank the remainder using exploitation likelihood scoring such as EPSS, whether the affected code is reachable from your application, and whether the workload is internet-facing. Finally use the image layer to route the finding, because layer of origin decides whether the fix is a rebuild or a code change.
- Is the number of container vulnerabilities a useful metric?
- Not as a risk measure. It moves when vulnerability databases are updated rather than when your engineering changes, so it rises across every image at once when a common library gets an advisory. It is useful for one thing: if an image's total has not changed in months, that image has not been rebuilt in months, which is a real finding about the pipeline.
- What reduces container findings the most?
- Automated weekly rebuilds on a current base image, because most operating system findings are already fixed upstream and appear only because the image is old. Consolidating many services onto one internally maintained base multiplies the effect, since a single rebuild then propagates everywhere. Moving to a minimal or distroless base reduces the surface permanently, at the cost of losing the shell and package manager your debugging habits may depend on.
- What is VEX and do you need it?
- VEX is a structured way of stating whether a product is actually affected by a given vulnerability, using statuses such as not affected, affected, fixed and under investigation, with a justification required when you claim not affected. Its value over an ad hoc suppression is that the justification is machine readable and checkable later. Confirm your scanner and registry consume VEX documents before committing to produce them, as support varies.
- When should a remediation deadline start?
- When a fix becomes available, not when the finding is discovered. Deadlines measured from discovery are breached routinely because many findings have no patch for weeks, which means your compliance figure ends up measuring the upstream ecosystem rather than your team. Set different windows by exposure: short for internet-facing services with a reachable finding, the next scheduled rebuild for internal workloads that never load the affected code.
- Why do container security platforms stop being maintained?
- Two reasons. Triage goes unassigned, so findings route to a channel that gets muted while the tool keeps reporting to nobody. And the platform itself has no owner, so database updates, registry integration changes and credential rotations lapse until rescans silently stop covering part of the registry while the dashboard still looks healthy. Both are fixed by a named owner plus an alert when any repository's last successful scan ages past a threshold.
