Container Scanning

You build an image, you push it to a registry, you deploy it to production, and somewhere inside that image is a vulnerable package nobody noticed, sitting there since the base image you pulled six months ago.

Container image scanning catches that before it ships, and three open source tools dominate the conversation, Trivy, Clair, and Anchore, they all find vulnerabilities, and they do it in fundamentally different ways, which means picking the wrong one for your workflow creates gaps you will not see until something goes wrong.

This is a practical comparison based on how each tool behaves in a real pipeline.

Important Disclaimer

This article is intended for educational and defensive purposes only. The techniques described here are shared to help security and DevOps teams understand container image scanning tools so they can build safer pipelines.

Do not use these techniques against systems you do not own or do not have explicit written permission to test. Unauthorized testing is illegal in most jurisdictions.

The author assumes no liability for any damages, legal consequences, or other outcomes resulting from the use or misuse of this information. Always obtain proper authorization before conducting any testing, and stay legal, stay ethical, stay responsible.

The Architectural Difference That Explains Everything

Before comparing features, understand how each tool is built, because that single fact determines how it fits into your workflow.

• Trivy is a command. You download a binary, you point it at an image, it prints findings. There is no server, no database to host, no API to call. It runs where you run it, when you run it.
• Clair is a service. It runs continuously, indexing image layers and exposing an API that clients query. It is designed to live next to a registry, not inside a build step.
• Anchore is a platform. It runs as a centralized service that stores analysis results, applies policy, and manages evaluation across many images and teams. It expects to be operated, not just invoked.

That distinction matters more than any feature list. Trivy is something you run. Clair is something you host. Anchore is something you operate.

Feature Comparison

Trivy: The One You Will Probably Start With

Trivy is the tool most teams adopt first, and the reason is simple, it does a lot with almost no setup.

One binary scans OS packages, language dependencies, infrastructure-as-code files, and secrets. It reads Kubernetes manifests. It generates SBOMs. You are not assembling a pipeline of separate tools, you are running one command.

Basic Usage

Install it, then scan an image:

trivy image registry.example.com/api:1.4.2

To turn it into a gate that fails your build:

trivy image --severity CRITICAL,HIGH --exit-code 1
 registry.example.com/api:1.4.2

That exit code is what changes behavior. Without it, Trivy is a report nobody reads. With it, the pipeline stops.

In a GitHub Actions Workflow

- name: Scan image
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: 'registry.example.com/api:${{ github.sha }}'
    severity: 'CRITICAL,HIGH'
    exit-code: '1'
    format: 'sarif'
    output: 'trivy-results.sarif'

The SARIF output lands in GitHub's Security tab, which puts findings where developers already look.

Where Trivy Struggles

Its vulnerability database is large and updates frequently, which matters in air-gapped environments where you have to mirror it yourself.

It also has known blind spots with binaries and libraries that were not installed through a package manager. If someone compiled a dependency from source and copied it into the image, Trivy may not see it.

Clair: The Registry Scanner

Clair was built for one job, scanning images inside a registry, and it does that job thoroughly.

It indexes image layers, extracts package information, and matches against multiple vulnerability feeds. It runs as a service and re-evaluates continuously, which means an image that was clean last month can be flagged this month when a new CVE is published against a package inside it.

How It Fits in Practice

You do not run Clair in a build step. You run it as infrastructure alongside your registry. Images are scanned when they are pushed, and the registry surfaces results to users.

This model has real advantages. Scanning happens automatically, developers do not need to remember to run anything, and historical images stay covered as new vulnerabilities emerge.

Where Clair Struggles

Clair is slow compared to the alternatives, and it shows in benchmarks.

It has limited SBOM support and almost no policy engine. You get findings, but you do not get a way to say "block this image unless it meets these conditions."

Its strength is depth in standard images. Its weakness is everything around the scan itself.

Anchore: The Policy Platform

Anchore is the heaviest of the three to set up and the most capable if you need governance.

