How does Trivy detect secrets and sensitive data in repositories?

Think of Trivy's secret detection like a bank's fraud detection system monitoring transactions. The system maintains a catalog of known suspicious patterns, such as transactions from blacklisted regions, unusual amounts, or specific sequences of digits that match stolen card numbers. When a transaction matches one of these patterns, it is flagged for review. Similarly, Trivy maintains a library of regular expression patterns that match the structure of known secret types, and it scans every file in the target looking for matches.

Trivy's secret scanner is one of its built-in scanners alongside vulnerability detection and misconfiguration checking. When invoked with --scanners secret or as part of a comprehensive scan, Trivy examines every file in the target artifact, whether that is a container image, a filesystem directory, or a git repository. The scanner applies a curated library of over 100 regular expression rules that match the known formats of secrets from major providers. For example, AWS access keys always start with AKIA followed by 16 alphanumeric characters, GitHub personal access tokens begin with ghp_ followed by 36 characters, and Slack webhook URLs follow a specific URL pattern. Beyond pattern matching, Trivy uses entropy analysis to detect high-entropy strings that may be randomly generated secrets even if they do not match a known provider pattern.

The scanning process works at the file content level. For container images, Trivy extracts every layer and examines the contents of every file, including configuration files, environment scripts, application code, and embedded resources. This means secrets that were added in an early Dockerfile layer and deleted in a later layer are still detected because Docker layers are additive and the file content persists in the lower layer. For filesystem scanning with trivy fs, Trivy walks the directory tree and reads each file, applying the pattern rules against the content. For git repository scanning with trivy repo, it can clone a remote repository and scan the current state. The scanner respects a built-in allowlist of file paths and patterns to reduce false positives, such as test fixtures, documentation examples, and known placeholder values. Teams can extend this allowlist using the --secret-config flag to provide a custom configuration file that defines additional rules or suppresses specific patterns.

In production workflows for services like the payments-api and user-auth-service, secret scanning is typically integrated at two points. First, it runs as a pre-commit or CI step against the source code repository to catch secrets before they are committed to version control. Running trivy fs --scanners secret against the repository root as part of a pull request check prevents developers from accidentally committing API keys or database passwords. Second, it runs as part of the container image scan in the CI pipeline to catch secrets that might be baked into the image during the build process, such as credentials embedded in configuration files or environment variables hardcoded in Dockerfiles. The inventory-sync team, for instance, discovered that their build process was copying a .env file containing production database credentials into the image because it was not excluded in .dockerignore. Trivy caught this during the image scan and blocked the pipeline, preventing the credentials from reaching the container registry.

A critical gotcha is the false positive rate in secret scanning. High-entropy strings in test fixtures, documentation, and example configuration files frequently trigger matches. A test file containing example_api_key=AKIA1234567890ABCDEF will match the AWS access key pattern even though it is not a real secret. Without proper tuning, the noise from false positives causes teams to ignore or disable the scanner entirely, defeating its purpose. Use the --secret-config flag to add allowlists for specific file paths like test/ and docs/ directories, and for specific patterns that your codebase legitimately uses. Another common issue is performance. Secret scanning reads the full content of every file, which can be slow for large repositories or images with many files. Use the --skip-dirs flag to exclude known safe directories like vendor/ or node_modules/ that contain third-party code unlikely to contain your organization's secrets. Finally, remember that Trivy's secret scanner checks the current file state, not git history. A secret that was committed and then removed in a subsequent commit will not be detected by trivy fs, though it will be detected in the container image if both layers are present.