BLOG

By David Chernitzky, Co-Founder and CEO, Armour Cybersecurity  |  Serving organizations across Canada, the US, and beyond  |  Last updated August 19, 2026

Quick answer: Container security in the CI/CD pipeline starts from a simple fact: container images bundle an application and all its dependencies into a portable, reproducible deployment unit, and they also bundle whatever vulnerabilities exist in the base image operating system, the installed packages, the application code, and the runtime configuration. If no one scans container images before they are deployed, those vulnerabilities reach production in every deployment. Container security in the pipeline means scanning images in the registry before they are deployed, enforcing policies that prevent images with critical unpatched vulnerabilities from being promoted to production, hardening base images to reduce the vulnerability surface, and configuring runtime policies that restrict what containers can do once they are running. This is not a one-time exercise; images need to be rescanned when new vulnerabilities are disclosed for software already in the image, not just when the image is first built.

Key Takeaways

• Container images inherit the vulnerability posture of everything they contain: the base image operating system and packages, the language runtime, the application dependencies, and the application code itself. A container built on an unpatched Ubuntu base image inherits every vulnerability in that Ubuntu version. A container that includes a vulnerable version of a library inherits that vulnerability. Scanning the container image is not a substitute for SAST and SCA on the application code; it is an additional layer that catches vulnerabilities at the image level that may have been introduced through the base image rather than the application code.
• Base image selection is the highest-leverage decision in container security. A minimal base image such as Alpine Linux, Distroless, or a scratch image contains far fewer packages than a general-purpose Ubuntu or Debian image, which means a smaller vulnerability surface. Every package in the base image is a potential source of vulnerabilities that must be patched when new CVEs are disclosed. Choosing the smallest base image that satisfies the application’s runtime requirements and keeping that base image current are the two most impactful practices for reducing container vulnerability counts.
• Container registry access controls determine who can push images to the registry and who can pull them for deployment. An open registry where any developer can push images without review creates the risk of unscanned or misconfigured images reaching production environments. Registry access controls enforce that only images that have passed the scanning and policy gate in the CI/CD pipeline can be promoted to the registries from which production deployments pull.
• Runtime security policies restrict what containers can do once they are running, limiting the blast radius of a compromised container. Kubernetes pod security standards, admission controllers, and runtime security tools like Falco enforce policies such as: containers may not run as root, containers may not use privileged mode, containers may not write to the host filesystem, and containers may not load kernel modules. These policies prevent a compromised container from escalating to host-level access or affecting other containers on the same node.
• Container images in production need ongoing rescanning as new vulnerabilities are disclosed. A container image that was scanned and passed all policies when it was built may contain vulnerabilities that are disclosed the following week for packages already in the image. Without ongoing rescanning of images in production or in the registry, the vulnerability posture of deployed containers is only known at build time and drifts as new CVEs are published.

What Container Scanning Actually Evaluates

Container image scanning works across three distinct layers of the image, and a Docker container vulnerability scan that stops at any one of them leaves the others unexamined.

OS package vulnerabilities in the base image

Container image scanning begins with the operating system layer: the base image and every OS package installed on top of it. The scanner maintains a database of known vulnerabilities (CVEs) for each package in common Linux distributions and compares the packages present in the image against that database. A container built on Ubuntu 22.04 with an unpatched libssl package will be flagged with the CVE for that vulnerability. The remediation is typically to update the base image to a version where the package has been patched, or to update the specific package within the base image.

OS package vulnerabilities in base images are the most common category of container findings and also the easiest to address in aggregate: updating the base image version in the Dockerfile and rebuilding the image typically resolves dozens or hundreds of OS-level findings at once. This is why keeping base images current is one of the highest-leverage practices in container security; an outdated base image accumulates CVE findings at the same rate that new vulnerabilities are discovered in its packages.

Application dependency vulnerabilities

Beyond the OS layer, container scanners evaluate the application dependencies installed in the image: Python packages from pip, Node.js packages from npm, Java dependencies from Maven or Gradle, Ruby gems, and similar. These are the same dependencies that SCA scanning evaluates at the code level, but container image scanning catches them in the built artifact rather than the source code. This matters because the container image may include dependencies not captured in the project’s manifest files, or the manifest may specify version ranges that resolve to vulnerable specific versions at build time.

Findings at the application dependency layer require the same response as SCA findings: upgrade the affected package to a version where the vulnerability is fixed, or accept the risk with documented rationale if no fixed version is available and the vulnerability is not exploitable in the application’s specific context. Unlike OS-level findings, application dependency findings may require code changes if the package interface changed between the vulnerable and fixed versions.

Configuration and secrets in the image

Container scanners also evaluate image configuration for security issues: images that run as root by default (a common pattern that increases the risk of container escape), images that expose unnecessary ports, images that contain secrets embedded in environment variables or files (a common pattern for passing configuration that bypasses secrets management), and images built without proper layer hygiene that leave sensitive intermediate build artifacts in earlier layers visible through image history inspection.

Secrets in container images are a specific risk category. A common development pattern is to copy a configuration file containing database credentials or API keys into the container image during the build process. Even if the file is deleted in a subsequent layer, the secret is still accessible in the earlier layer of the image and can be extracted by anyone who pulls the image. This is the same hardcoded secrets problem that plagues source code, surfacing one layer down in the build. Proper secrets handling for containerized applications passes secrets at runtime through environment variables populated from a secrets management system, not through files baked into the image at build time.

