Container Vulnerability Management: From Scan to Verdict

Most explanations of container vulnerability management stop at “scan the image and read the report.” That is the easy ten percent. The rest of this guide is the part a report does not do for you: keeping track of a finding after the first scan, deciding what a pipeline should do about it, and answering that question the same way every time it is asked.

What is container vulnerability management?

Container vulnerability management is the practice of finding known vulnerabilities in a container image’s packages, deciding what to do about each one, and keeping that decision so it survives the next scan. The “finding what’s vulnerable” part is well understood and available for free from several open-source engines. The part that is actually hard — and the part a report has no way to represent — is the second half: who looked at this, what did they decide, and does that decision still hold.

What happens when an image is scanned?

TRUSTIVAN pulls the image from its registry — public or, with a stored credential, private — and analyses it for known vulnerabilities. Nothing in that path asks for a Docker socket or a container runtime on your infrastructure: the scanner never runs the image, and it never gets access to your build host. A scan is a durable job, not a request-response call, so it survives a worker restart instead of silently vanishing mid-run.

What is a “finding,” and why does it need an identity?

A finding is one vulnerability, in one package, in one image — but the identity that record carries is deliberately narrow. Severity, line numbers and the installed version are excluded from what makes a finding “the same finding” across scans. That is a specific design choice: if a re-rating of a CVE’s severity counted as a new finding, every re-rating would orphan the triage work already done and hand you back a decision you had already made, as if you had never made it. Because identity is derived from content rather than from an engine’s internal bookkeeping, it also survives a change of scanning engine — the decision record belongs to the product, not to whichever tool happened to produce the raw list.

What states does a finding move through?

Five, with a fixed table of legal moves between them:

From	Can move to
open	triaged, suppressed
triaged	open, suppressed
suppressed	open, triaged, suppressed (amend)
resolved	reopened
reopened	triaged, suppressed

Everything not in that table is refused. open means a scan observed it and nobody has looked yet. triaged means someone read it and accepted it into the backlog. suppressed means a risk was accepted, with a reason, an owner, and an expiry of at most two years — suppression is never open-ended. resolved means a scan that would have found it did not. reopened means it was fixed once and came back, which stays permanently distinguishable from having never been fixed.

Can someone just mark a finding as fixed?

No, and this is the rule most vulnerability tools get backwards. Resolution is a statement about evidence — a scan that would have found the vulnerability did not — and evidence is not something a person can assert by clicking a button. A “mark as fixed” control lets someone claim evidence they do not actually have, and the next scan contradicts them the moment it runs. The only way a finding closes is a rescan that no longer sees it.

What is a policy verdict?

A verdict is the answer to the one question a build actually needs: may this ship? Not “what did you find” — a report answers that, and a report is not a decision. A policy is a declarative rule set: a list of conditions (severity, finding kind, lifecycle status, fixability, advisory identifier, age, how many findings must match) that either all hold or the rule does not fire. There is no expression language, no embedded interpreter, and no customer-supplied code to evaluate — a rule fires or it doesn’t, and its effect is exactly one of fail, warn or ignore.

Evaluation is a pure function of the policy, the findings and the time, which is what makes a verdict trustworthy rather than merely plausible: the same inputs always produce the same answer, an age-based rule is testable, and a historical evaluation reproduces its historical result. A policy version cannot be edited after it exists, so the exact policy a past verdict was graded against can always be reproduced.

Does an accepted risk (a suppression) make a build pass?

Not by default. A suppressed finding still appears in every verdict as a warning unless the policy is configured otherwise. That default is a deliberate product opinion: accepting a risk is a decision to carry it, not a decision to stop knowing about it, and a build that turns green the instant someone clicks “accept” teaches a team to click rather than to think. Each policy can choose instead to treat suppressed findings as absent (ignore) or to have them block exactly like an open finding (enforce).

How does a pipeline consume the answer?

In the response body, never in the HTTP status code. Requesting a verdict succeeds with a 2xx and the verdict itself says pass, warn or fail; a non-2xx response means the request could not be answered at all, which is an infrastructure problem and calls for a different reaction than a real policy failure. Verdicts are also append-only and never recomputed — asking for one again replays the recorded decision, so two stages of the same pipeline cannot end up disagreeing about the same build.

What does this not cover?

Nothing here parses a Terraform or Kubernetes manifest for a policy violation — infrastructure-as-code scanning is a different capability and this is not it, though connecting a cloud account or a Kubernetes cluster to inventory what runs there is a separate thing TRUSTIVAN does ship. Known- exploited status is enriched onto a finding; whether the vulnerable code path is actually reachable from your application is not — that is reachability analysis, and no engine here performs it.

See the container scanning, finding lifecycle and policy and verdicts pages for the mechanism behind each answer above, or the machine API for how a pipeline calls any of it directly.