trivy fs: Scan a Filesystem or Repo
trivy fs scans a local filesystem path for vulnerable dependencies, exposed secrets, and misconfigurations.
When you want to scan source before it becomes an image, trivy fs reads lockfiles and config in place. It is the natural fit for a pull-request gate on the checked-out repository.
What it does
trivy fs walks a directory, detects dependency lockfiles (package-lock.json, go.sum, requirements.txt, Cargo.lock, and more), and reports vulnerabilities against the Trivy database. With the right scanners it also flags hardcoded secrets and IaC misconfigurations.
Common usage
trivy fs .
trivy fs --scanners vuln,secret --severity HIGH,CRITICAL .
# scan only a lockfile directory and emit SARIF for code scanning
trivy fs --format sarif --output trivy.sarif .Options
| Flag | What it does |
|---|---|
| --scanners <list> | vuln, secret, misconfig, license |
| --severity <list> | Severities to report |
| --format sarif | Emit SARIF for GitHub code scanning |
| --output <file> | Write the report to a file |
| --skip-dirs <dir> | Exclude paths such as node_modules or vendor |
| --exit-code <n> | Exit code to use when findings match |
In CI
On a pull request, scan the checkout with --scanners vuln,secret and gate with --exit-code 1 --severity HIGH,CRITICAL. Use --format sarif --output trivy.sarif and upload it to GitHub code scanning so findings annotate the diff.
Common errors in CI
"no supported file was detected" means trivy found no lockfiles in the path; point it at the directory that contains them and avoid over-broad --skip-dirs. Database download failures match the trivy image case: cache the DB or authenticate to avoid TOOMANYREQUESTS. A surprising clean result often means lockfiles are gitignored and not present in the checkout.