How to audit vulnerabilities in Docker images in the pipeline

Why scan Docker images before pushing to the registry

When we package an application into a container, we usually inherit hundreds of operating system packages and third-party libraries that often go unnoticed. In practice, this means a simple Node.js or Python application can carry dozens of known security flaws simply because of the chosen base image. If we do not perform rigorous screening before sending the artifact to the corporate registry, we open a massive security gap that can compromise the entire production cluster.

Integrating security directly into the continuous delivery flow is the only way to ensure defective code does not advance silently. Instead of discovering breaches after deployment, automated auditing acts as a strict inspector at the shipping dock. If the image contains known critical vulnerabilities, the build is stopped immediately, forcing the developer or maintainer to update the dependency before trying again. This process aligns perfectly with the need for speed without sacrificing stability, much like we discussed when analyzing why your CI/CD pipeline is slow and how to speed up builds, where balancing velocity and technical rigor makes all the difference.

The fundamental role of SBOM in the supply chain

The concept of SBOM, or Software Bill of Materials, is essentially the ingredient list of the software you are building. Just like a nutrition label on a food package details every component, the SBOM lists all libraries, packages, and versions present inside the container. This radical transparency has changed how engineers and security teams handle audits, eliminating guesswork when figuring out if a specific system is affected by a newly disclosed public flaw.

During the delivery pipeline, generating the SBOM should happen right after building the artifact and prior to pushing it to the central repository. Modern tools can map even nested dependencies that the developer did not even know existed in the project. Besides meeting increasingly common regulatory demands in the market, having this structured map greatly simplifies future investigations. When we combine this visibility with best practices on how to speed up Docker builds with cache, we ensure the checking process remains fast and does not become an operational bottleneck in the workflow.

Choosing and integrating the right scanning tool

There are several solutions on the market to analyze container images for known flaws, ranging from open-source options to robust commercial platforms. Tools like Trivy or Grype stand out for being extremely fast and easy to embed into automation scripts. They query vulnerability databases updated daily to pinpoint exactly which package is outdated and which version fixes the problem.

To put this into practice in an automated way, we can set up a specific stage in our pipeline configuration file. Below is a practical example of how to run a check using an open-source tool directly within the integration pipeline:

security-scan:  image: aquasecurity/trivy:latest  stage: test  script:    - trivy image --exit-code 1 --severity CRITICAL,HIGH my-app:latest

In this simple command, we define that the pipeline must fail (with exit code 1) if it finds any vulnerability classified as critical or high in the built image. This shields the repository against unpleasant surprises and ensures the team maintains a proactive stance against incidents.

Establishing tolerance policies and exception handling

One of the biggest mistakes when implementing container security scanning is blocking all builds indiscriminately without a clear prioritization criterion. In practice, Linux base images frequently accumulate dozens of low-severity alerts that can paralyze developer work with false positives. Therefore, engineering needs to define objective policies: what actually blocks deployment and what should merely generate a warning for future correction.

When a critical vulnerability emerges in a library that cannot be updated immediately due to legacy system limitations, the need for documented exceptions arises. These exceptions must have a short expiration date and require explicit approval from the security team. Rigorous management of these exceptions prevents alert fatigue, ensuring developers keep paying attention to genuinely important warnings without losing operational agility.

Final considerations on continuous container security

Auditing Docker images before pushing them to the registry is no longer a corporate luxury; it has become a basic survival requirement in modern software development. Combining automated scanning with SBOM generation ensures total visibility and strict control over everything entering staging and production environments. By educating the team and automating these barriers, we build a culture where security walks hand in hand with delivery speed, protecting both the company and end users from avoidable threats.