Source
Commit, repository, owner, dependency manifests, build definition, and approved branch.
Artifact identity, workload exposure, and runtime proof
Cloud Workload, Container, and Image Vulnerability Scanning
Cloud workload vulnerability scanning is credible only when your team can prove which image digest was assessed, which digest was deployed, where it is running, what the scanner could inspect, and which risks remain outside image-package analysis.
Identify the artifactRecord the immutable digest, registry, architecture, build, and provenance.
Map what is runningConnect deployed workloads, namespaces, clusters, accounts, regions, and owners.
Cover the blind spotsAdd host, configuration, identity, application, secret, and runtime controls.
“The image was scanned” is not closure. The defensible statement is: the exact immutable artifact running in the approved environment was assessed with known coverage, prioritized in context, remediated or governed, and verified again.
One artifact, several security decisions
Follow the workload from source to runtime without losing its identity
A tag can move. A build can change. A multi-architecture manifest can resolve differently. The evidence chain should preserve the identity of the artifact as it moves through controls.
Build
Builder identity, base image, packages, architecture, SBOM, signatures, and attestations.
Registry
Repository, immutable digest, tag history, scan status, timestamps, and retention policy.
Admission
Policy result, exception, signature decision, environment, and deployment authorization.
Runtime
Cluster, namespace, workload, pod or task, node, account, region, and active digest.
Closure
Rebuilt artifact, new digest, rollout proof, old-instance removal, and verified risk disposition.
Immutable identity
Prove the scanned digest is the deployed digest
Kubernetes documents why a digest identifies a specific image version, while a mutable tag can later point to different code. Use the digest as the join key across build, registry, admission, inventory, findings, tickets, and rescan evidence.
registry.example/team/service@sha256:3f6…9b2
build: 2026.07.11.1842
architecture: linux/amd64
environment: production-west
build: 2026.07.11.1842
architecture: linux/amd64
environment: production-west
01
Record both tag and digest
The tag helps people recognize a release; the digest proves which bytes were assessed and deployed. Do not treat one as a substitute for the other.
02
Resolve image indexes by platform
For multi-architecture images, identify the manifest and architecture-specific image that each runtime pulled. Coverage for one platform does not prove coverage for another.
03
Reconcile registry and runtime inventory
Find running images absent from the approved registry, stale workloads using older digests, sidecars and add-ons outside the release pipeline, and images that escaped the normal gate.
04
Verify the old artifact left the environment
A clean replacement image does not reduce exposure if vulnerable replicas, jobs, nodes, serverless revisions, cached tasks, or rollback targets still execute the old digest.
Six coverage planes
An image scan covers packages—not the entire cloud workload
NIST SP 800-190 describes security concerns across the container technology stack. A practical program needs several coordinated lenses because each one answers a different question and produces a different kind of evidence.
Image composition
Operating-system and language packages, versions, dependency paths, known vulnerabilities, secrets where supported, malware where supported, licenses, and unsupported software.
- Confirm supported distributions and package types.
- Record unrecognized or unscannable content.
Build and supply-chain trust
Source-to-build relationship, base-image origin, reproducibility, builder identity, SBOM quality, signatures, attestations, and protected pipeline controls.
- Scanning does not prove origin or integrity.
- Preserve attestations with the digest.
Registry governance
Repository scope, push and rescan behavior, retention, immutability, cross-account copies, private-registry access, stale results, and images outside supported repositories.
- Prove every required repository is enabled.
- Monitor scan age and coverage state.
Deployment configuration
Privileged mode, capabilities, seccomp or equivalent, read-only filesystems, secrets mounts, service accounts, network policies, resource controls, and admission decisions.
- Most settings do not exist inside the image.
- Review manifests and live workload state.
Host and cloud control plane
Node operating systems, managed control planes, cloud IAM, registry permissions, KMS, logging, private endpoints, cluster configuration, and account-level exposure.
- The shared-responsibility boundary varies.
- Keep account and cluster ownership visible.
Runtime behavior
Executed binaries, unexpected process trees, file changes, network connections, credential access, exploit behavior, drift, and active attack signals.
- A clean image can be abused at runtime.
- Runtime detection is not package scanning.
Coverage and closure matrix
Know what each control can prove—and what it cannot
Use this matrix during architecture review, scanner evaluation, control testing, and incident follow-up.
The full matrix remains available inside this scroll frame. Use the visible right and bottom scrollbars to review every column.
| Control question | Strong evidence | Common false confidence | Additional control | Closure proof |
|---|---|---|---|---|
| Which artifact was assessed? | Digest, registry path, manifest architecture, scan engine, rule/feed version, scan time, and status | Only a mutable tag, screenshot, or release name | Build provenance and registry API evidence | Finding and deployment records join on the same digest |
| What packages were inspected? | Inventory/SBOM, supported package ecosystems, file paths, layers, and unrecognized content | Assuming “scan completed” means every file and package was understood | Coverage test images and independent inventory comparison | Known supported and excluded content documented |
| Is the image running? | Runtime inventory mapped to cluster, namespace, workload, account, region, and digest | Prioritizing every registry finding as production exposure—or ignoring unused artifacts entirely | Registry-to-runtime reconciliation | Active and non-active artifact states recorded with owner and environment |
| Is the workload securely configured? | Live manifest, policy evaluation, effective service account, privilege, mounts, network and secret configuration | Equating a package-only image scan with workload hardening | Kubernetes/cloud posture assessment and manual review | Effective configuration rechecked after deployment |
| Is the host layer covered? | Node/host inventory, OS vulnerability status, control-plane responsibility, patch state, and exceptions | Assuming the managed platform removes every host responsibility | Cloud-native host assessment and provider responsibility mapping | Affected node pool rebuilt, patched, or governed and rescanned |
| Was the vulnerable code executed? | Reachability analysis where reliable, runtime telemetry, process/network evidence, and application context | Calling a package present “exploited,” or calling it safe solely because execution was not observed | Application testing and threat detection | Risk decision cites reachability limits and runtime evidence |
| Did remediation reach production? | New digest, deployment rollout, replica/task/revision inventory, and removal of the old digest | Closing when a pull request merges or a new image reaches the registry | Deployment and configuration validation | Targeted rescan plus runtime inventory proves the replacement is active |
| Can the old image return? | Rollback targets, cached jobs, dormant revisions, autoscaling templates, recovery artifacts, and registry retention | Checking only currently healthy replicas | Rollback and disaster-recovery review | Old digest blocked, removed, or explicitly governed |
Cloud-provider reality
Verify enabled features, supported scope, scan age, and runtime mapping
Cloud-native capabilities change. Confirm the current product documentation, account configuration, service tier, permissions, supported registries, package ecosystems, and data freshness rather than assuming a checkbox creates complete coverage.
Microsoft Azure and multicloud Defender
Microsoft documents separate requirements for registry image assessment and vulnerability assessment of running images. It also identifies limitations such as an unscanned container runtime layer and conditions that can cause partial results.
Review supported Defender for Containers assessment behavior
Amazon ECR and Inspector
AWS distinguishes basic ECR scanning from Amazon Inspector enhanced scanning. Enhanced scanning can cover operating-system and programming-language packages and can operate continuously when configured for the repository.
Google Artifact Analysis and SCC
Google Artifact Analysis scans container dependencies and continuously updates findings within documented activity windows. Security Command Center can add workload and runtime context depending on the enabled service and tier.
Current Google Cloud transition: Google’s documentation states that GKE Advanced Vulnerability Insights was scheduled for shutdown on June 16, 2026. Teams that relied on the retired GKE posture-dashboard capability should verify replacement coverage through Artifact Analysis, Security Command Center, other approved controls, and their own registry-to-runtime reconciliation. Review Google’s published transition notice.
Worked coverage scenario
A rebuilt image is not remediated until the rollout and exposure are verified
This fictional example shows how a finding should move across engineering, cloud operations, security, and evidence records.
Example: vulnerable library in a customer-facing service
- The registry scanner identifies a vulnerable language package in digest A. The record includes the dependency path, fix availability, scan age, and the image’s supported/unsupported content.
- Runtime inventory shows digest A in a public production service, a non-public worker, an inactive rollback revision, and a scheduled job. The external service receives the highest exposure priority.
- Engineering updates the dependency and rebuilds digest B from the approved source and base image. The pipeline produces a new SBOM and attestation.
- Admission policy allows digest B. Deployment evidence shows the public service and worker rolled forward, while the scheduled job still references digest A.
- The ticket remains open. Operations updates the job, removes or governs the rollback reference, verifies no active workload uses digest A, and runs a targeted rescan of digest B.
- Closure preserves both the clean rescan and the runtime rollout evidence. If any accepted exception remains, it carries an owner, compensating controls, expiry, and reopen trigger.
Minimum evidence pack
Preserve the facts needed to reproduce the security decision
A screenshot of a clean dashboard is not enough. The record should remain useful after tags move, tools change, staff rotate, or an auditor asks how coverage was established.
Scope and ownership
Cloud account/subscription/project, region, registry, repository, cluster/service, namespace, workload, environment, business owner, technical owner, and criticality.
Artifact identity
Digest, tag history, manifest architecture, source commit, build, base image, SBOM, signature/attestation, and registry timestamps.
Assessment context
Scanner, engine/rules/feed version, scan trigger, time, supported content, exclusions, errors, result status, and freshness.
Exposure context
Running workload count, public reachability, privileges, service account, data sensitivity, network path, exploit evidence, and compensating controls.
Remediation record
Owner, due date, rebuilt digest, deployment change, exception approval, expiry, mitigation, rollback treatment, and implementation evidence.
Closure and monitoring
Targeted rescan, runtime reconciliation, old-digest removal, remaining risk, future-rescan trigger, and conditions that reopen the finding.
Connect adjacent security work
Carry cloud findings into prioritization, remediation, and application testing
Use CVSS, EPSS, KEV, exposure, and business context to build the remediation queue. Then apply a governed remediation SLA with rescan and closure evidence.
Package analysis cannot validate authorization, business logic, exposed routes, or runtime application behavior. Use web application and API vulnerability scanning where the workload exposes an application interface, and validate the scan report’s scope, health, and evidence before accepting its conclusions.
Cloud and container scanning questions
Clarify identity, coverage, freshness, and closure before relying on the result
Is container image scanning the same as cloud workload vulnerability scanning?
No. Image scanning primarily analyzes content packaged in an image. Cloud workload vulnerability scanning should connect that artifact to the environment where it runs and add configuration, identity, host, cloud-control-plane, application, and runtime evidence appropriate to the platform.
Why should we track the image digest instead of only the tag?
A tag is a human-friendly pointer that can later move to another image. A digest identifies specific image content. Record both, but use the digest to prove which artifact was scanned, admitted, deployed, remediated, and rescanned.
Does a clean registry scan prove the running workload is clean?
Not by itself. Prove the running workload uses the scanned digest, confirm the correct architecture, review scan freshness and limitations, and assess deployment settings, host/cloud controls, application behavior, secrets, and runtime risk that a package scan cannot cover.
How often should container images be rescanned?
Scan during the build or before admission, on registry push where supported, and continuously or on a defined cadence as new advisories appear. Trigger additional scanning when the base image, package inventory, threat intelligence, production exposure, platform configuration, or tool coverage changes.
What should close a container vulnerability finding?
Closure should identify the replacement digest, targeted rescan result, deployment rollout, runtime inventory, treatment of old images and rollback targets, remaining exceptions, and any conditions that would reopen the finding. A merged pull request or retagged image is not sufficient proof.
Can one cloud-native scanner cover Azure, AWS, Google Cloud, Kubernetes, and serverless workloads completely?
Do not assume so. Supported registries, package types, architectures, runtime services, activity windows, permissions, tiers, and limitations vary. Build a requirements matrix, test representative artifacts and workloads, and document the controls used to cover each gap.
Turn cloud scan data into verified workload risk decisions
OC Security Audit can review registry and runtime coverage, artifact identity, scan configuration, cloud-control gaps, prioritization, exceptions, and closure evidence—so leaders know what was assessed, what is actually running, and what needs action first. The review is guided by Ali Hassani, CISO, with 25+ years of IT, cybersecurity, cloud, network, and compliance experience.