Anchore - Container Scanner That Actually Tells You What's Inside

Anchore scans container images and tells you what's inside them. Unlike most security tools that just scan for vulnerabilities, Anchore starts by generating a Software Bill of Materials (SBOM) that lists every package, library, and dependency in your containers. Then it scans those components for known security issues.

The main value? You finally know what's actually running in production. Had a Log4j incident? Anchore can tell you which containers are affected in minutes instead of days. Though honestly, if you haven't been tracking your dependencies already, that's on you.

The Three Parts That Actually Matter

Anchore Secure finds vulnerabilities and other nasty stuff. It scans for known CVEs, malware, and leaked secrets. The scanning is fast - takes about 30 seconds for a typical Node.js container. But you'll spend way more time dealing with the false positives it throws at you. And trust me, there will be a lot of them.

Anchore Enforce blocks deployments that fail your security policies. This is where things get interesting (and frustrating). You write JSON policies that define what's allowed. First time you enable this, it'll break half your deployments because of some random OpenSSL vulnerability from 2019 that doesn't actually affect your app. I learned this the hard way during a Friday afternoon deployment.

Anchore SBOM manages all your software bills of materials. Supports SPDX, CycloneDX, and Anchore's own format. The SBOM management is actually pretty solid - you can import external SBOMs, track license compliance, and generate reports that make auditors happy.

Why It Exists: The Open Source Tools

The whole platform is built on two open source tools that you can use for free:

Syft generates SBOMs from container images. Works on filesystems and source code too. Has 7.6k GitHub stars and actually works reliably. The SBOM generation is surprisingly good - catches most dependencies, though it sometimes misses weird package managers. I've had it choke on some custom Maven setups, but that's probably Maven's fault anyway.

Grype scans for vulnerabilities using the SBOMs from Syft. 10.6k GitHub stars and updates its vulnerability database multiple times per day. Works well, but like all vulnerability scanners, you'll get false positives. Lots of them.

Honestly, most teams can get by with just these free tools. The Enterprise platform adds policy management, a web UI, and compliance reports - nice to have, but not essential unless you're dealing with government contracts or have compliance people breathing down your neck.

How the Damn Thing Works

Anchore Enterprise (current version 5.19 as of August 2025) runs as a bunch of containers that talk to each other. Uses PostgreSQL for storage and has these main services:

• Data Syncer: Downloads vulnerability feeds from NVD, Red Hat, and others. Takes forever on first boot - about 45 minutes to sync everything. Sometimes longer if their feeds are having a bad day.
• Policy Engine: Runs your policy rules against scan results. This is where you'll spend most of your tuning time trying to make the damn thing stop flagging every OpenSSL version ever released.
• Analyzers: Actually scan the images and generate SBOMs. Can be CPU-intensive if you're scanning large images. I once watched it chew through 8 cores scanning a bloated Python image.
• API Server: REST API for everything. Well-documented and actually works, which is refreshing.

You can run it on Kubernetes (they provide Helm charts), Docker Compose, or use their pre-built AWS AMIs. The Kubernetes deployment is the most battle-tested option, though the resource requirements are higher than what they tell you in the docs.

For air-gapped environments, you can run it offline, but you'll need to manually download and import vulnerability database updates. Pain in the ass, but it works. Just budget extra time for explaining to security teams why the vulnerability data is a week old.

Start With the Free Tools First

Before spending money on Enterprise, try the open source tools - seriously. Install Syft and Grype and see if they actually work in your environment. Takes 5 minutes and might save you thousands of dollars. Trust me on this one.

## Install both tools (macOS)
## See: https://github.com/anchore/syft#installation
brew install anchore/syft/syft anchore/grype/grype

## Test on a real container - this will take about 30 seconds
syft nginx:latest -o cyclonedx-json > sbom.json
grype nginx:latest --fail-on medium

If Grype finds 50+ vulnerabilities in nginx (it will), and 40 of them are false positives that don't affect your use case (they will be), then you know what you're getting into. Welcome to the wonderful world of vulnerability scanning.

CI/CD Integration: Where Things Get Real

The GitHub Action works but will break your builds the first time you use it. The new one-time scan feature in 5.19 makes CI/CD integration faster (no persistent storage), but you lose historical scan data. Here's what actually happens:

- name: Scan container image
  uses: anchore/scan-action@v4  # https://github.com/marketplace/actions/anchore-container-scan
  with:
    image: \"myapp:latest\"
    fail-build: true
    severity-cutoff: medium  # This will fail. Start with \"high\"

First deployment gotchas (that will ruin your day):

• The action downloads a 150MB vulnerability database every time - cache it or your builds will take forever and your CI minutes will disappear
• Setting severity-cutoff: medium will fail 90% of images due to CVE-2022-3602 and other ancient OpenSSL vulnerabilities that don't affect your containerized app
• The scan takes 2-3 minutes for typical Node.js images, 5+ minutes for large Python images. I once had a 4GB Python image with every fucking ML library known to man - took 15 minutes and maxed out the GitHub Action timeout

What actually works:

• Start with severity-cutoff: high and fail-build: false to see what breaks
• Use content hints to suppress false positives (you'll need this, trust me)
• Run scans in parallel with builds, not blocking them initially

For Jenkins, the plugin is decent but you'll need to tune the timeout settings - default 300 seconds isn't enough for large images. Learned that one the hard way.

Kubernetes Deployment: The Real Challenge

The Helm chart works but needs serious resource tuning. Default resource requests are way too low:

## What the docs suggest (doesn't work under load)
catalog:
  resources:
    requests:
      memory: \"1Gi\"
      cpu: \"1\"

## What you actually need
catalog:
  resources:
    requests:
      memory: \"4Gi\"      # Scanning large images eats RAM
      cpu: \"2\"
    limits:
      memory: \"8Gi\"      # Prevent OOM kills

Deployment gotchas that will bite you:

• Initial vulnerability database sync takes 45+ minutes - plan for this during deployment. The database is fucking massive (600GB+ after decompression)
• PostgreSQL needs proper persistent storage or you'll lose scan history. Learned this when our PV got wiped and we lost 3 months of scan data
• The default ingress config doesn't work with most ingress controllers. You'll get 503 Service Temporarily Unavailable errors until you fix the annotations
• Memory limits are bullshit. Catalog service will OOM kill with anything less than 4GB under real load

I spent an entire weekend troubleshooting why our deployment kept failing with CrashLoopBackOff before realizing the memory limits were way too low. The pods would start, eat through 1GB scanning one Python image, then die. Don't be like me - just give it 8GB and move on with your life.

Air-Gapped Deployments: Pain in the Ass

Air-gapped deployment is technically possible but prepare for suffering:

1. Manual database updates - Download vulnerability feeds externally, sneakernet them in (yes, really)
2. Container registry challenges - All Anchore images must be mirrored to your internal registry
3. Certificate nightmares - Custom CAs, proxy configurations, TLS everywhere

The process works but takes 2-3x longer to set up than connected deployments. Budget extra time for troubleshooting connectivity issues. And when I say extra time, I mean weeks, not days.

Policy Management: Where You'll Spend Most of Your Time

Writing Anchore policies is like configuring a firewall - start permissive and gradually tighten. The JSON syntax is verbose and easy to screw up:

{
  \"id\": \"no-high-vulns\",
  \"version\": \"1_0\",
  \"rules\": [
    {
      \"gate\": \"vulnerabilities\",
      \"trigger\": \"package\",
      \"action\": \"stop\",
      \"params\": [
        {
          \"name\": \"severity_comparison\",
          \"value\": \">=\"
        },
        {
          \"name\": \"severity\", 
          \"value\": \"high\"
        }
      ]
    }
  ]
}

Policy development reality:

• First policy deployment will break everything - plan a maintenance window
• Whitelisting false positives becomes a daily task (seriously, daily)
• Different teams need different policies - you'll end up with 5+ policy variants

Progressive rollout that actually works:

1. Week 1-2: Monitor mode only, collect data on current violations
2. Week 3-4: Enforce on non-production environments, fix major issues
3. Week 5+: Gradual production enforcement with escape hatches

The policy hub has good starting templates for NIST, CIS, and STIG compliance, but you'll need to customize them for your environment. And by "customize" I mean "completely rewrite" because their default policies are way too strict for most real-world applications.