A scan result belongs to an artifact and an observation time
A vulnerability report is useful only when it refers to the image actually being considered or run. Container tags can move, while a digest identifies an immutable image. Start by linking the deployed or candidate digest to its scan evidence before interpreting a severity count shown under a familiar tag.
Google documents automatic and on-demand scanning with different analysis lifecycles. Coverage depends on supported package information and configured scanning behavior. A report without findings is not proof that the application has no exploitable weakness, and an older report should not be presented as a current assessment without checking its state.
Prepare evidence for a release decision
- Record the image digest, repository, source commit and package inventory available for review. Identify who owns the base image and application dependencies.
- Verify the intended scanning configuration and result state for that artifact. Keep automatic analysis and a one-time on-demand result distinct in the release record.
- Define a review process for findings, exceptions and remediation. Keep an accepted recovery image and a test plan for dependency updates.
For beginners, severity describes one aspect of a finding. The operating team also needs package location, available fix, application usage and the decision owner. A dashboard count alone cannot explain the production risk or select a safe update.
Illustrative incident: the tag points to a different image
A pipeline scans one image, then a mutable release tag is moved to another build before deployment. An operator reads the earlier scan and assumes it covers the running workload. This is an illustrative scenario. Adding another label to the image does not establish that the expected digest was assessed and released.
Trace the finding to the package and runtime
Compare candidate, scanned and deployed digests. Inspect scan completion or failure state and the age of the evidence. Identify whether a flagged package comes from the base image, a direct dependency or a transitive dependency so the correct maintainer can act.
| Observation | Evidence | Decision |
|---|---|---|
| Tag is familiar, digest differs | Registry and deployed digest | Reconcile artifact identity |
| No findings but scan incomplete | Scan status and configuration | Obtain usable evidence |
| Package is not directly declared | File or dependency provenance | Identify owning layer |
| Fix changes runtime behavior | Candidate tests and compatibility evidence | Review release risk |
Do not assume that enabling a scanner automatically enforces a deployment gate. Artifact assessment and admission or release policy must be wired together deliberately. Preserve failed scan states rather than converting them into a successful zero-finding result.
Remediate the candidate and retain the decision trail
For the illustrative digest mismatch, rebuild the release evidence around the exact candidate and deploy that accepted digest through the normal process. For a demonstrated package finding, update the responsible dependency or base image, then rerun relevant application tests and obtain new scan evidence.
Verify the deployed workload uses the accepted digest. Record unresolved findings with a named risk owner and review date instead of silently suppressing them. Test that a deliberately non-compliant candidate is handled according to the release policy, including scanner failure behavior.
Operating objective and scanning SOP
Measure coverage of released digests, evidence freshness and remediation decisions. An illustrative internal gate could require every candidate digest to have completed supported assessment and an explicit disposition before release. It is an engineering control, not a security certification or a guarantee that all vulnerabilities are detectable.
The SOP should retain digest, scan mode, state, evidence time, package owner, exception rationale and test result. Escalate uncertain findings and unavailable fixes to the risk owner. Review scanning coverage after language or base-image changes rather than assuming a previously useful assessment covers every new package format.
See Clouvenix engineering support for scope based on documented requirements and acceptance evidence.
Technical reference
Google Cloud: container scanning overview and Artifact Analysis overview. Reviewed 19 October 2026; check prerequisites against the product configuration and software version in use.