Enforcing Container Security in the Pipeline

Effective container security in the CI/CD pipeline requires gates that enforce policy rather than just report findings. A scanning configuration that reports findings to a dashboard without blocking deployments of images with critical vulnerabilities is informational, not preventive. Policy enforcement means defining which finding severities block promotion of an image between environments: an image with critical unpatched vulnerabilities is blocked from being promoted to staging or production until the vulnerabilities are resolved or formally excepted. An image that runs as root or contains embedded secrets is blocked regardless of its vulnerability count.

The policy thresholds are calibrated during the engagement to match the organization’s risk appetite and the realistic patching pace of the development team. A policy that blocks promotion of images with any CVE of any severity will block every image because most base images contain some low-severity findings for which no patch has been released. A policy tuned to block promotion only for critical and high-severity findings with available fixes, while reporting medium and low findings for scheduled remediation, creates an enforceable gate that the development team can work within without blocking all deployments. This calibration is one of the tuning decisions that a DevSecOps program makes deliberately rather than by default.

Container registry access controls enforce that only images that have passed the pipeline policy gate can be pushed to the production registry from which deployments pull. Signed images, using container signing standards like Sigstore Cosign, allow the Kubernetes admission controller to verify that the image being deployed was produced by the authorized pipeline and has not been tampered with after signing. This supply chain integrity control prevents an attacker who gains access to the registry from deploying a malicious image by replacing a legitimate one. Armour Cybersecurity configures container scanning, registry access controls, and runtime policies as part of its DevSecOps engagement, and calibrates the policy gates to the team’s real patching pace so the controls hold without stalling delivery.

Frequently Asked Questions

What is the difference between SAST/SCA and container image scanning?

SAST (Static Application Security Testing) analyzes the source code of the application for security vulnerabilities before the code is compiled or deployed. SCA (Software Composition Analysis) analyzes the third-party libraries the application uses for known vulnerabilities. Both operate at the source code and dependency manifest level. Container image scanning operates on the built artifact: the container image that is the result of building the application code along with its dependencies, the language runtime, and the base OS. Container scanning catches vulnerabilities in the OS layer of the base image and in dependencies that may be installed at image build time but not tracked in the application’s source-level manifest files. The three tools are complementary layers: SAST catches code-level issues, SCA catches dependency-level issues in the source, and container scanning catches OS and dependency issues in the built artifact.

How do we handle base image vulnerabilities when no patch is available?

When a CVE is disclosed for a package in the base image and no fixed version has been released by the package maintainers, the options are: use a different base image that does not include the affected package (for example, switching from a general-purpose Ubuntu image to a minimal Distroless image that does not include the vulnerable package because it does not include that package category at all), apply a compensating control that makes the vulnerability unexploitable in the container’s specific deployment context, or formally accept the finding with documented rationale and a re-evaluation date. The formal acceptance process records that the security team has evaluated the finding, assessed the exploitability in the specific environment, and made a documented decision to accept the residual risk, which is exactly what a risk register is for. This is materially different from ignoring the finding, and it is the documentation that auditors expect to see for vulnerabilities that are present in deployed software and not immediately remediable.

What Kubernetes security configurations matter most?

The highest-impact Kubernetes security configurations are: pod security standards (enforcing that pods do not run as root, do not use privileged mode, and do not mount the host filesystem), network policies (defining which pods can communicate with which other pods, enforcing network segmentation at the pod level rather than just the node level), RBAC (Role-Based Access Control) configuration (ensuring that service accounts and users have only the permissions they need for their specific function), and admission controllers (validating or mutating pod specifications before they are admitted to the cluster, enforcing organizational security policies including image signing requirements). The Kubernetes CIS Benchmark provides a comprehensive set of hardening recommendations for cluster configuration; automated tools like kube-bench evaluate a cluster’s configuration against the benchmark and produce a findings report that can be used to prioritize the configuration changes that have the most security impact.

How often should container images be rescanned after initial deployment?

Container images in production or in the registry should be rescanned at minimum weekly, and ideally daily for images supporting critical workloads. New CVEs are disclosed continuously, and a vulnerability disclosed today for a package present in an image that was scanned and cleared six months ago represents a new risk in a deployed image that the initial scan did not detect. Continuous rescanning of the image inventory against an updated vulnerability database is the only way to maintain current visibility into the vulnerability posture of deployed containers. Most enterprise container scanning platforms support scheduled rescanning of the registry inventory; configuring this feature and routing the alerts to the appropriate remediation workflow is part of the container security program implementation.

The Bottom Line

A container image is only as secure as the least secure thing baked into it, and most of what it carries, the base OS, the installed packages, the runtime, the dependencies, came from somewhere other than your application code. Container security in the CI/CD pipeline means scanning all three layers before an image ships, gating promotion on the findings that actually matter, and rescanning what is already deployed as new vulnerabilities surface. Pair that with a small base image, registry access controls, signed images, and runtime pod policies, and a compromised container has far less it can reach. The calibration is what makes it workable: gate on critical and high findings with fixes, schedule the rest, and the pipeline protects production without blocking every deploy. A structured DevSecOps engagement stands up the scanning, the gates, and the runtime policies together, tuned to how your team actually ships.