Container Image Security Audit: A Step-by-Step Guide for Security Engineers

The distinction matters operationally because the tools, timing, and remediation paths are different.

A container image audit is static analysis applied before deployment. It answers the question: what is in this image, and is it safe to run? The audit runs during the build pipeline or on demand against a pulled image. Findings from an image audit are fixed by modifying the Dockerfile, updating dependencies, or rotating exposed secrets -- changes that happen before the image ships.

A runtime audit is behavioral monitoring applied while a container is executing. It answers the question: is this container doing what it is supposed to do? Runtime tools like Falco, Sysdig Secure, and Prisma Cloud Defender watch for anomalous system calls, unexpected outbound connections, privilege escalation, and filesystem writes to sensitive paths. Findings from a runtime audit indicate active exploitation, misconfiguration under load, or lateral movement.

For security engineering teams, the practical implication is sequencing: image audits should gate deployment (block the pipeline on critical findings), while runtime monitoring operates continuously in production. An image that passes all pre-deployment checks can still behave maliciously if it is compromised after the fact via a supply chain substitution or if a zero-day is disclosed after deployment -- which is why both layers are necessary.

The base image is the largest single factor in an image's starting vulnerability surface. A Debian full image ships with several hundred packages, most of which a production application does not need. Every package that is not needed is an attack surface that does not need to exist.

The audit checklist for base images covers three questions. First, is the base image minimal? Distroless images (from Google) ship with no shell, no package manager, and only the runtime libraries required by the application. Alpine Linux is a popular minimal alternative that keeps the base image under 5 MB. Red Hat UBI-minimal provides a minimal RHEL-compatible base with enterprise support. Full Debian, Ubuntu, or CentOS base images are rarely justified for production workloads.

Second, is it an official image or a community image? Official images on Docker Hub are maintained by the software vendor or by Docker's official images program and undergo security review. Community images have no such guarantee. In your audit, flag any base image not sourced from a verified publisher or your organization's internal registry.

Third, is the base image pinned by digest rather than tag? A tag like python:3.12-slim is mutable -- the content it points to can change without notice. A digest pin like python@sha256:abc123... is immutable. Audit findings should flag tag-pinned base images as a supply chain risk.

Vulnerability scanning compares the packages, libraries, and binaries in a container image against known CVE databases to identify components with disclosed security flaws.

The three scanners used most widely in 2026 are Trivy, Grype, and Snyk Container. Trivy (Aqua Security) is open source, fast, and scans OS packages, language-specific dependencies, and infrastructure-as-code files bundled inside an image. It is the most common scanner in open-source CI/CD pipelines. Grype (Anchore) is also open source and produces output in SARIF format, which integrates directly with GitHub Advanced Security and other SAST platforms. Snyk Container is a commercial option that combines scanning with developer-facing fix guidance and integrates with IDE plugins.

Running a Trivy scan against a local image takes a single command: trivy image --severity HIGH,CRITICAL myapp:latest. The output lists each vulnerability, its CVE ID, the affected package, the installed version, the fixed version if available, and the CVSS score.

For CI/CD integration, the standard threshold policy is: fail the pipeline on Critical CVEs (CVSS 9.0+), produce a warning and require sign-off on High CVEs (CVSS 7.0-8.9), and allow Low and Medium findings to pass with logging. This threshold should be documented as policy, not left to individual pipeline configuration. Exceptions require a documented risk acceptance from the application owner.

Secrets embedded in container image layers are a persistent problem because developers sometimes hard-code API keys, database passwords, or private certificates during development and forget to remove them before committing the Dockerfile or application code.

The critical detail for container image audits: removing a secret from the final image layer does not remove it from the image history. If a secret is written in one layer and deleted in a subsequent layer, the secret remains accessible in the intermediate layer. Secrets detection must scan all layers, not just the final filesystem state.

The three tools most commonly used for secrets scanning in container image audits are Gitleaks, truffleHog, and detect-secrets. Gitleaks supports scanning Docker image filesystems directly and can be configured with custom rules for organization-specific secret patterns. truffleHog scans image layers with entropy analysis to catch high-entropy strings that pattern matching misses. detect-secrets (Yelp) is audit-focused and produces a baseline file that tracks known acceptable findings, making it useful for suppressing false positives without disabling rules.

For CI/CD integration, run secrets detection as a pre-push hook on the Dockerfile and application code repository, and as a separate pipeline stage scanning the built image before it is pushed to the registry. Both checks are needed: the pre-push hook catches secrets before they enter the build; the image scan catches secrets injected during the build process itself.

A Software Bill of Materials is an inventory of every package, library, and dependency included in a container image. For container image audits, an SBOM is both a security artifact and a compliance requirement.

From a security standpoint, the SBOM is what enables rapid response when a new vulnerability is disclosed. When Log4Shell was announced in December 2021, organizations with SBOMs for their container images could query the SBOM to identify affected containers in minutes. Organizations without SBOMs spent days or weeks manually auditing their image catalog.

From a compliance standpoint, FedRAMP High and recent CISA guidance under the Biden-era executive order on software supply chain security both require SBOM generation for software used in federal systems. SOC 2 auditors increasingly request SBOMs as evidence of software inventory controls.

