Container Image Scanning Setup | Cloud DevOps Solutions

Image Vulnerability Scanning for Kubernetes with Trivy or Snyk

We add vulnerability scanning where it prevents real risk: in CI before an image is pushed, in the registry on a schedule, and in the cluster for what is actually running. Trivy or Snyk results feed clear policies, such as which severities block a build, so findings get fixed, not ignored.

Key takeaways

Scan at three points: in the pipeline, in the registry and in the running cluster.

Not every CVE deserves a build failure; fixability and exploitability decide what blocks.

Smaller, current base images remove more risk than any scanner configuration.

Trivy is open source and flexible, Snyk adds developer workflow and commercial support.

Ownership matters: findings need a named team, a deadline and an exceptions process.

The goal is fewer risky images, not more reports

Installing a scanner is easy. Making it useful is the work. Plenty of teams switch on image scanning, receive thousands of findings, decide it is too noisy, and stop looking. The vulnerabilities did not go away; the signal did.

Our approach to Kubernetes image vulnerability scanning, part of our Kubernetes consulting service, is to put scanning where it changes behaviour, set a policy people can live with, and shrink the underlying problem at source. It connects directly to your CI/CD pipeline and to container work.

Three places to scan

Stage	What it catches	Why it matters
CI, before push	Vulnerabilities in the image you are about to ship	Cheapest place to fix, tied to the commit
Registry, scheduled	New CVEs in images already stored	Old tags are still deployable
Cluster, continuous	What is running right now	Shows real exposure, including images nobody rebuilt

Doing only the first leaves a blind spot: an image built six months ago and untouched since was clean when built and is not now.

Trivy or Snyk

Trivy is open source, runs as a single binary and scans OS packages, language dependencies, infrastructure code and exposed secrets. Snyk Container is a commercial product with a strong developer workflow, base image upgrade recommendations and managed prioritisation. They are not exclusive; some teams use Trivy in pipelines and an enterprise tool for reporting.

Concern	Trivy	Snyk
Cost	Free	Paid tiers
Setup in CI	One step	One step plus account and token
Prioritisation and fix advice	Basic (fixed version info)	Richer, with base image suggestions
In-cluster scanning	Trivy Operator	Snyk controller
Support	Community	Vendor

We choose with you based on budget, compliance expectations and how much triage effort your team can absorb.

A pipeline step that behaves sensibly

A GitHub Actions job scanning a freshly built image and failing only on fixable high and critical findings:

- name: Scan image
  uses: aquasecurity/[email protected]
  with:
    image-ref: ghcr.io/example-org/api:${{ github.sha }}
    severity: CRITICAL,HIGH
    ignore-unfixed: true
    exit-code: "1"
    format: table

Pin the action to a version you have verified. ignore-unfixed keeps the pipeline from failing on issues nobody can patch yet. For the cluster side, the Trivy Operator runs as a Kubernetes operator and publishes vulnerability reports as custom resources you can alert on.

Policy: what blocks, what tickets

A policy we commonly start with:

Block critical and high findings with an available fix, in production-bound images.
Ticket medium findings with an owner and a time limit.
Record everything else, reviewed periodically.
Exceptions require a reason, an owner and an expiry date.

Also consider exploitability. A critical CVE in a library your service never loads is lower priority than a high severity flaw in an internet-facing path. Context beats raw severity, which is where tools with reachability analysis or VEX data help.

The bigger lever: fewer packages

Most findings come from the base image. Cutting them is more effective than triaging them:

Use minimal or distroless images, and multi-stage builds so compilers and package managers do not ship.
Pin base image digests and update them regularly through Renovate or Dependabot.
Rebuild on a schedule so base image fixes reach production even when application code is unchanged.
Run as non-root with a read-only filesystem to limit the impact of whatever remains.

Worked example: reading a first scan honestly

