What is analyzed
The engine classifies extracted content into component types and applies the appropriate scanning strategy to each.| Component class | What is scanned |
|---|---|
| Confidential files | Over 100 recognized files that may contain credentials, e.g. .bash_history, .zshrc |
| Source files | C, C++, C header files, Go, HTML, JavaScript, Java, JSON, Julia, Lisp, Lua, Markdown, OCaml, Perl, PHP, Python, R, Ruby, Shell, SQL, XML, YAML |
| Plaintext | Unstructured text content |
| Python and Java bytecode | Compiled bytecode (.pyc, .class files) |
| Docker configs | Container configuration files |
| Docker image shadowed files | Files deleted during the Docker image build process; not present in the final image layer |
| Git repositories | Git repository content (including the commit history) and repository configuration |
| Database files | LMDB |
| Shadow password files | Unix-like /etc/shadow, with password hash cracking support |
| POSIX binaries | Raw byte content — not disassembled or code-analyzed |
Detection method
The detection engine uses 200+ regex-based rules that match on the structure and format of known secret types: API key prefixes, JWT header patterns, webhook URL formats, URL credentials, and similar signatures. Entropy is calculated for each candidate match and reported alongside the finding. Shadow password file entries are parsed and each hashed password is checked against a list of 1,000+ common passwords. Supported hash formats:md5crypt, sha256crypt, and sha512crypt.
What is detected
| Secret type | Examples |
|---|---|
| Credentials | Service passwords, URL credentials |
| API credentials | API keys and tokens |
| OAuth credentials | Client secrets, access tokens |
| Encryption keys | Symmetric keys embedded in firmware or application binaries |
| JWT tokens | Signed authentication tokens |
| Webhook URLs | Slack, Teams, and other service webhook endpoints |
| Generic sensitive data | Generic API keys and tokens of an unknown format |
| Signed URL | Signed URLs with embedded access credentials, e.g. AWS S3 signed URLs |
Validation
Each secret finding carries a validity status populated by a dedicated validation service that calls out to external APIs to confirm whether the credential is still active.| Status | Meaning |
|---|---|
| Valid | The credential was confirmed active against an external service |
| Invalid | The credential was checked and found inactive or revoked |
| Undetermined | The credential could not be checked: the service was unreachable, the secret type is not covered by a validator, or the check returned an inconclusive result |
| Unspecified | The validity status is not specified (for finding types other than Secret). Select this value when filtering by validity to include non-secret findings alongside a specific secret validity status. |
Undetermined does not mean a credential is inactive: it means the check could not be completed.
Validation runs automatically on SaaS. On on-prem deployments, it is disabled by default.
Finding details
Each secrets finding includes:- Location — the file path and component within the analyzed image where the secret was found
- Secret value — the extracted string, shown as decoded text
- Entropy — the entropy of the identified secret value
- Validity — the validation status:
Valid,Invalid, orUndetermined - CWE classification — the associated weakness class (hardcoded secrets are classified under CWE-798)
Related
- Secret finding classes — Full list of secret finding classes
- Finding Types & Classes — How finding types map to finding classes
- Supported Platforms — Platform and format coverage
- Stop the Leak: Scanning Containers for Exposed Secrets — Research findings from scanning 80,000+ Docker images across 54 organizations