What is container image scanning? How it works, best practices, and top tools

Container image scanning is the automated analysis of a container image’s layers, operating system packages, application dependencies and build configuration against vulnerability databases. It finds known CVEs, embedded secrets and risky settings before the image runs in production. Every image inherits code from a base image and pulls in open-source libraries nobody on the team reviewed line by line, so the image is the most practical checkpoint in the software supply chain. Image-only scanning is still incomplete. It reports what is installed, but it cannot tell you what is loaded, exposed or under attack. This guide, current as of October 2026, explains how scanners work internally, where they fall short, how to add them to CI/CD and Kubernetes, and which tools to consider.

What container image scanning covers, and where it stops

Container image scanning covers the static contents of an image: OS packages, language libraries, binaries and image metadata. Secret detection, IaC checks, license compliance, malware detection, registry rescans and runtime monitoring are adjacent capabilities. Many vendors bundle all of these under the broader label “container security scanning,” which is why the two terms often get used as if they meant the same thing.

The distinction matters when you buy or build a pipeline. A container vulnerability scanner that only matches packages to CVEs will not flag an AWS key baked into a layer, a Kubernetes manifest that grants privileged: true, or a cryptominer started by a compromised process.

Static, registry and runtime scanning compared

The same image gets evaluated at three points in its life. Each point sees something different. Registries such as Harbor can scan Docker images for vulnerabilities on push, which keeps findings current for images that are no longer being rebuilt. Our guide to registry vulnerability scanning covers that layer in more depth.

How container image scanning finds vulnerabilities

Container image scanning finds vulnerabilities by unpacking an image into its filesystem, building an inventory of every OS and language package, and comparing each package version against vulnerability advisories. A scanner runs the steps below in order. Most false positives and false negatives trace back to one of them.

1. Resolve the image. The scanner pulls the image by tag or digest and reads the OCI manifest and config JSON, which list the layers, environment variables, user and exposed ports.
2. Extract and flatten layers. Each layer is a tar archive. The scanner applies them in order and honors whiteout files (.wh.*) so a package deleted in a later layer is not reported. Good scanners also record which layer introduced each package, so fixes target the right Dockerfile line.
3. Detect the OS. Files such as /etc/os-release or /etc/alpine-release identify the distribution and release, for example Debian 12 or Alpine 3.20. Distro version decides which advisory feed applies.
4. Enumerate OS packages. The scanner parses the package database: /var/lib/dpkg/status for Debian and Ubuntu, the RPM database for RHEL, Fedora and Amazon Linux, and /lib/apk/db/installed for Alpine.
5. Parse language manifests and binaries. It reads package-lock.json, requirements.txt and Python METADATA files, Gemfile.lock, Cargo.lock, pom.properties inside JARs (including nested fat JARs), and Go build info embedded in compiled binaries.
6. Normalize identifiers. Each component is expressed as a package URL (for example pkg:deb/debian/[email protected]~deb12u2) or a CPE string. Package URLs map cleanly to ecosystem advisories. CPEs are what NVD uses, and they are fuzzier.
7. Correlate with advisories. Versions are compared to affected ranges using each ecosystem’s rules: dpkg epochs, RPM epoch-version-release, or semver. Treating 1:2.3 as a plain string is a classic source of wrong results.
8. Filter and report. The scanner applies distro “not affected” statuses, VEX statements and ignore lists. It then outputs each finding with severity, CVSS score, fixed version and originating layer, in formats such as JSON, SARIF, CycloneDX or SPDX.

Vulnerability databases and advisory sources

For prioritization, many teams add CISA’s Known Exploited Vulnerabilities (KEV) catalog and FIRST’s EPSS exploit-probability scores on top of these sources.

SBOMs and rescanning when new CVEs appear

A software bill of materials (SBOM) is the package inventory from steps 4 to 6, saved as a file. The two dominant formats are SPDX, a Linux Foundation standard (ISO/IEC 5962) with strong license detail, and CycloneDX, an OWASP standard built for security use cases that also supports VEX data. Tools such as Syft or trivy image --format cyclonedx generate them at build time.