On a first baseline scan, expect a long list and resist the urge to fix it top to bottom. We group findings by image layer instead. Typically one or two base images account for most of the volume, so moving those to a current, slimmer base clears a large share in a single change. The remainder splits into application dependencies, which Renovate or Dependabot can raise as pull requests, and unfixed operating system packages, which go on the record with an expiry date.

Then we look at exposure. Which of the remaining images face the internet, run privileged, or hold credentials? Those get fixed first, regardless of raw severity ordering. This turns an overwhelming report into a short, owned list.

Enforcement in the cluster

Scanning tells you what is wrong. Admission policy can stop the worst from running. With Kyverno or a similar engine you can require images to come from approved registries, forbid the latest tag, and, with signing through Cosign, verify that images were built by your pipeline. Pair this with least privilege access so a compromised workload has little to work with. Because GitOps records which image digest runs where, answering “where is this vulnerable image deployed?” takes minutes.

Trade-offs and when not to over-engineer

Very early stage: a single Trivy step in CI with a lenient policy delivers most of the value. Do not build a vulnerability management programme for two services.
Regulated industries: you may need evidence, retention and attestations. We plan reporting accordingly, but formal compliance assessment is separate.
Scanner disagreement: tools use different databases and may report different counts. Do not chase parity; pick one source of truth.
Cost of Snyk or similar: per-developer or per-project licensing adds up, so evaluate against what you will actually use.

Common failure modes

Failing builds on every CVE, then adding exit-code: 0 everywhere.
Scanning only at build, never again.
Ignore lists with no expiry.
Huge images with full OS toolchains, producing endless noise.
Nobody assigned to the findings queue.

Delivery and how to tell it works

You get scanning wired into CI, registry and cluster, a written triage policy, base image recommendations, dashboards of open findings by team, and alerts for new criticals in running workloads. It works when the count of fixable high findings trends down, builds fail rarely and for good reason, and you can answer a headline CVE question about your estate in minutes. To plan this for your stack, contact us.

References

How we deliver it

Baseline what you run

We scan current images to see the real starting position and find the largest sources of findings.

Choose tooling

Trivy, Snyk or both are selected based on budget, language coverage and workflow preferences.

Integrate into CI

Scans run on every build with a severity policy, producing reports and optionally SBOMs.

Add registry and cluster scanning

Scheduled registry scans and an in-cluster operator catch new CVEs on already deployed images.

Define triage policy

Rules decide what blocks, what is ticketed, how exceptions work and who owns fixes.

Reduce the noise at source

We help move to slimmer base images and automate dependency updates.

Frequently asked questions

Trivy or Snyk, which should we choose?

Trivy is free, fast and covers OS packages, language dependencies, IaC and secrets, so it is a strong default. Snyk offers a polished developer experience, fix suggestions, prioritisation and vendor support, at a licence cost. Many teams use Trivy in CI and consider Snyk when they want managed prioritisation.

Should vulnerabilities fail the build?

Only some. A reasonable start is failing on critical and high severity findings that have a fix available, and reporting the rest. Failing on every finding stops delivery and trains people to bypass the scanner. We tune the policy against your baseline, then tighten it as the backlog shrinks.

Why scan again after the image is deployed?

New vulnerabilities are published daily. An image that was clean on build day may have critical findings a month later. Registry or in-cluster scanning re-evaluates what is running against fresh vulnerability data, so you learn about it without waiting for the next build.

What is an SBOM and do we need one?

A software bill of materials lists the components inside an image. Tools like Syft or Trivy generate one in formats such as SPDX or CycloneDX. It helps you answer 'are we affected?' quickly when a new CVE lands, and some customers and regulations now ask for it.

How do we deal with false positives and unfixable CVEs?

Use VEX statements or the scanner's ignore file with a reason and an expiry date, reviewed by the owning team. Prefer fixing by updating the base image. Exceptions without expiry dates pile up silently, so we build the review into the process.

Does scanning make images secure?

No. It finds known vulnerabilities in packages. It does not detect logic bugs, misconfiguration or zero-days. Combine it with minimal images, non-root containers, signed images, admission policy and runtime controls. Scanning is one layer of several.