Reviewing an unchanged container again

Most submissions are not the first submission of a container. A build comes back after a rejection, a new tag is cut, or a routine rescan runs. Each of these opens a new review, and Attest is built so that a second review takes as long as the change deserves rather than as long as the first one did.

The delta

Every scan run is compared with the previous run for the same container at the same deployment level. The package header says what changed.

Line	Meaning
N resolved, M new	Findings that closed since the last run, and findings that were not there before.
Unchanged since pipeline P	Same findings as the previous run.

New findings are marked in the evidence and listed first. Resolved findings are listed too, so the record shows that they were closed rather than simply disappearing.

Reviewing against the delta

Your earlier decisions carry forward as context, not as decisions. A finding you accepted on the previous run shows your earlier basis next to it and asks you again. If nothing has changed, confirming it takes a few seconds. If the developer's justification changed, you can see the difference.

The record for the new run references the previous run and notes that the review was made against the delta. That is why a second review is quick, and the record says so.

Unchanged submissions

When the pipeline recognizes that a container has not changed, the review merge request is labelled accordingly and the console shows it. The review is still yours to record; the label just tells you where to spend your attention.

Regressions

A container that was authorized can regress on its next scan. A newer build might run as root, or a fresh vulnerability database might match a new CVE in a package that has not changed. The delta shows it as new and the verdict reflects it. The authorization already on record is unchanged, because it was a decision about the run it was made on.