SBOMs change how you respond to a new CVE. When Log4Shell (CVE-2021-44228) hit, teams without inventories had to pull and unpack every image to look for log4j-core, often buried inside fat JARs. With stored SBOMs, you rerun matching against updated feeds (for example grype sbom:./api-sbom.cdx.json) and get a list of affected images in minutes.

Limitations of image scanning

• Unfixed CVEs: Many findings have no patched version yet, or the distro marks them “won’t fix.” Blocking on these stalls every build.
• Distro backports: Red Hat and Debian patch old versions without bumping the upstream number. NVD-only matching then flags fixed packages as vulnerable.
• Noisy matches: CPE collisions attach CVEs to the wrong product, for example a Python package that shares a name with an unrelated C library.
• Secret and malware gaps: CVE matching cannot see credentials or malicious binaries. Those need dedicated detectors.
• Private dependencies: Internal packages have no public advisories, so they always look clean.
• Distroless, scratch and copied binaries: Images without a package database, or with tools fetched via curl in a RUN step, leave the scanner nothing to enumerate unless it reads binary metadata.
• Point-in-time results: A scan only reflects CVEs known when it ran. An unchanged image can fail tomorrow.

Container image scanning in CI/CD, GitHub and Kubernetes

Container image scanning in CI/CD runs a scanner right after the image is built, fails the job when findings exceed a threshold, and publishes results to the platform’s security view. Kubernetes admission policies then refuse anything that skipped those checks. The patterns are similar across platforms, and only the syntax changes.

GitHub Actions

Build the image, scan it by commit SHA, and upload SARIF results so findings appear in GitHub code scanning.

- name: Build
  run: docker build -t ghcr.io/acme/api:${{ github.sha }} ., name: Scan image
  uses: aquasecurity/trivy-action@master   # pin a release tag or SHA
  with:
    image-ref: ghcr.io/acme/api:${{ github.sha }}
    severity: CRITICAL,HIGH
    ignore-unfixed: true
    exit-code: '1'
    format: sarif
    output: trivy.sarif, name: Upload results
  if: always()
  uses: github/codeql-action/upload-sarif@v3
  with:
    sarif_file: trivy.sarif

Other GitHub options work the same way. The NeuVector image scan action takes image-repository and image-tag inputs, plus fail thresholds such as min-high-cves-to-fail: "1". It can also scan remote registry images using registry credentials stored as secrets. The open-source vimp tool wraps Grype, Trivy or Snyk (vimp scan --image <image>) and supports SARIF output for GitHub code scanning.

GitLab CI

GitLab ships a built-in Jobs/Container-Scanning.gitlab-ci.yml template. A custom job with Grype looks like this:

container_scan:
  stage: test
  image: alpine:3.20
  script:
    - apk add --no-cache curl
    - curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin
    - grype registry:$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA --fail-on high -o table

Jenkins

Red Hat’s OpenShift image signing and scanning example uses the same flow in Jenkins, scanning after build and before deployment. It also uses a controller that scans images automatically when they are pushed to the registry.

stage('Scan image') {
  steps {
    sh 'trivy image --exit-code 1 --severity CRITICAL,HIGH --ignore-unfixed acme/api:${GIT_COMMIT}'
  }
}

Signed images and attestations

A scan result is only useful if the image you deploy is the image you scanned. Sigstore’s Cosign signs the image digest and can attach the scan report as a signed attestation.

cosign sign --key cosign.key ghcr.io/acme/api@sha256:4f1c...
trivy image --format cosign-vuln -o vuln.json ghcr.io/acme/api@sha256:4f1c...
cosign attest --key cosign.key --type vuln --predicate vuln.json ghcr.io/acme/api@sha256:4f1c...

Signing proves who built the image. The attestation proves it was scanned, and when. SLSA provenance attestations add which source commit and builder produced the image. Keyless signing with Fulcio certificates and the Rekor transparency log removes the need to manage long-lived keys.

Kubernetes admission policies