The two primary tools for container image SBOM generation are Syft and Docker Scout. Syft (Anchore) generates SBOMs in CycloneDX or SPDX format from local images, running containers, or image tarballs: syft myapp:latest -o cyclonedx-json > sbom.json. Docker Scout is integrated into Docker Desktop and Docker Hub and generates SBOMs with a visual diff view for comparing image versions. Attach the SBOM as a build artifact in your CI/CD pipeline and store it alongside the image in your registry.

Dockerfile configuration issues create exploitable misconfigurations even when all packages are patched. An image audit includes a static review of the Dockerfile against a baseline of known-good practices.

The five Dockerfile checks that generate the most audit findings are:

Non-root USER instruction. Containers that run as root give an attacker root access to the container filesystem and potentially the host if the container runtime is misconfigured. Every production Dockerfile should include a USER instruction that switches to a non-root user before the final CMD or ENTRYPOINT.

COPY vs. ADD. The ADD instruction has additional capabilities beyond file copying: it automatically extracts tarballs and fetches remote URLs. This behavior makes it a source of unexpected file inclusion. Use COPY unless the specific capabilities of ADD are required, and document the reason when ADD is used.

Multi-stage builds. Multi-stage builds allow the compilation environment (with build tools, compilers, and development dependencies) to be separated from the final runtime image. The result is a production image that contains only the compiled application and its runtime dependencies. Single-stage builds that include build tools in the production image increase the attack surface without functional benefit.

Pinned digests vs. tags. As noted in the base image step, tag references are mutable. All FROM instructions and any RUN commands that pull external resources should reference content by digest.

Layer minimization. Each RUN instruction creates a new image layer. Package installation commands that run apt-get update in one layer and apt-get install in the next leave the package cache in an intermediate layer. Chain package operations into a single RUN instruction and clean the cache in the same layer.

Image signing provides cryptographic proof that an image was produced by a specific pipeline or identity and has not been tampered with in transit. Without signing, a container runtime has no mechanism to verify that the image it is about to execute is the same one that passed all the audit checks.

Sigstore is the open-source project that provides the tooling for keyless container image signing. Cosign is the Sigstore CLI for signing and verifying container images. The keyless signing model uses OIDC identity tokens from a CI/CD provider (GitHub Actions, GitLab CI, Google Cloud Build) to sign images without managing long-lived private keys. The signature is stored in the same container registry as the image.

The CI/CD integration pattern is: sign the image immediately after it passes all audit checks, before it is pushed to the production registry. Verification runs at deployment time: Kubernetes admission controllers (Kyverno, OPA Gatekeeper) can be configured to reject any image that does not carry a valid Cosign signature from your organization's CI pipeline identity.

For audit documentation, record the signing identity (the OIDC subject), the registry location of the signature, and the policy enforcing signature verification at deploy time.

The CIS Docker Benchmark is a published security configuration standard for Docker environments that covers both the Docker daemon configuration and individual container and image settings. The docker-bench-security tool automates the majority of CIS benchmark checks against a running Docker host.

Running docker-bench-security produces a categorized report of pass, warn, and info findings organized by CIS benchmark section. For an image-focused audit, the most relevant sections are Section 4 (Container Images and Build File) and Section 5 (Container Runtime). Section 4 checks include: whether a non-root user is specified, whether the image uses a trusted base image, whether unnecessary packages are not installed, and whether HEALTHCHECK is defined.

For security teams auditing images in a CI/CD context rather than against a live Docker host, the CIS benchmark checks can be partially implemented as Dockerfile linting rules using Hadolint, an open-source Dockerfile linter that maps its rules to Docker best practices. Hadolint integrates as a pipeline step and produces findings in SARIF format.

A container image audit that runs manually on demand catches issues but does not prevent them from reaching production. The goal is a pipeline that enforces audit checks automatically on every image build.

A practical CI/CD integration sequences the audit steps as follows. First, run Hadolint against the Dockerfile as a pre-build check. Second, build the image. Third, run Trivy or Grype for vulnerability scanning and fail the pipeline on Critical findings. Fourth, run Gitleaks or truffleHog against the built image layers for secrets. Fifth, generate a Syft SBOM and attach it as a pipeline artifact. Sixth, if all checks pass, sign the image with Cosign and push it to the registry. Seventh, trigger policy enforcement at the Kubernetes admission controller to verify the signature before the image runs.

Fail thresholds by severity: Critical CVEs (CVSS 9.0+) block the build. High CVEs (CVSS 7.0-8.9) generate a warning and require documented risk acceptance. Medium and Low CVEs are logged but do not block deployment. Secrets findings always block regardless of severity classification.

An image security audit is only a compliance artifact if the findings are documented in a format that auditors can evaluate. For SOC 2 and FedRAMP, the minimum documentation set for each audited image includes the image name and digest, the scan date and tool version, a finding summary table (finding ID, CVE or rule ID, severity, affected component, remediation status), the SBOM file or registry location, evidence of image signing (signing identity and signature location), and a risk acceptance record for any High findings that were not immediately remediated.

For FedRAMP High authorization, the container image audit results map to the SA-10 (Developer Configuration Management) and SI-2 (Flaw Remediation) controls. Document the audit workflow as part of the System Security Plan's software development lifecycle section, and maintain audit records for the duration of the authorization period.

For SOC 2 Type II, container image audit evidence supports the Change Management and Risk Mitigation criteria. Auditors will look for evidence that image scans run on every build (not just on request), that Critical findings are blocked before deployment, and that SBOM artifacts are retained and accessible.