A scanner that reports “412 vulnerabilities” has told you nothing you can act on at five on a Friday. The useful question is narrower: what in this image is serious, and which version makes it go away?
Scanned on push
Every push to a tag is scanned with Trivy as it lands. The repository list shows the counts that matter — critical, high, never scanned, signed or not — so the image that needs attention is visible before anybody opens it. A scan that fails says it failed; it is never shown as clean.
Findings that name the fix
Each finding carries its CVE, the package, the version installed and the version that fixes it — or says there is no fix yet. Up to 200 findings are kept per image, worst first, and critical or high results notify the workspace owners in the app and by email.
acme/api:1.4.0 scanned on push
critical openssl 3.0.11 → 3.0.14
critical libexpat 2.5.0 → 2.6.3
high zlib 1.2.13 → no fix yetWhy it doesn’t block the push
A scanner that refuses pushes turns a CVE published overnight into a broken release pipeline the next morning. So scanning informs and never blocks, and the decision to deploy stays where it belongs — in your pipeline, or in your cluster.
Signatures that mean something
A signature is a claim that someone vouched for exactly this image. Each workspace signs with its own cosign key, held in AWS KMS, Google Cloud KMS, Azure Key Vault or HashiCorp Vault — or uploaded, encrypted at rest and never written to disk. Signatures pushed from your own CI are recognised as signatures rather than listed as stray tags, and retention never prunes them.
Enforcement lives with whoever consumes the image:
$ cosign verify --key cosign.pub registry.subnomic.com/acme/api:1.4.0What a scan is not
A signed image with a critical CVE is a signed image with a critical CVE. And a tag is not a promise — pushing the same tag again moves it — so deploy by digest when it matters which bytes run.
See Registry, Container registry and Image security.