Kyverno can verify signatures at admission and rewrite tags to digests, so a re-pushed tag cannot swap the image afterward.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-signed-images
spec:
  validationFailureAction: Enforce
  rules:
    - name: verify-cosign-signature
      match:
        any:
          - resources:
              kinds: [Pod]
      verifyImages:
        - imageReferences: ["ghcr.io/acme/*"]
          mutateDigest: true
          attestors:
            - entries:
                - keys:
                    publicKeys: |-
                      -----BEGIN PUBLIC KEY-----
                      ...
                      -----END PUBLIC KEY-----

Kyverno verifyImages rules can also check the vuln attestation, for example rejecting images whose scan is older than 7 days. With OPA Gatekeeper, teams typically pair constraint templates such as allowed repositories and disallowed :latest tags with an external data provider such as Ratify for signature verification.

Best practices: thresholds, SLAs and remediation

Gate builds on fixable, high-impact findings, set remediation deadlines by severity and exposure, and fix problems by rebuilding images rather than patching running containers. That is the best practice for container image scanning. Blocking on every CVE trains developers to bypass the scanner. Blocking on nothing turns scanning into a reporting exercise.

Policy thresholds and SLAs by severity

The table below is an example policy that many teams adapt. Tune the windows to your risk appetite and compliance obligations.

Runtime context should reorder that queue. A simple prioritization rule looks like this:

priority = severity_rank(cve)                 # critical=4 ... low=1
if cve.in_kev or cve.epss > 0.1:   priority += 2
if package.loaded_at_runtime:      priority += 2
if workload.internet_exposed:      priority += 1
if not package.loaded_at_runtime and not cve.in_kev:
    priority = min(priority, 2)               # defer dormant code

For example, a high-severity OpenSSL CVE in an internet-facing API pod that loads libssl outranks a critical CVE in a perl package that never executes in a batch job. Ranking by exposure first is how mature container vulnerability management works.

Remediation workflows

1. Rebuild from a patched base image. Most OS findings come from the base image. Bump FROM debian:12 to the latest point release and rebuild, rather than running apt-get upgrade on top of a stale base.
2. Pin by digest, not tag. FROM python:3.12-slim@sha256:... makes builds reproducible. Let Renovate or Dependabot open pull requests when the digest changes.
3. Shrink the attack surface. Slim, distroless or Chainguard-style minimal bases drop shells and package managers. Use multi-stage builds so compilers never reach the final image.
4. Update application dependencies. Bump the direct dependency that pulls in the vulnerable transitive package, then regenerate lockfiles.
5. Handle exceptions formally. Record unfixed or non-exploitable findings as VEX or ignore entries, each with an owner, a justification and an expiry date.

• ✓Scan the same image at build, in the registry on a schedule, and at admission.
• ✓Generate and store an SBOM for every released image digest.
• ✓Use , ignore-unfixed or its equivalent at the CI gate, but track unfixed CVEs separately.
• ✓Run containers as non-root and drop the scanner’s config findings into the same SLA queue.
• ✓Rebuild active images at least weekly, even without code changes, to pick up base-image fixes.

Top container image scanning tools

The leading container image scanning tools fall into two groups. Open-source scanners (Trivy, Grype, Clair) are strong at build-time checks, and commercial platforms (Upwind, Snyk Container, Prisma Cloud, Aqua Security and Wiz) add registry coverage, runtime context and prioritization. Many teams run one of each type.

Upwind

Upwind is a CNAPP built around runtime data. It combines agentless cloud discovery with lightweight eBPF sensors on VMs, containers and serverless workloads. For image scanning, it plugs into CI/CD pipelines and IaC scanning, provides SBOM visibility, and ranks CVEs by reachability, whether the affected package is actually loaded, internet exposure and exploitability. It can also trace a runtime finding back to the code or configuration that introduced it. One Gartner Peer Insights reviewer wrote that “Upwind found some significant vulnerabilities that were being missed by other products we use for security scanning.” Upwind is rated 4.8/5 from 88 reviews on Gartner Peer Insights as of October 2026.

Trivy

