Implementing Level 3 of the Container Vulnerability Management Framework

In our previous post, we explored Levels 1 & 2 of the Container Vulnerability Management Framework, focusing on gaining visibility into vulnerabilities through scanning and structured tracking with Trivy and Dependency Track. These foundational steps helped teams move from ad hoc scanning to scheduled, repeatable vulnerability assessments.

While this visibility is critical, it doesn’t prevent vulnerabilities from reaching production. Without clear security enforcement, developers can still build and deploy images containing known risks, and security teams are left reacting to issues rather than preventing them.

Level 3 marks a fundamental shift from simply tracking vulnerabilities to actively blocking insecure containers from deployment. This is where security enforcement mechanisms—such as CI/CD security gates, policy-driven controls, and the use of vetted base images—become essential. In this post, we will shift the focus from merely identifyingN vulnerabilities to actively enforcing security policies in containerized environments. This means locking down insecure base images, integrating security controls into CI/CD pipelines, and ensuring production images meet security standards before deployment.

This post walks through practical ways to implement Level 3, covering multiple approaches—including how Root-curated base images help reduce vulnerabilities at the source, but also how image signing, policy enforcement, and automated scanning pipelines ensure that only secure, trusted images reach production.

Moving from Visibility to Active Prevention

At Level 3, organizations transition from passive security monitoring to active prevention. Instead of reacting to vulnerabilities after they are deployed, security is embedded into the development lifecycle, stopping insecure containers before they reach production.

This level introduces policy-based security enforcement, where teams define and enforce rules for container image usage to eliminate high-risk deployments. 

The goal is to:

• Ensure every container image adheres to security policies before deployment

• Enforce the use of secure, trusted base images to reduce inherited vulnerabilities

• Block unapproved or vulnerable images from being used in production

Key Security Controls at Level 3

At this stage, security shifts from informational to mandatory. Several enforcement mechanisms come into play:

• Policy-driven image enforcement – Security teams define and enforce rules for container image security, ensuring that only approved images are allowed

• Scanning and CI/CD security gates – Vulnerability scans are required before an image can be deployed, ensuring compliance

• Trusted base images – Organizations ensure that only vetted, pre-approved base images are used as the foundation for container builds

• Continuous monitoring and drift detection – Teams track security posture over time and detect when containers deviate from approved baselines

These controls work together to proactively prevent security issues rather than reactively addressing them after deployment.

Enforcing Security in CI/CD Pipelines

At Level 3, security becomes an integral part of the development and deployment process, ensuring that insecure images never reach production.

The key shift is policy-based enforcement—introducing automated rules and security controls that govern which container images can be used, how they are built, and whether they pass security standards before deployment.

Defining Security Standards for Container Images

One of the biggest security challenges in containerized environments is inherited vulnerabilities. Developers frequently pull base images from public repositories without assessing their security posture, unknowingly introducing hundreds—or even thousands—of known vulnerabilities into their applications.

At Level 3, organizations eliminate these risks earlier in the development lifecycle by enforcing strict base image policies. This ensures that all container images start from a secure foundation, rather than requiring continuous patching after deployment.

There are multiple approaches to achieving this:

• Curated Base Image Repositories – Some organizations adopt pre-approved, security-maintained base images to minimize vulnerabilities from the outset. Root-curated images, for example, are optimized for security, reducing vulnerability exposure while maintaining usability.

• Internal Golden Images – Larger organizations maintain their own private repositories of hardened base images, which must be used in development. This helps maintain consistency across teams while reducing reliance on external sources.

• Policy-Based Enforcement – Teams use security policies to restrict which images can be used in development and production environments, preventing the use of unapproved or vulnerable base images.

While curated images dramatically reduce vulnerabilities at the source, they are only one piece of the enforcement puzzle. The next step is ensuring that every image that moves through the CI/CD pipeline meets security requirements before deployment.

Automated Security Gates in CI/CD Pipelines

At Level 3, vulnerability scanning is no longer a passive, point-in-time process—it becomes an active enforcement mechanism. Instead of running scans just for awareness, organizations enforce security requirements in CI/CD pipelines to block deployments that fail to meet security standards.

This is crucial because:

• Security findings are often ignored if they don’t cause failures – If scans don’t impact deployment, insecure images will eventually make it to production.

• Developers may unknowingly introduce vulnerable dependencies – Even when using secure base images, application dependencies can introduce new risks.

• Manual review doesn’t scale – Without automated enforcement, security teams are left manually triaging vulnerabilities, slowing down releases.

