A first scan of a real image produces a long, undifferentiated list. By the end of this tutorial you will have worked one image’s findings into a state where the list means something: what you are looking at, what you have accepted and until when, and what you have not touched. You need a completed scan and a session in the dashboard, or the cookie file from the Quickstart. Allow about twenty minutes.

​
1. See the size of the problem

order=severity is the backlog view — worst first, which is how a person reads a list they intend to work through. It sorts by a value that changes, so it is not the order to enumerate with; that distinction matters later and is covered in Enumerate findings safely. Now look at the top of it:
Everything starts as open. open means nobody has looked, which is the only honest starting state.

​
2. Narrow to what you can act on

Before triaging anything, cut the list down to the part where action is possible.
A finding whose advisory names a fixed version is one you can do something about today. TRUSTIVAN reports fixability as fixable or unknown and never guesses unfixable: absence of a fixed version in the data is not evidence that no fix exists, and a tool that treated it as such would hide exactly the findings nobody has looked at.

​
3. Triage the ones you are taking on

Triaging says “this is on someone’s list”. It is a queue position, not a decision, and it moves a finding out of “nobody has looked” without asserting anything about the risk.
Repeat for a handful. When there are more than a handful, one request handles up to 500 of them — see Triage in bulk. Requesting the state a finding is already in succeeds and writes nothing. A retried request, a double-clicked button and a stale browser tab all produce exactly that, and answering 409 to any of them would read as a race that is not happening.

​
4. Accept one risk, with a reason and an end date

Somewhere in the list is a finding you are not going to fix — a vulnerable package your image ships but never calls, or a detection that is simply wrong. Suppression is how that decision is recorded.
The reason is mandatory. It is the entire audit value of the action: an acceptance nobody wrote down is indistinguishable, six months later, from somebody clicking a button to make a number go down. The expiry is optional but almost always right. An accepted risk is a judgement about a business context that changes, so it should come back for review; a false positive is a statement about the detection being wrong, which will still be true next year, and permanent suppression is the honest answer there. Explicit expiries are bounded at two years, because without a ceiling “expires 31 December 9999” is permanent suppression wearing a costume. Suppression is held to a higher bar than triage — it is the one action whose misuse is invisible by design, since it removes a real vulnerability from the backlog, the severity counts, and eventually the gate that blocks a release.

​
5. Notice what you cannot do

Try to close a finding you have fixed:
That is refused, and the refusal is the design. resolved means “a scan that would have found this did not” — a statement about evidence. A button that set it would let a person assert evidence they do not have, and the next scan would contradict them by reopening it. So there are two ways to close something, and which one you use says what happened:
  • Something you decided not to fix: suppress it, with a reason. That is step 4.
  • Something you have fixed: rebuild the image and rescan. The absence speaks.
Two further refusals follow from the same reasoning. A resolved finding cannot be suppressed — there is nothing to suppress, it is already closed. And a reopened finding cannot be downgraded to open: reopened records that something was fixed once and came back, which is the most interesting fact a vulnerability programme produces, and relabelling it would erase a regression from the backlog while the timeline still said it happened.

​
6. Fix something and rescan

Rebuild against a newer base image, then scan it:
When the scan finishes, look at the findings again. The scan did not produce a fresh list: it was reconciled against what already existed on the asset. A finding the new scan still sees keeps its row, its identity and every decision you recorded against it. One it no longer sees becomes resolved. One that was resolved and is seen again becomes reopened. Your suppression from step 4 survived, because a finding’s identity is derived from its content — which advisory, which package, which install path — and deliberately excludes everything that changes while the issue does not: severity, the installed version, even the engine that found it.

​
7. Read the record

Every state change you made is here, append-only and enforced by the database rather than by a comment in the code. Each event names its actor structurally: actor_user_id for a person, actor_api_key_id for a machine, scan_id for a scan, and none of them for an unattended system action such as a suppression expiring. That last case is worth knowing about now rather than discovering later. When the expiry you set in step 4 arrives, a sweep returns the finding to the backlog and records suppression_expired — not unsuppressed. The two are different facts, and only one of them means a human has looked. The lapsed reason is copied onto the expiry event, because the finding no longer carries it.

​
What you have now

One image’s backlog in a state that survives the next scan: triaged work that is visibly somebody’s, one accepted risk with an owner, a reason and an end date, and a timeline that can answer “why is this not in the list any more” without anyone having to remember. From here: