Vulnerability Management, Part 2: Finding Vulnerabilities in Docker Images

Introduction

In Part 1 we explored how tools like OSV-Scanner help you detect vulnerabilities in application-level dependencies (think requirements.txt, package-lock.json, etc.).

But in real-world containerised deployments the risk surface is bigger.
Every image you ship includes:

• a base operating-system layer (e.g., Ubuntu, Amazon Linux, Debian)
• any packages you install during the Docker build (via apt install, yum install, etc.)
• your application dependencies (npm, pip, etc.) layered on top

This Part 2 focuses on vulnerability detection in Docker images - how to scan all the layers, integrate scanning into your CI/CD pipeline, and reconcile results between tools like Trivy and AWS Inspector.

                   ┌────────────────────────────┐
                   │     Developer / CI/CD      │
                   │  (GitHub Actions, etc.)    │
                   └────────────┬───────────────┘
                                │
                                │ 1️⃣  Prevent vulnerabilities early
                                ▼
                     ┌────────────────────┐
                     │       Trivy        │
                     │  Image & FS Scans  │
                     │ (OSV / app libs)   │
                     └────────┬───────────┘
                              │
                              │ Push only clean images
                              ▼
                     ┌────────────────────┐
                     │   Amazon ECR       │
                     │  (Image Registry)  │
                     └────────┬───────────┘
                              │
                              │ 2️⃣  Detect issues in production
                              ▼
                     ┌────────────────────┐
                     │   AWS Inspector    │
                     │ Continuous Scans   │
                     │  (ECR, Lambda, EC2)│
                     └────────┬───────────┘
                              │
                              │ Findings exported to
                              ▼
                     ┌────────────────────┐
                     │  AWS Security Hub  │
                     │  (Central View)    │
                     └────────┬───────────┘
                              │
                              │ 3️⃣  Track + Report
                              ▼
                     ┌────────────────────┐
                     │       Vanta        │
                     │  Compliance & SLA  │
                     │  Evidence tracking │
                     └────────────────────┘

Why Image Scanning Matters

At InfraHouse, we like to treat security vulnerabilities as small incidents. Just like operational incidents, they require a structured response:

• Prevent them from occurring in the first place,
• Detect them quickly if they slip through, and
• Remediate before they cause real impact.

In vulnerability management, the same logic applies.

We aim to detect vulnerabilities before they reach production - using tools like Trivy or OSV-Scanner in CI to block vulnerable builds.

When issues do make it into production, we rely on AWS Inspector to detect and surface them as early as possible, enabling fast remediation and continuous learning.

This mindset turns vulnerability management from a reactive firefight into a continuous-improvement loop - one that prevents incidents, detects what slips through, and drives better engineering hygiene over time.

That’s why introducing developer-side scanning with Trivy is critical. Trivy runs in your CI/CD build step (or local dev environment) and catches issues before an image is pushed - giving developers time to fix them while the cost of change is still low.

Image scanning bridges prevention and detection:

• Prevention: block or flag vulnerable images during CI/CD with Trivy.
• Detection: continuously monitor deployed workloads with AWS Inspector.

Together, they close the feedback loop - find -> fix -> learn - building a resilient foundation for your security posture.

The Scanning Ecosystem

AWS Inspector

• Automatically scans container images in Amazon ECR, Lambda bundles, or EC2 hosts.
• Uses multiple feeds (NVD, distro OVAL, AWS proprietary mappings) to detect OS + library vulnerabilities.
• Ideal for post-deployment monitoring.

Trivy

• Open-source, CI-friendly scanner.
• Supports scanning:
  • Container images (trivy image ...)
  • File systems (including source + lockfiles)
  • SBOMs (trivy sbom …)
• Can detect OS-level packages and application dependencies (npm, pip, etc.).
• Works perfectly for “shift-left” scanning in build pipelines.

Both tools play complementary roles in a mature DevSecOps process - Trivy enforces preventive controls in CI, while Inspector provides detective coverage once the image is live.

Scanning Layers: What Trivy Actually Sees

Base Image

When you run:

trivy image ubuntu:24.04

Trivy extracts OS packages, matches them against advisories, and identifies issues like outdated libssl3, old curl, etc.

Build Layer

Example Dockerfile excerpt:

FROM node:22
RUN apt-get update && apt-get install -y ffmpeg
COPY . .
RUN npm ci

You’d scan it with:

trivy  image --scanners vuln --exit-code 1 myapp:latest

This finds vulnerabilities both in the ffmpeg OS package and in npm dependencies.

Application Dependencies

Before the image build (or in a separate step), you might scan the source tree:

trivy fs --scanners vuln --exit-code 1 .

This focuses on lock-files (e.g., package-lock.json, poetry.lock) - what we covered in Part 1.

Security SLAs and Trivy Flexibility

In Part 1 we discussed how OSV-Scanner fits into your security SLAs - e.g., “fix critical library vulns within 48 h, high within 7 days.” Trivy gives you the same flexibility when scanning images, letting you enforce SLAs while maintaining dev velocity.

Here’s how you can implement that:

1. Temporarily ignore known issues

Create a .trivyignore file in your repo:

# .trivyignore
CVE-2025-30204 # Base image openssl vuln - patch pending upstream
CVE-2025-22870 # npm transitive dependency, tracking upstream fix

This lets you defer non-urgent issues but still track them.

2. Use expiration comments

Encourage discipline by including tickets and dates:

# .trivyignore
CVE-2025-30204 exp:2025-04-28 # Base image openssl vuln - patch pending upstream (APP-1234)
CVE-2025-22870 exp:2025-04-28 # npm transitive dependency, tracking upstream fix (APP-1235)

That way you avoid “permanent ignores”.

3. Integrate Trivy into your CI workflow

You can run the following commands to validate your builds and images before pushing:

      - name: Scan code for vulnerabilities
        run: |
          trivy fs --ignore-unfixed --exit-code 1 .          

      - name: Build docker image
        run: docker build -t myapp:latest

      - name: Scan Docker image for vulnerabilities
        run: |
          trivy image --ignore-unfixed --exit-code 1 myapp:latest          

Reconciling AWS Inspector & Trivy Results

You may still see cases where AWS Inspector flags a CVE that Trivy does not, or vice-versa. Why?

• Different vulnerability databases or ingestion dates
• CPE/CVE mapping differences between tools
• Stale Trivy DB (I recommend running Trivy on self-hosted GitHub Action runners with a limited max lifetime to keep databases fresh)
• Scanning different artifacts (ECR image vs. local build)
• Scanning different layers (OS vs. application dependencies vs. transitive dependencies)
• Different dependency sources: AWS Inspector can sometimes infer vulnerable versions directly from package.json, even if a package-lock.json is missing or incomplete. Trivy, by contrast, primarily relies on lockfiles (package-lock.json, yarn.lock, etc.) to determine the exact dependency graph. This means Inspector may flag vulnerabilities that Trivy won’t see if the lockfile hasn’t yet been generated or committed.

To align both tools:

• Run Trivy on the same image digest Inspector flagged (trivy image <sha256:...>).
• Use --ignore-unfixed=false so you don’t skip unfixed CVEs.
• Export both reports to JSON and diff by VulnerabilityID.
• Use a central dashboard for tracking (Vanta is great for collecting vulnerabilities from different sources and tracking tickets).
• For Node.js projects, ensure lockfiles are generated and committed before scanning - it’s the only way Trivy can reliably reproduce Inspector’s results.

Best Practices

• Pin your base images using digests rather than tags:

  FROM ubuntu@sha256:...
  

• Limit unnecessary build-time installs; every apt install, yum install, or custom binary added to the image increases attack surface.

• Add scanning to CI/CD early (left shift). Example GitHub Action above.

• Generate SBOMs alongside builds for auditability and traceability.

• Track ignores with tickets, expiration dates, and clear accountability.

• Regularly update your Trivy DB, ideally using self-hosted runners with a limited lifetime to ensure freshness.

• Use both prevention + detection: prevention via Trivy in CI, detection via AWS Inspector in runtime.

Takeaway

Part 1 was about finding issues in your codebase. In Part 2 we broaden the scope to include your runtime environment - the actual container image that gets deployed.

By combining prevention (Trivy) and detection (AWS Inspector) with clear SLAs and disciplined ignore workflows, you build a resilient process: one that catches “small incidents” early, gives devs time to fix them, and prevents escalation into major issues.

Call to Action

If your team uses AWS and runs containerised workloads, InfraHouse can help you automate your vulnerability-management pipeline - from Trivy + Inspector integration to centralized reporting and compliance dashboards.

👉 Contact InfraHouse and let’s strengthen your cloud security posture together.