To prevent these issues, organizations implement automated security gates in their CI/CD pipelines that enforce policies such as:

• Blocking builds if critical or high-severity vulnerabilities are detected.

• Requiring all container images to be scanned before they are deployed.

• Rejecting images that don’t come from trusted sources.

Security gates shift security left, ensuring that insecure images are identified and blocked before they can cause harm.

Preventing Unauthorized or Tampered Images

In addition to vulnerability scanning, organizations at Level 3 also begin enforcing image provenance and authenticity. A key concern is ensuring that only approved, untampered images are deployed—preventing scenarios where unverified images enter production environments.

This is achieved through:

• Image signing and verification – Digital signing mechanisms ensure all container images are cryptographically verified before deployment, preventing unauthorized modifications or image swaps

• Runtime security policies – Security tools enforce policies that block unsigned or unverified images, ensuring only legitimate builds are executed

• Registry access controls – Teams implement strict access controls on container registries, limiting who can push or pull images, ensuring only security-approved versions are used

By combining scanning with authentication and provenance controls, organizations gain confidence that every image deployed is both secure and trusted.

Why Curated Base Images Matter

A common challenge in container security is that developers pull base images from public repositories without vetting their security posture. These images often contain hundreds or thousands of known vulnerabilities, leading to unnecessary risk before application code is even added.

To address this, organizations at Level 3 mandate the use of trusted, pre-approved base images rather than relying on arbitrary public images.

Strategies for Base Image Security

• Root-curated base images – Without too much self-promotion, Root has invested a lot of engineering effort to curate a catalog of security-optimized base images designed to minimize vulnerabilities to remove the manual toil from engineering teams.

• Internal golden image repository – Many companies build self-hosted registry where teams maintain vetted, security-hardened base images.

• Image allow lists – Alternate methods include writing and maintaining policies that enforce which base images can be used in development and production.

Where Root Fits In

Most teams unknowingly start from bloated, vulnerable base images. Whether it’s a "latest" tag pulled from Docker Hub or an outdated version of a common image, this approach introduces risk before any code is even written.

Root eliminates this risk at the foundation. As a Docker Verified Publisher, Root offers a growing catalog of curated base images that are:

• Radically reduce vulnerability counts by stripping out unnecessary and outdated components

• Ensure compatibility and usability by maintaining a balance between security hardening and developer experience

• Keep security up to date through continuous maintenance and proactive patching by Root Labs

These curated images are designed to drop into your existing workflows with minimal friction. Root also integrates directly into CI/CD pipelines, ensuring that secure images aren’t just available—they’re enforced.

By standardizing on Root-curated images across all containerized workloads, teams shift from reactive patching to proactive prevention—starting every build with security built in.

Key Takeaways from Level 3

By enforcing security at the CI/CD pipeline level, organizations ensure that vulnerabilities are blocked before they ever reach production.

• Base image security is formalized, ensuring only pre-approved, vetted images are used

• Security scans become a mandatory step in deployment, stopping vulnerable images before they go live

• Authentication and provenance controls prevent unauthorized images from entering production environments

• Continuous monitoring ensures security remains strong after deployment, not just at the build stage

Security is not a one-time process. Even when images are approved at build time, new vulnerabilities emerge daily, and an image that was secure yesterday may become a risk tomorrow. At Level 3, organizations introduce continuous monitoring to track vulnerabilities across all containerized environments. This ensures that:

• Security risks are monitored beyond just CI/CD scans – Even after deployment, security tools should continuously check for newly discovered vulnerabilities.

• Teams receive alerts when new risks are detected in production environments.

• Security trends can be analyzed over time, helping teams make informed decisions about patching and updates.

Dependency Track plays a critical role in this stage by aggregating vulnerability data, tracking security metadata, and providing a historical view of container security trends. However, monitoring alone is not enough—it must be combined with policy enforcement and CI/CD security gates to proactively prevent security issues before they reach production.

Looking Ahead: Automated Remediation in Level 4

At Level 3, organizations move beyond awareness and take proactive control over container security. By integrating security enforcement into CI/CD pipelines, enforcing the use of secure base images, and preventing unauthorized images from being deployed, teams ensure that only trusted, security-compliant containers reach production.

However, Level 3 still relies on manual remediation—when vulnerabilities are detected, security teams must act on them. Level 4 takes this a step further by introducing automated remediation and vulnerability patching, ensuring that security is maintained at scale without requiring constant manual intervention.

In our next post, we’ll explore how organizations can go beyond prevention and start actively fixing vulnerabilities before they become security incidents.