It performs deep inspection of images, collecting data on files, OS packages, and language artifacts. Then it applies policy, which is where it separates itself. You define rules that go beyond "fail on critical CVE" into areas like allowed licenses, approved base images, and configuration standards.

The SBOM Side

Anchore maintains two tools worth knowing separately. Syft generates SBOMs, and Grype scans either images directly or SBOMs that were generated earlier.

That decoupling is genuinely useful. You generate an SBOM once at build time, store it, and re-scan it later when new vulnerabilities are published, without pulling the image again.

Where Anchore Struggles

Anchore requires you to run a service, manage a database, and maintain infrastructure. That is a real cost.

It has also shown weakness detecting vulnerabilities in libraries that were compiled manually or embedded outside package manager workflows, the same blind spot that affects the other tools to varying degrees.

Performance and Detection in Practice

Speed matters when you scan on every commit.

Trivy is the fastest, often finishing in seconds for typical images.

Anchore sits in the middle, the centralized service adds a round trip but remains workable for CI.

Clair is the slowest, and it is better suited to registry integration than build gating.

Detection accuracy also varies. No single tool finds everything, and independent comparisons have consistently shown that each scanner misses vulnerabilities the others catch. If you care about coverage, layering is not optional.

A Setup That Uses Each Tool Well

Here is a practical arrangement that plays to each tool's strengths.

In CI, Use Trivy

Run it on every build, fail on critical and high findings, and publish results where developers see them.

- name: Trivy gate
  run: |
    trivy image --severity CRITICAL,HIGH --exit-code 1 \
      --format sarif --output results.sarif \
      registry.example.com/api:${{ github.sha }}

Fast, simple, and it catches the majority of issues before they merge.

In the Registry, Use Clair

If you run your own registry, let Clair scan on push and re-evaluate continuously. This catches the vulnerabilities that appear after your image was built, which is where a lot of real exposure actually lives.

For Governance, Use Anchore

If you have compliance requirements, license restrictions, or base image standards, Anchore's policy engine gives you the control to enforce them consistently across teams.

For SBOMs, Use Syft and Grype

Even without adopting Anchore as your primary scanner, generating SBOMs at build time and re-scanning them later is one of the highest value habits you can build. When a critical CVE drops, you can check your entire inventory in seconds.

How to Choose

If you are starting from nothing, start with Trivy. It gives you value the same day. Add Clair or Anchore when you hit a specific limitation, not because a comparison table says so.

The Bottom Line

Trivy, Clair, and Anchore solve the same problem in different ways, and treating them as interchangeable is the mistake that creates gaps.

Trivy is fast, broad, and easy to adopt, which makes it the right default for CI gating.

Clair is thorough and registry native, which makes it right for continuous scanning of everything you store.

Anchore is policy driven and centralized, which makes it right when you need governance across teams.

The teams that get this right do not pick one, they layer. Scan in CI, scan in the registry, generate SBOMs, and re-evaluate when new vulnerabilities appear.

Scan before you deploy. Every time.

FAQ Section

What is container image scanning?

Container image scanning analyzes the contents of an image, including OS packages, language dependencies, and configuration, to find known vulnerabilities before deployment.

Is Trivy better than Clair?

They solve different problems. Trivy is faster and easier to fit into CI. Clair is built for registry integration and continuous re-evaluation. Many teams use both.

Does Anchore require a server?

Anchore runs as a centralized service, so yes, it requires setup, hosting, and maintenance. Trivy is a single binary that runs on demand.

Can I run more than one scanner?

Yes, and you should. Different scanners catch different vulnerabilities, and layering meaningfully improves coverage.

What is an SBOM and why does it matter?

An SBOM is a software bill of materials, a complete list of what is inside your image. It lets you re-scan for new vulnerabilities without pulling the image again.

Which scanner is fastest?

Trivy is fastest in typical use, Clair is slowest, and Anchore sits in between.

Do I need all three?

No. Most teams start with Trivy, add registry scanning if they run their own registry, and add policy tooling only when governance requirements demand it.