How do you scan a filesystem or source code repository with Trivy?

Scanning a filesystem with Trivy is like having a building inspector check the blueprints before construction begins. Instead of waiting until the building is finished (the container image is built) to find structural problems, the inspector catches issues while changes are still cheap and easy to make. Trivy's filesystem and repository scanners bring security feedback as far left in the development process as possible.

The trivy fs command scans a local directory for vulnerabilities, misconfigurations, and secrets. When you run trivy fs on the root of your payments-api project, Trivy walks the directory tree looking for dependency manifest files and lock files. It recognizes dozens of package manager formats: package-lock.json and yarn.lock for Node.js, requirements.txt and Pipfile.lock for Python, go.sum for Go, Gemfile.lock for Ruby, pom.xml and build.gradle for Java, Cargo.lock for Rust, and many others. For each dependency it finds, Trivy checks the version against its vulnerability database and reports any known CVEs. The trivy repo command does the same thing but takes a Git repository URL as input, cloning the repository into a temporary directory before scanning.

The key difference between filesystem scanning and image scanning is what gets analyzed. Image scanning examines both OS packages and application dependencies within the built container layers. Filesystem scanning focuses on the application source code and its declared dependencies before any container image is built. This means filesystem scanning is faster, does not require Docker, and can run on a developer's laptop as part of a pre-commit workflow. For user-auth-service, a developer can run trivy fs . in the project directory to catch a vulnerable version of jsonwebtoken before even pushing the code to the repository.

In production workflows, teams use trivy fs at multiple points. Developers run it locally during development as a quick check. The CI pipeline runs it as one of the first steps, before the more time-consuming Docker build and image scan. For a monorepo containing order-processing-service, inventory-sync, and checkout-service, teams can run trivy fs on each subdirectory independently or scan the entire monorepo at once. The trivy repo command is particularly useful for scheduled scanning of third-party dependencies or for security teams that need to audit repositories they do not have checked out locally. A nightly cron job can run trivy repo against all repositories in the organization and aggregate results into a security dashboard.

One gotcha beginners encounter is that trivy fs only detects vulnerabilities in declared dependencies, not in vendored or copied code. If someone copies a vulnerable function from a library directly into their source code instead of importing the package, Trivy will not detect it. Additionally, the accuracy of filesystem scanning depends on having accurate lock files committed to the repository. If the lock file is outdated or missing, Trivy may miss dependencies or report incorrect versions. Teams should enforce that lock files are always committed and kept in sync with the manifest files.