Examples in this article are illustrative, not customer case studies. Product availability and coverage are described on the linked capability pages.
Open-source container image scanners are good enough that most teams start with one and never pay for the scan itself. The trouble starts when two of them disagree about the same image, or when the report has no idea which service runs it. This guide sets out what Trivy, Grype, Syft and Dockle each do, according to their own READMEs, how to run them in a pipeline, and where the work they leave to you begins.
The short version: Trivy and Grype find vulnerable packages, Syft builds the SBOM they read, and Dockle checks how the image was built rather than what is inside it. They are complements, not substitutes, and the strongest open-source setup uses more than one.
The worked example is a platform team that owns the base images and the CI templates for a few dozen services. They want one scan step every pipeline can include, an SBOM kept per release, and a gate that blocks the obvious mistakes without stopping every build.
Trivy covers the widest range of container image checks
Trivy is an open-source security scanner whose README lists container images, filesystems, git repositories, virtual machine images and Kubernetes as targets. Its scanners find vulnerable OS packages and language dependencies, infrastructure-as-code misconfigurations, including Dockerfiles, exposed secrets and licences, and it can generate an SBOM in CycloneDX or SPDX. Output formats include a table, JSON and SARIF. It is licensed under Apache 2.0.
For the platform team, Trivy is the natural single step: one binary, one command and a severity threshold that sets the exit code, for example trivy image --exit-code 1 --severity CRITICAL <image>@<digest>. The breadth is also its limit. A secrets hit, a misconfiguration and a CVE arrive in one report, and someone still has to decide which of them belongs to which team.
Grype focuses on container image vulnerability matching
Grype is a vulnerability scanner for container images and filesystems, maintained by Anchore. Its README lists major Linux distributions and language ecosystems among the package types it matches, and it can scan an SBOM directly instead of the image. It writes table, JSON, CycloneDX and SARIF output, and a --fail-on severity flag makes it usable as a gate. It is licensed under Apache 2.0.
Running Grype alongside Trivy is common for a reason. Each tool draws on its own vulnerability data and matching logic, so the two lists for the same image rarely match exactly. A second opinion catches packages one tool misidentified, and it surfaces disagreements that are worth a closer look rather than an automatic ticket.
Syft builds the SBOM that the scanners read
Syft is an SBOM generator for container images and filesystems, also from Anchore. It catalogues OS packages and language dependencies and writes CycloneDX, SPDX or its own JSON format. It does not report vulnerabilities on its own. It is licensed under Apache 2.0.
Separating the inventory from the matching pays off over time. The platform team can generate the SBOM once per digest, keep it as a release artefact, and rescan it when a new advisory lands, without pulling the image again. The difference between an inventory and a vulnerability answer is set out in SCA vs SBOM: what each answers and why you need both.
Dockle checks how the image was built
Dockle is a container image linter. Its README describes checks for security and Dockerfile best practice, including items drawn from the CIS Docker Benchmark: running as root, leaving credentials in environment variables or layers, missing health checks and using latest. It inspects the built image rather than the Dockerfile, and it can return a failing exit code. It is licensed under Apache 2.0.
Dockle finds nothing a CVE scanner finds, which is exactly why it is worth the extra step. An image with no known vulnerabilities that runs as root with a token baked into a layer is not a clean image. For the platform team, Dockle in the shared template stops those build mistakes from spreading to every service that copies it.
Open-source container image scanners compared
| Tool | Primary job | Finds CVEs | SBOM output | Gate flag | Licence |
|---|---|---|---|---|---|
| Trivy | Broad image scanning | Yes | CycloneDX, SPDX | --exit-code |
Apache 2.0 |
| Grype | Vulnerability matching | Yes | CycloneDX | --fail-on |
Apache 2.0 |
| Syft | SBOM generation | No | CycloneDX, SPDX | Not applicable | Apache 2.0 |
| Dockle | Image build best practice | No | No | --exit-code |
Apache 2.0 |
A practical pipeline uses them in order. Syft writes the SBOM, Grype or Trivy matches it, Trivy adds secrets and misconfiguration checks, and Dockle lints the image. Every step targets the image digest, not a tag, so the report describes the exact bytes that will be promoted.
Running container image scanning in CI needs a digest and a policy
The step itself is easy in GitLab CI, GitHub Actions or any other runner: build, push, resolve the digest, scan by digest and fail on a threshold. The hard part is the threshold. Fail on every critical CVE and the gate blocks builds over packages nobody can patch today, so teams quietly add exceptions. Fail on nothing and the scan becomes a report nobody reads.
A better rule combines severity with context: block on critical findings that have a fix available, on exposed secrets and on Dockle’s root and credential checks, and record everything else for prioritisation. That still leaves the question every scanner leaves open, which is whether the vulnerable image runs anywhere that matters. How to prioritise container vulnerabilities covers the signals that answer it.
Key takeaways
- Use Syft for the inventory and keep one SBOM per image digest as a release artefact.
- Run Trivy or Grype for vulnerabilities, and treat disagreements between them as items to inspect.
- Add Dockle to the shared CI template so build mistakes do not spread to every service.
- Scan by digest and gate on fixable critical findings, secrets and root images, not on raw severity counts.
How SecurityVault approaches this
SecurityVault runs Trivy, Grype, Syft and Dockle alongside its native engine’s image mode, against a digest-pinned reference, as ephemeral jobs in an untrusted scan band with no platform credentials. Results that agree resolve to one finding, so a CVE reported by several tools is one item in the queue rather than several.
The image SBOM is stored as components and layers, which drives layer attribution and base-image recommendations. Each digest sits on the same graph as the commit that built it and the workloads that run it, so a finding is ranked by the exposed services running the image and routed to the team that owns the fix. See container security for the full flow, including signature and provenance checks.
Promotion is decided by fail-closed deployment gates written in Open Policy Agent, so the context-aware rule above can be expressed as policy and every decision is recorded as evidence.
Start with the quickstart to connect one registry and one cluster, or talk to our team.