What Is Vulnerability Scanning? A Quick Intro to Docker and Package Scanning with Trivy

🌏 中文版

TL;DR

The goal of vulnerability scanning isn’t to drive report numbers to zero — it’s to quickly identify which known vulnerabilities exist in your system, where they come from, and which ones actually need immediate attention. Tools like Trivy make it straightforward to scan Docker images, OS packages, language packages, and even repository configurations and secrets. The key isn’t just knowing how to run the commands — it’s understanding whether a finding comes from your application or from the base image / toolchain.

What Vulnerability Scanning Actually Does

Vulnerability scanning works by comparing the components installed in your system against a database of known vulnerabilities, checking whether your current versions match any publicly disclosed CVEs or security advisories.

In a development context, common scan targets include:

• OS packages — packages installed in Alpine, Debian, Ubuntu, etc.
• Application dependencies — npm, pip, Maven, Go modules
• Container images
• IaC / configuration files — Dockerfiles, Terraform configs, Kubernetes manifests
• Secrets — tokens or keys accidentally committed to a repo

So vulnerability scanning isn’t just checking “does my code have bugs” — it’s looking at which known-risky components exist across your entire deliverable.

Why Engineering Teams Should Run Vulnerability Scans

The reasons are pretty practical.

First, many vulnerabilities aren’t introduced by code you wrote — they come from third-party packages or base images. Second, modern systems are deeply reliant on open-source components, and without scanning it’s genuinely hard to know what you’ve shipped to production. Third, vulnerability scanning gives remediation work a clear priority order, rather than triggering blanket major version upgrades every time a security issue surfaces.

The real value of vulnerability scanning isn’t “having a report” — it’s answering these questions:

• Where does this risk live?
• Which component introduced it?
• Is it a direct dependency or a transitive one?
• Is it actually coming from the base image?
• Does this risk need to be addressed right now?

Common Misconceptions

1. Red findings mean it’s definitely my app’s problem

Not necessarily.

When scanning a Docker image, scanning tools typically analyze the entire image filesystem — not just your app directory. That means a finding could come from:

• Your app’s dependencies
• OS packages in the base image
• Toolchain components bundled in the base image (npm, Python runtime, Java runtime, etc.)

So when you see packages like tar, openssl, or glibc flagged, that doesn’t automatically mean they were installed through your package.json or requirements.txt.

2. All vulnerability counts must be zeroed out

Ideal in theory, but not always practical.

Some vulnerabilities:

• Are never reachable in your actual execution paths
• Haven’t had a fix released upstream yet
• Would require a major version upgrade that carries more risk than the vulnerability itself
• Only exist in build-time tooling that never makes it into the runtime

Vulnerability scanning is more like risk management than a numbers game.

3. Upgrading app packages will fix everything

Also not necessarily true.

Some vulnerabilities live in the base image or toolchain itself. A classic example in Node.js images: your project’s dependencies are fully up to date, but the npm bundled inside the image still carries an old version of tar, glob, or minimatch. In that case, what needs changing is the Dockerfile — not package.json.

What Is Trivy?

Trivy is an open-source security scanner from Aqua Security. Its strengths are:

• Easy to install
• Supports a wide range of scan targets
• Straightforward CLI
• Well-suited for integrating into development workflows or CI pipelines

Common Trivy use cases include:

• Scanning container images
• Scanning filesystems / project directories
• Scanning repository misconfigurations
• Scanning for secrets
• Scanning SBOMs

If your goal is to quickly establish baseline vulnerability scanning capability for your team, Trivy is a great starting point.

What Trivy Can Scan

Scanning an image

This is the most common use case:

trivy image node:22-alpine

Or scan your own built image:

trivy image your-app:latest

This mode typically produces two categories of results:

• OS packages
• Language packages

Scanning a project directory

To check dependency issues directly in your repository without building an image:

trivy fs .

This is convenient for projects not yet packaged as images — it reads from lockfiles and dependency manifests directly.

Scanning for secrets

trivy fs --scanners secret .

This helps surface anything in your repo that looks like credentials, tokens, or private keys.

Scanning for misconfigurations

trivy config .

This targets insecure configurations in Dockerfiles, Terraform configs, Kubernetes manifests, and similar files.

How to Read Trivy Results When You’re Starting Out

A lot of people get overwhelmed by the volume of findings at first. A more useful approach is to break down the results across three dimensions.

Start with: which layer does this belong to?

First, distinguish between:

• Is this an OS package?
• Is this an app dependency?
• Is this a dependency of the toolchain itself?

This step is critical because it directly determines where the fix needs to happen:

• Update the base image
• Modify the Dockerfile
• Update package.json / lockfile
• Or accept the risk for now

Then look at severity

You’ll typically see LOW, MEDIUM, HIGH, and CRITICAL. But don’t stop at severity alone — also consider:

• Whether the package actually exists in the runtime environment
• Whether a fixed version is available
• Whether your system actually exercises the vulnerable code path

Finally, check whether a fix is available

Trivy often lists a fixed version directly. At that point, ask:

• Is it just a patch version bump?
• Does it require a major version upgrade?
• Is this a direct or transitive dependency?
• Is the fix in the app, or in the image?

A Practical Investigation Flow

When scanning a Docker image, I recommend consistently following this sequence:

1. Look at the image report: note the package name, installed version, and fixed version
2. Check your app’s dependency tree — does your project actually install that package?
3. If it’s not in your dependency tree, inspect the base image’s bundled toolchain inside the container
4. Once you’ve confirmed the source, decide whether to upgrade the app package or the base image / npm / other toolchain component

The benefit of this flow: you won’t reflexively edit package.json every time you see an npm ecosystem package name in the report.

Recommendations for Getting Started with Trivy

If your team is just starting out, there’s no need to go all-in from day one. Start here:

1. Scan images first

Images are the closest artifact to what actually gets deployed, so those results have the most practical value.

2. Focus on HIGH / CRITICAL first

Don’t try to clear every LOW / MEDIUM immediately — that’s a fast track to team burnout.

3. Build a classification habit

Every time you look at a finding, label it as one of:

• app dependency
• base image
• toolchain
• config
• secret

This is far easier to track than maintaining a raw list of findings.

4. Add Trivy to CI, but start in notification mode

Initially, have Trivy generate reports in CI without failing the build. Once your team is comfortable reading the results, gradually tighten the thresholds.

Closing Thoughts

The hardest part of vulnerability scanning usually isn’t “how do I run the tool” — it’s “how do I interpret the results.” Trivy is a great tool for building that foundational skill: first understand what risks exist, then learn to identify their source, and only then decide how to fix them. Once you separate “app packages” from “base image / toolchain,” most reports that initially look overwhelming become much easier to reason through.

References

• Trivy Official Documentation
• Trivy GitHub
• CVE Vulnerability Database (NIST NVD)
• Docker Official Security Best Practices
• Aqua Security - What is Vulnerability Scanning?