Trivy
dependency CVEs. Part of AuditCore's automated security audit pipeline — runs on every scan in the Enterprise tier and above, with findings normalized into a single severity-rated table.
What is Trivy?
Trivy is the dependency-CVE workhorse for the static phase. It reads your project's lockfiles (`package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`, `Pipfile.lock`, `poetry.lock`, `go.sum`, `Gemfile.lock`, `composer.lock`, `pom.xml`, `Cargo.lock`) and cross-references every package + version against the National Vulnerability Database (NVD), GitHub Advisory Database, and language-specific security advisories.
AuditCore runs Trivy's filesystem scan mode (`trivy fs --scanners vuln`) against the cloned repository. Findings are filtered to severity HIGH and CRITICAL by default — Trivy will happily report 200+ informational vulns on a typical Node project, most of which are dev-only or in unreachable code paths. We chose the noise/signal balance to surface things you should actually patch.
Common patterns Trivy catches that other scanners miss: stale lodash (CVE-2021-23337 prototype pollution), vulnerable axios versions (CVE-2024-XXXX SSRF), Spring Boot pulled in transitively with a Log4j vulnerability, Pillow with image-parsing CVEs in Python ML stacks. The dev-only dependency exclusion catches: webpack plugins flagged for issues that only matter in browser bundles (which the dev plugin isn't part of), test frameworks flagged for issues that don't apply server-side.
What Trivy doesn't do well: zero-day detection (relies on published CVEs — there's a lag between vulnerability discovery and CVE publication), runtime exploitability assessment (a vuln in a dev-only dep with no runtime path is ranked the same as a vuln in your auth handler). For runtime context, you need our dynamic scanners. Trivy is the best dependency-CVE scanner in OSS, but it's still a piece of the puzzle.
What it tests
- Known CVEs in npm/yarn/pnpm dependencies (Node.js)
- Known CVEs in pip/Pipenv/poetry dependencies (Python)
- Known CVEs in go.mod (Go)
- Known CVEs in Gemfile (Ruby)
- Known CVEs in composer.json (PHP)
- Known CVEs in Maven pom.xml + Gradle (Java/Kotlin)
- Known CVEs in Cargo.lock (Rust)
- Known CVEs in NuGet packages.config / .csproj (.NET)
- OS-level vulnerabilities in Dockerfile base images (when Dockerfile present)
- License compliance checks (optional, off by default)
Where it runs in the AuditCore pipeline
Phase 5/5 · Static / Code & Mobile
Source-code, dependency and mobile-binary analysis — Semgrep rules, gitleaks secrets, Trivy CVEs, APK / IPA manifest, permissions, strings, network and native-binary hardening.
Source: scanners/trivy_scanner.py
Sample findings
lodash 4.17.20 — prototype pollution (CVE-2021-23337)
High. `_.template()` and `_.set()` accept `__proto__` keys, allowing prototype pollution that can lead to RCE in some contexts. Mitigation: upgrade to lodash 4.17.21+. If you can't upgrade, audit usage of `_.template()` with user-controlled input (it should never accept untrusted input regardless).
axios 0.21.0 — SSRF via redirect handling (CVE-2020-28168)
Medium. axios <0.21.1 follows redirects without re-validating against allow-lists, enabling SSRF if your app makes server-side HTTP calls to user-supplied URLs. Mitigation: upgrade to axios 0.21.1+. If your app makes outbound HTTP, also implement SSRF defenses (see /fix/ssrf).
Pillow 9.0.0 — buffer overflow in image parsing (CVE-2022-22817)
Critical. PIL.Image.open() can be exploited via a crafted image file. If your app accepts image uploads (avatars, attachments, OCR), an attacker can crash the worker or potentially achieve RCE. Mitigation: upgrade to Pillow 9.0.1+. Also: process uploads in a sandboxed worker, never in your web handler.
Log4j 2.14.1 transitively pulled by spring-boot-starter-web
Critical. Log4Shell (CVE-2021-44228) — RCE via crafted log message. Even if your app doesn't directly include log4j, Spring transitively does. Mitigation: upgrade Spring Boot to 2.6.2+ which uses log4j-core 2.17.1+.
Other static / code & mobile scanners
FAQ
Why does Trivy report so many vulnerabilities on a fresh project?
Modern dependency trees pull in 1000+ transitive packages. Even with active maintenance, some have unpatched CVEs — usually low-severity or in dev-only paths. AuditCore filters to HIGH and CRITICAL by default. To see all findings, run `trivy fs --severity LOW,MEDIUM,HIGH,CRITICAL` locally.
Trivy flagged a CVE in a dev dependency. Do I need to fix it?
Often no — dev dependencies (test runners, linters, build tools) don't ship to production. But check: some 'dev' deps actually run during build (webpack plugins with file-system access, postinstall scripts) and those can be exploited if you build untrusted code. AuditCore reports raw Trivy output; categorization is your call.
How fresh is Trivy's vulnerability database?
We pull the latest DB on every scan via `trivy --download-db-only`. The database is updated by Aqua Security multiple times per day with new CVE data. New CVEs typically appear in Trivy within 24-48 hours of NVD publication.
Does Trivy detect supply-chain attacks (typosquatted packages)?
Partially. If a typosquatted package has been reported and published in the NVD or GitHub Advisory database, Trivy will detect it. For unreported supply-chain attacks (unpublished malware), use specialized tools like Socket.dev or Phylum. AuditCore is on the roadmap to add a supply-chain check via Socket integration.
Can Trivy scan Docker images instead of source?
Yes (`trivy image …`), but AuditCore's flow is source-first since most customers integrate via repo URL. Container scanning is on the roadmap for the Enterprise tier where customers might want to audit pre-built images from their registry.