CI/CD image scanning is the automated inspection of container images within build and deployment pipelines. It checks image layers, packages and metadata for known vulnerabilities, misconfigurations or embedded secrets before the image is promoted to testing or production.
What CI/CD image scanning actually checks
CI/CD image scanning inspects container images while they are still moving through the delivery pipeline, before they are allowed into shared testing or production environments. It is aimed at image layers, embedded packages, metadata and other build-time artefacts that can carry known vulnerabilities, unsafe configuration or hidden secret material.
The value of the control is that it treats the image as a deployable security object, not just a software artifact. A clean source repository does not guarantee a clean image, because build steps can introduce outdated libraries, inherited base-image flaws, leftover credentials or configuration drift that only appears in the final packaged image.
Where image scanning fits in the delivery chain
Image scanning is usually placed after the image is built and before promotion, so it can act as a release gate. That placement matters because the scan sees the exact artifact that will run, rather than assuming the source tree or dependency manifest fully represents the runtime state.
In practice, this makes image scanning part of a broader container security workflow that also includes base-image selection, registry hygiene, tag discipline and image provenance. Container Image Security Guide is the natural starting point for that wider workflow, because it connects scanning to signing, SBOMs and registry access control.
When organisations separate build, store and deploy stages cleanly, scanning becomes a policy decision point rather than a one-time checklist item. That is especially important for ephemeral CI/CD systems, where a compromised build artifact can spread quickly if promotion rules are weak.
What good scans need to find
A useful scan does more than flag package versions. It should surface vulnerable operating-system packages, insecure libraries, suspicious metadata, hard-coded credentials and obvious misconfigurations that were introduced during the image build. It should also preserve enough context to tell whether a finding is inherited from the base image or created by the current pipeline.
That distinction matters because remediation differs. A flaw in an inherited base image may require rebuilding from a safer upstream image, while a secret embedded during build may require revocation, rotation and a new build process. How to find hard-coded secrets in container images is especially relevant when the concern is secret leakage inside layers or image history.
CI/CD image scanning also works best when it is paired with registry-side review, because some risks are easier to catch after an image is pushed and indexed. Container Registry Security Guide covers the surrounding controls that make scanning more reliable, including tag immutability and admission-related checks.
Why scanning cannot be treated as a final guarantee
Image scanning reduces exposure, but it does not prove that an image is safe to run. A scan can miss newly disclosed vulnerabilities, runtime-only misbehaviour, poisoned build inputs or secrets that are encoded in unusual formats. It can also create a false sense of safety if teams treat a passing result as a permanent property of the artifact.
For that reason, image scanning works best when it is combined with provenance and integrity controls that answer where the image came from and whether it was built from trusted inputs. Supply-chain integrity is especially important when a pipeline consumes third-party dependencies or reuses shared build infrastructure. SLSA is a strong companion reference because it focuses on build provenance and artifact integrity, which complements the vulnerability-focused view of scanning.
Authoritative container guidance also helps teams decide how much trust to place in scan results and where additional runtime controls are needed. NIST SP 800-190 Container Security is useful here because it treats image, registry, orchestrator and runtime as one security system rather than isolated steps.
How teams should use scan results operationally
Image scanning only creates value when the findings are triaged, prioritized and tied to release policy. High-confidence findings should block promotion, while lower-confidence issues need a consistent exception process so teams do not ignore the scanner out of frustration.
Secret findings deserve especially fast handling because a secret baked into an image may already be replicated across registries, caches and deployed workloads. In that situation, the right response is not just to rebuild the image, but to revoke or rotate the exposed material and verify that the replacement image no longer contains it. Secrets in Container Images and Build Artefacts Guide gives a practical view of why these exposures persist after deletion and how they should be handled.
For teams looking at policy maturity rather than a single control, scanning should sit inside a repeatable secure-delivery program. OWASP SAMM is relevant when the question is how to build scanning into software delivery practices, not just how to configure a tool.
Risk and Threat Considerations
CI/CD image scanning matters because a compromised or poorly built image can carry vulnerable code, hidden credentials or malicious configuration into every environment that pulls it. If the pipeline promotes images automatically, one missed finding can become a broad deployment problem rather than a single-host issue.
Failure mechanism: Attackers or careless build steps can introduce secrets, vulnerable packages or poisoned layers into the image, then rely on weak scanning coverage, false negatives or exception fatigue to get the artifact promoted.
Impact: The result can be credential theft, lateral movement, registry sprawl, repeated redeployment of a bad image and a longer cleanup cycle because the same artifact may already exist in multiple clusters and caches.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, SLSA and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | Image scanning identifies vulnerabilities in container artifacts before deployment. |
| CM-8 — System Component Inventory | Image scanning depends on knowing which image artifacts, layers and dependencies exist. | |
| IA-5 — Authenticator Management | Scanning often finds embedded secrets, tokens and keys that must be rotated after exposure. | |
| Recommendation — Scan container images before promotion and remediate confirmed flaws before release. Inventory image artifacts and dependencies so scan coverage matches what you actually deploy. Rotate exposed credentials and tokens immediately when scans reveal secret material in images. | ||
| SLSA | Supply-chain Levels for Software Artifacts | Image scanning complements build provenance and integrity controls for container artifacts. |
| Recommendation — Pair image scanning with provenance verification so you can trust the artifact source and build path. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Scanning checks image configuration and known insecure software content before deployment. |
| Recommendation — Enforce secure image configuration checks before images reach production. | ||
Practitioner Guidance
Why practitioners should care: Image scanning should be treated as a release gate tied to the exact image that will run, not as a generic compliance checkbox. The most useful setups fail closed on high-confidence findings, preserve build context for triage and distinguish base-image issues from pipeline-introduced issues.
Practitioner takeaway: The strongest programs pair scanning with provenance, registry controls and secret revocation, because scanning alone cannot prove that a container image is trustworthy.