trivy repo scan choked on a git repo with 2GB of vendored dependencies - the agent couldn't exclude the vendor directory

Trivy repo scan choked on 2GB of vendored dependencies

TL;DR

Exclude the vendored directories with --skip-dirs vendor (repeat for each vendored path) and persist the exclusions in a .trivyignore file at the repo root. Trivy walks every file in the repo by default, so 2GB of vendored code gets fully analyzed. Excluding vendor drops the scan to minutes with no real loss in signal, because vendored packages are still covered when you scan the lockfile directly.

The failure

trivy repo scan stalled for 30+ minutes and kept growing in memory
(repo contains 2GB of vendored dependencies, no exclusions configured)

Steps

1. Re-run the scan with the vendored directories skipped: trivy repo --skip-dirs vendor --skip-dirs third_party [REPO_PATH], adding one flag per vendored tree. Expected: the scan completes in minutes and the output notes the skipped directories.
2. Persist the exclusions so the agent picks them up automatically: add the vendored paths to a .trivyignore file at the repo root. Expected: subsequent scans without the flags behave the same as step 1.
3. Keep vendored packages covered by scanning the lockfile directly: run trivy fs --scanners vuln [LOCKFILE_PATH]. Expected: CVEs in the vendored versions still get reported, because the lockfile pins the exact versions.
4. Verify the fix stuck: compare the finding count of the repo scan plus the lockfile scan against a full un-skipped scan on a small sample. Expected: no CVEs lost from the exclusion.

Use this when

• trivy repo stalls, OOMs, or takes absurdly long on a repo with vendored deps
• the repo vendors node_modules, Go vendor dirs, or third-party source trees
• the agent cannot finish a repo scan inside a CI step timeout
• scan cost scales with vendored code size rather than your own code size

Not for this skill when

• the scan fails fast with an error (that is a config or auth problem, not scan weight)
• the repo has no vendored directories (look at large generated files or git history instead)
• you specifically need file-level findings inside vendored code (then scan it, but shard it separately)
• trivy image or trivy fs scans are the slow ones (different flags apply)

Variant phrasings

• trivy scan hangs on repo with large vendor directory
• trivy repo scan out of memory vendored dependencies
• how to exclude vendor folder from trivy scan

Why it happens

trivy repo clones and walks the entire repository, analyzing every language artifact it finds. Vendored dependency trees are often 10 to 100 times larger than the project's own code, so the scan spends nearly all its time and memory on third-party code you did not write. The vendored versions are already pinned in your lockfile, so scanning the lockfile gives you the same vulnerability signal at a fraction of the cost. Exclusion is not losing coverage, it is moving coverage to the cheaper input.

Edge cases

• Vendored code that is NOT in the lockfile (hand-copied sources) loses coverage when excluded. Audit that gap once and either lockfile it or scan it separately on a schedule.
• --skip-dirs matches directory names, so a common name like vendor could also skip a first-party directory that happens to share the name. Check the skipped list in the output.
• .trivyignore also supports file patterns. Use it for giant generated files (bundled assets, test fixtures) that are not real dependencies.
• If the vendor tree is committed but rarely changes, scan it once per vendored-bump instead of every repo scan.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_jog9goXhIzlS3ISwFRpvIg