Trivy

What it is #

Trivy is an open-source security scanner from Aqua Security, distributed as a CLI under the Apache-2.0 licence. It is structured as a matrix of targets (where Trivy looks for issues) and scanners (what kinds of issues it looks for).

Targets: container images, filesystems, git repositories (remote), virtual machine images, and Kubernetes clusters.

Scanners: known vulnerabilities in OS packages and language dependencies (CVE matching), infrastructure-as-code misconfigurations, hardcoded secrets, software licences, and SBOM generation.

Trivy has broad ecosystem coverage. Language dependencies are scanned for C, Dart, .NET, Elixir, Go, Java, Julia, Node.js, PHP, Python, Ruby, Rust, and Swift. OS packages are scanned across most major Linux distributions (Alpine, Debian, Ubuntu, RHEL/CentOS, Amazon Linux, SUSE, Arch, Chainguard/Wolfi, and others).

Scanner model #

Vulnerability scanning is the core function and is fundamentally a database lookup. For each detected package, Trivy looks up known vulnerabilities against an aggregated set of advisory databases: per-OS-vendor advisories for OS packages (Red Hat OVAL, Ubuntu CVE Tracker, Alpine secdb, and similar) and language-ecosystem databases (GitHub Security Advisories, GitLab) for language packages. Per-vendor selection is deliberate: Trivy reports a Red Hat package’s severity using Red Hat’s rating rather than NVD’s, because backport behaviour changes the actual exploitable surface.

The other scanners are conceptually independent of vulnerability scanning. IaC scanning runs policy checks against Terraform, CloudFormation, Kubernetes manifests, and similar definition files. Secret scanning matches patterns against text content. Licence scanning extracts licence declarations from package manifests and source code. SBOM generation enumerates components in a target. None of these involve code execution; Trivy is a static lookup and pattern-matching engine, not a behavioural analyser.

Workflow #

The basic invocation is trivy <target> [--scanners <list>] <subject>. For example, trivy image python:3.4-alpine scans a container image; trivy fs --scanners vuln,secret,misconfig myproject/ scans a directory for vulnerabilities, secrets, and misconfigurations.

Beyond the CLI, Trivy is integrated through a wide ecosystem: a GitHub Actions action, a Kubernetes operator, IDE plugins, and CI integrations of various shapes. The data flow is the same in each case: Trivy fetches the relevant advisory databases, runs its detection passes, and emits findings.

Comparison to OpenVet #

Trivy’s scope is much broader than OpenVet’s. The IaC, secret, licence, SBOM, OS-package, and container/Kubernetes scanners cover concerns OpenVet does not address. The meaningful comparison sits in one slice of Trivy’s work: scanning language-package dependencies for known vulnerabilities. That subset overlaps with OpenVet’s territory and is where the structural contrast matters.

The structural differences, scoped to language-dependency vulnerability scanning:

Reactive vs proactive. Trivy’s vulnerability scanning is reactive: it matches detected packages against advisory databases that exist only because someone has already discovered, reported, and catalogued the vulnerability. OpenVet aims to surface problems before they reach a consumer, by having an auditor read the code and either sign claims about it or surface concerns as findings on the audit. The reactive layer is genuinely useful (some bugs are only found later, and CVE feeds are how the ecosystem coordinates after disclosure), but a defence layered entirely on what other people have already discovered accepts being late as a property.

Operating model. Trivy is an automated database lookup: it identifies packages in the scan target, queries advisory databases, and reports matches. OpenVet audits are human-authored: an auditor reads the code and signs claims about specific properties. OpenVet itself does not run any checks, it only provides the tooling and the hosting for audits.

Output shape. Trivy emits matched vulnerability records: CVE IDs, severity scores drawn from the source database, fixed-version pointers, and where the data exists exploit-availability metadata. OpenVet auditors produce structured claims (impl-crypto, uses-network) describing what a package’s own code does; aggregation across the dependency tree is performed by the OpenVet tooling against the consumer’s lockfile.

Coverage trigger. Trivy scans whatever the consumer points it at, on demand or on schedule. Coverage is bounded by the union of advisory databases Trivy consults. OpenVet covers dependencies that a human has chosen to audit, plus vulnerabilities re-published as OpenVet audits from upstream CVE sources.

Ecosystem. Trivy’s language coverage includes C, Dart, .NET, Elixir, Go, Java, Julia, Node.js, PHP, Python, Ruby, Rust, and Swift. OpenVet covers Cargo, npm, PyPI, Go modules, and RubyGems.

Using alongside OpenVet #

For language-dependency vulnerability scanning, OpenVet is intended as the replacement. OpenVet plans to re-publish known vulnerabilities as audits in its own data model, which means a consumer running OpenVet gets the same CVE coverage Trivy provides without running Trivy separately, plus the proactive audits that surface issues before disclosure. The reactive CVE layer remains useful as a backstop for cases the audits did not catch, but the primary signal moves to the audit set.

The other Trivy scanners stay relevant alongside OpenVet, because they address concerns OpenVet does not currently express. Configuration scanning (IaC and Kubernetes manifests) and secret scanning sit on a different axis from dependency review and are outside what OpenVet aims to express. OS-package and container scanning are in principle expressible in OpenVet’s data model (both resolve to content hashes that an OpenVet audit subject can be anchored to) but are not currently implemented. Auditing binary artefacts is also less informative than auditing sources: unless a binary can be reproduced from source, a reviewer can verify provenance but not contents.

A project that uses OpenVet for its application-level dependency assurance can still get value from Trivy on those other axes.