TRUSTIVAN vs. Running Trivy Yourself

Does TRUSTIVAN use Trivy?

Yes. Vulnerability matching in TRUSTIVAN is done by Trivy, an established open-source scanner, under its Apache 2.0 licence. That is not a buried dependency — it is stated plainly on TRUSTIVAN’s own why TRUSTIVAN page, because claiming the detection engine as a proprietary moat would be a claim a reader could disprove in an afternoon by reading Trivy’s own changelog.

So if the scanner is the same, what is TRUSTIVAN actually selling?

Everything that happens to a finding after Trivy reports it. Running trivy image myapp:latest on its own gives you a point-in-time list of vulnerabilities and nothing else: no memory of what you decided last time, no record of who accepted which risk, and no way for a CI pipeline to ask “may this ship” and get a single, auditable answer back. That gap is what a nightly cron job running Trivy directly does not close, no matter how often it runs.

What does TRUSTIVAN add on top of the scan?

• A finding identity that survives a rescan. Trivy’s own output has no concept of “the same finding I saw yesterday” — each run is independent. TRUSTIVAN derives identity from content (not severity, not version, not report position), so a nightly rescan does not throw away yesterday’s triage. See the finding lifecycle for the exact mechanism.
• A lifecycle with rules, not a flat list. Five states — open, triaged, suppressed, resolved, reopened — with a fixed transition table, and a rule no plain scanner enforces: nobody can mark a finding resolved by hand. Only a rescan that no longer finds it can close it.
• A policy engine that produces a verdict. Trivy can fail a CI step above a severity threshold; it has no concept of a declarative, versioned policy that also accounts for lifecycle status, fixability, an advisory’s age or how many findings must match, and it does not record an immutable, replayable verdict for later audit. See policy and verdicts.
• An audit timeline. Every lifecycle transition writes to an append-only record naming the kind of actor responsible — a person, a scan, a scheduled task, or an API key. A cron job running Trivy produces no equivalent record.
• A machine API built for pipelines, with scoped expiring credentials, signed cursors, idempotent bulk operations and signed webhooks — see the machine API — rather than a CLI exit code a script has to interpret.
• Repository and SBOM ingestion alongside container images, so the same lifecycle and policy machinery applies to more than one kind of scan target.

When is running Trivy yourself the right choice?

When you genuinely need only the scan, not the decision record. A single developer running trivy image before a manual push, a one-off audit of a handful of images, or a team that already has its own triage tooling and only wants the raw vulnerability list — none of those need a lifecycle, a policy engine or an audit trail, and Trivy alone is free, fast, and does that one job well. TRUSTIVAN exists for the moment a team notices that the same CVE keeps getting triaged from scratch on every rescan, or that no one can say with confidence which findings were consciously accepted versus quietly ignored.

What does TRUSTIVAN still not do?

The same honest limits stated on the why TRUSTIVAN page apply here too: no infrastructure-as-code scanning (nothing parses a Terraform or Kubernetes manifest for a policy violation, though inventorying what runs in a connected cluster or cloud account is a separate capability that does ship), no reachability analysis, no pull-request scanning, and no attestation of TRUSTIVAN itself — evidence maps to compliance controls, but TRUSTIVAN holds no SOC 2 report or ISO certificate.