Root.io

  New!Learn how Root compares to Chainguard 
Menu
Login
Sign Up

A Hands-On Guide to Container Vulnerability Management – Levels 1 & 2

John Amaral

A Hands-On Guide to Container Vulnerability Management – Levels 1 & 2

In a previous post, we introduced the Container Vulnerability Management Framework, outlining a structured approach to improving container security. While that post established the four maturity levels and their role in reducing risk, today we move beyond theory into practical implementation.

After a fun meetup in Tel Aviv with a lot of audience participation and questions, we understood we wanted to take this framework from theory to implementation and share how you can practically apply these steps to evolve your container vulnerability management maturity.

This guide will walk you through Levels 1 & 2 of the maturity framework, showing how to:

  • Set up an image inventory and establish a structured vulnerability management workflow.
  • Implement periodic vulnerability scanning with open-source tools like Trivy.
  • Track vulnerabilities over time using the OWASP tool Dependency Track (DepTrack).
  • Generate and store SBOMs for security visibility and compliance.

By the end, you’ll have a hands-on foundation to start securing your containerized workloads effectively.

Level 1: Ad Hoc Scanning & Manual Review

Most teams begin their container security journey by running vulnerability scans manually, usually on an ad hoc basis. A common practice is to scan images only when a security issue arises—often in response to a breach, compliance audit, or after a major release. While this reactive approach provides temporary insights, it lacks consistency, repeatability, and historical tracking. 

Developers may scan an image once, but without automation, there’s no guarantee that newly discovered vulnerabilities will be detected over time. The goal of Level 1 is to establish basic visibility into existing risks and lay the groundwork for automated, continuous security monitoring—allowing teams to proactively address vulnerabilities rather than firefighting them after deployment.

Trivy, a popular open source container security scanning tool, helps overcome these challenges by offering fast, automated, and repeatable security scans that integrate seamlessly into DevSecOps workflows.

Below we’ll walk through a quick guide for how to get started with Trivy to get to Level 1 of our maturity framework.

Step 1: Install Trivy and Perform a Basic Scan

Installing Trivy

Trivy is a lightweight and easy-to-use vulnerability scanner for container images. Get started by installing it with the following command:

				
					# macOS

brew install aquasecurity/trivy

# Debian/Ubuntu

sudo apt install trivy

Scanning a Container Image

Once installed, run Trivy against a public base image:

				
					trivy image docker.io/library/nginx:latest

Trivy will output a list of known vulnerabilities (CVEs) detected in the image, categorized by severity (Critical, High, Medium, Low).

Key Takeaways:

  • This scan provides immediate insights but is not repeatable.
  • There’s no tracking—once the scan runs, results are lost unless manually recorded.
  • Actionability is limited—there’s no structured way to manage vulnerabilities over time.

Step 2: Store and Review Scan Reports

While manual scans provide valuable insights, organizations need a structured approach to tracking results. 

To save scan reports, run the following:

				
					trivy image --format json -o trivy_reports/nginx-latest.json docker.io/library/nginx:latest

This outputs a JSON report for later review.

Once we complete Level 1, while teams may still be reactive, this is the first step for gaining maturity in your container management maturity and lays the groundwork for structured vulnerability tracking as we continue through the maturity framework.

Level 2: Basic Image Inventory and Vulnerability Awareness

To move beyond ad hoc scanning, teams need a structured vulnerability tracking process. Without consistent monitoring and historical tracking, security efforts remain reactive, making it difficult to assess risk trends or prioritize fixes. 

Level 2 introduces repeatable processes that bring stability and visibility to vulnerability management. By establishing a formal image inventory, teams ensure they scan and monitor the right set of images—rather than relying on scattered or inconsistent reviews. 

Scheduled vulnerability scanning eliminates reliance on manual checks, reducing the risk of vulnerabilities slipping through unnoticed. Storing scan results over time enables security teams to track vulnerability trends, assess the impact of new discoveries, and ensure that remediation efforts are effective. These foundational steps lay the groundwork for more advanced security automation in later stages of the framework.

Step 3: Set Up a Private Image Repository

The next steps will help us level up to the next level of the maturity framework.

Instead of scanning arbitrary public images, Level 2 introduces a Private Image Repository, ensuring that only approved base images are used.

Using a private image repository instead of scanning arbitrary public images is a crucial step in strengthening container security. Public repositories often contain outdated, bloated, or unverified images, making it difficult to control what dependencies and vulnerabilities are being introduced into an environment. By centralizing base images in a private repository, teams ensure that only vetted, security-approved images are used across development and production. 

This prevents the accidental use of images with known vulnerabilities or misconfigurations. Additionally, a private repository enables better version control, allowing security teams to track updates, enforce patching policies, and ensure that all deployed containers originate from a trusted source. This shift from an open-ended approach to a controlled, curated inventory is essential for maintaining consistency, reducing attack surfaces, and preparing for more advanced security automation in later stages.