Trivy is an open-source scanner maintained by Aqua Security. It scans container images, filesystems, Git repositories, IaC files and Kubernetes clusters for vulnerabilities, misconfigurations and secrets, and outputs SARIF, CycloneDX and SPDX. Its single binary and offline database mode make it the default CI gate for many teams. It has no runtime context of its own.

Grype

Grype is Anchore’s open-source vulnerability scanner. It pairs with Syft, which generates SBOMs. Grype can scan an image directly or scan a stored SBOM, so it works well for rescanning a fleet when a new CVE lands. Its , fail-on flag gives simple severity gating.

Clair

Clair is an open-source static analyzer that indexes image layers and matches them against advisory feeds through an API. It powers scanning in Red Hat Quay. It fits registry-side scanning better than developer workstations or quick CI jobs.

Snyk Container

Snyk Container is a commercial scanner aimed at developers. It integrates with registries, CI and source repositories, and is known for recommending alternative base images with fewer vulnerabilities. It suits teams that want developers to own fixes directly.

Prisma Cloud (Palo Alto Networks Cortex Cloud)

Cortex Cloud scans IaC templates and Dockerfiles, runs SCA with license compliance checks, integrates with CI/CD pipelines, and traces runtime findings back to code. It prioritizes CVEs by reachability, loaded packages, internet exposure and exploitability. Gartner Peer Insights reviewers praise its Kubernetes and CI/CD coverage. Several also report that custom workflows, API integrations and alert tuning take significant setup work, and some describe the cost as steep.

Aqua Security

Aqua covers image scanning, secrets, malware detection, virtual patching, image assurance policies and digitally signed SBOMs, with eBPF-based runtime protection. Reviewers describe it as mature for Kubernetes environments. Some note that it suits large enterprises with experienced staff better than small teams, because onboarding and tuning demand expertise.

Wiz

Wiz uses agentless snapshot scanning and integrates with CI/CD pipelines to scan images, repositories and configs for vulnerabilities and secrets. It generates SPDX and CycloneDX SBOMs and validates which packages are loaded at runtime. One reviewer noted that its detection and response capabilities still need development. Another said it suits hands-on practitioners better than GRC teams.

How Upwind adds runtime context to image scanning

Upwind runs alongside your build-time scanner and tells you which of its findings matter in production. Keep Trivy or Grype gating pull requests. Upwind’s eBPF sensor then watches the running containers built from those images and flags the CVEs whose packages actually load, sit on a reachable path and face the internet. Each finding links back to the Dockerfile or code change that introduced it, so the owning team gets one fix instead of hundreds of tickets. Some Gartner Peer Insights reviewers say Upwind’s SBOM features still need more polish.

• ✓CI/CD and IaC scanning feed the same risk view as runtime findings.
• ✓CVEs are ranked by loaded packages, reachability, exposure and exploitability.
• ✓Runtime findings trace back to the line of code or configuration.
• ✓Threat Stories correlate runtime, identity and cloud signals when an image is exploited.
• ✓Microsoft Sentinel playbooks can isolate containers or quarantine nodes.

How to choose a container image scanning tool

Test each container image scanning tool on your own images against the failure modes covered above, which are backports, distroless bases, nested JARs and alert volume. Vendor feature lists matter less. Run a two-week trial on 20 to 30 representative images and compare results side by side.

1. Accuracy: Does it use distro advisories and VEX, or flag backported packages as vulnerable?
2. Coverage: Does it find packages in distroless images, Go binaries and fat JARs?
3. Pipeline fit: Does it offer native GitHub Actions, GitLab CI and Jenkins support with SARIF output and fail thresholds?
4. Supply chain: Does it produce SPDX or CycloneDX SBOMs and Cosign attestations, and support admission checks?
5. Lifecycle: Does it rescan registries continuously and add runtime context to rank findings?
6. Exceptions: Can you record expiring, owned waivers instead of permanent ignores?

The strongest programs treat container image scanning as one control in a chain. Scan at build, sign what passed, verify at admission, rescan stored SBOMs as advisories change, and let runtime evidence decide what your team fixes this week.

FAQ