Show Me the Code

Create a private repository using Docker Hub, AWS ECR, or another registry:

				
					docker tag nginx:latest myrepo/nginx:latest
docker push myrepo/nginx:latest

All base images should be stored centrally, enabling consistent tracking.

Step 4: Automate Scheduled Scans with Trivy

Rather than running scans manually, schedule daily automated scans.

Create a simple cron job to scan and store results:

				
					0 2 * * * trivy image --format json -o 
/var/reports/nginx-latest.json myrepo/nginx:latest

This ensures that:

  • Every base image is scanned daily.
  • Historical vulnerability trends are tracked.
  • Security teams get early warnings of new vulnerabilities.

Step 5: Introduce DepTrack for Continuous Monitoring

Trivy alone provides point-in-time scans, meaning it detects vulnerabilities when a scan is run, but it doesn’t maintain historical tracking or provide ongoing monitoring. This creates a gap—while Trivy helps identify issues, it lacks built-in capabilities to track how vulnerabilities evolve over time, correlate security risks across multiple images, or alert teams when a new CVE affects an image already in use.

This is where Dependency Track (DepTrack) becomes essential. DepTrack is a software supply chain risk management platform that continuously monitors vulnerabilities in container images, libraries, and dependencies. Instead of running isolated scans, it maintains an inventory of all software components used across your organization and automatically correlates new vulnerability disclosures with existing assets. You can learn more about integrating Trivy and DepTrack through Client/Server Mode.

By integrating Trivy with DepTrack:

  • Vulnerability trends can be monitored over time – teams can see if a vulnerability has been patched or worsened.
  • Security risks are continuously evaluated – if a new CVE is published that impacts an already-deployed image, DepTrack will detect it and flag it.
  • SBOMs (Software Bill of Materials) are centrally stored and analyzed – providing deeper visibility into dependency risks.
  • Security teams get proactive alerts – instead of rerunning scans manually, they receive updates when new threats emerge.

This shift from point-in-time scanning to continuous security monitoring is critical for scaling vulnerability management. DepTrack transforms vulnerability scanning from a reactive process into a proactive security strategy that ensures teams can detect and respond to risks before they become a problem in production.

Step 6: Monitor Vulnerability Trends

DepTrack provides a vulnerability dashboard, allowing teams to:

  • View security trends across base images.
  • Monitor new vulnerabilities as they emerge.
  • Track security fixes over time.
  • Integrate monitoring into their workflow by connecting DepTrack with container registries to automatically scan and track images.
  • Receive notifications (e.g., Slack) when new vulnerabilities are detected, ensuring timely responses.

Key Takeaways from Levels 1 & 2

Level 1: Initial Visibility
At this stage, teams begin running ad hoc vulnerability scans on container images to gain a basic understanding of security risks. However, because these scans are performed manually and inconsistently, they provide only a snapshot in time rather than a complete security picture. Without a structured process, results are not stored or tracked beyond individual reports, making it difficult to measure progress or respond to emerging threats. Additionally, there are no enforcement mechanisms in place, meaning even critical vulnerabilities can go unaddressed, leaving organizations exposed to security risks.

  • Ad hoc scanning provides immediate insights but lacks continuity
  • Scan results are not stored or tracked, making trend analysis impossible
  • No policies exist to prevent vulnerable images from being used in production

Level 2: Structured Awareness
To move beyond reactive scanning, teams need a more systematic approach to vulnerability management. This begins with maintaining a Private Image Repository, ensuring that only approved, security-vetted base images are used. Instead of relying on occasional manual checks, organizations implement scheduled scans, allowing security teams to detect vulnerabilities consistently and track changes over time. To further enhance visibility, Dependency Track (DepTrack) is introduced to continuously monitor vulnerabilities across all images, providing historical tracking, automated alerts, and a central repository for security insights.

  • Private Image Repositories enforce control over base images, reducing risk
  • Scheduled scanning replaces inconsistent manual reviews, improving accuracy
  • DepTrack continuously monitors vulnerabilities, alerting teams to new risks

Next Up: Moving up to Levels 3 & 4

At this stage, organizations understand vulnerabilities but lack structured enforcement. The next steps include: 

  • Enforcing the use of secure images, like Root’s Images Catalog, to prevent vulnerabilities at the source. 
  • Integrating vulnerability management into the CI/CD pipeline to block insecure images. 
  • Automating remediation which can be done by leveraging Root’s patching system and AVR.

In an upcoming post, we’ll explore Levels 3 & 4, showing how organizations can enforce security at scale—ensuring that only patched, secure images make it to production.

John Amaral

root.io