> ## Documentation Index > Fetch the complete documentation index at: https://docs.binarly.io/llms.txt > Use this file to discover all available pages before exploring further. # Secrets Detection > How the Binarly Transparency Platform detects hardcoded secrets across firmware, container images, source files, and binary artifacts. The Binarly Transparency Platform detects hardcoded secrets — credentials, tokens, keys, and other sensitive material — across all content within an analyzed image. Detection is architecture-independent: the engine normalizes everything it can extract from an image and scans it for secrets, regardless of the processor architecture the binary targets. Supported inputs include Docker container images, POSIX-based firmware (router firmware, BMC firmware), disk images, and archives. Any format the platform can unpack is eligible for secrets detection. ## 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 | POSIX binaries (ELF executables and shared libraries) are scanned as raw data. The engine does not disassemble or decompile them for secrets detection — it extracts readable strings and applies pattern matching against binary content. Secrets compiled into a binary or embedded as string literals are detected through this method. Some secret types have limited or no coverage in POSIX binaries: secrets that are encoded, split across memory, or reconstructed at runtime are not detected. ## 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. | All secrets are reported regardless of 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`, or `Undetermined` * **CWE classification** — the associated weakness class (hardcoded secrets are classified under CWE-798) ## Related * [Secret finding classes](/resource-center/finding-classes#secret-classes) — Full list of secret finding classes * [Finding Types & Classes](/resource-center/finding-types) — How finding types map to finding classes * [Supported Platforms](/user-guides/about/supported-platforms) — Platform and format coverage * [Stop the Leak: Scanning Containers for Exposed Secrets](https://www.binarly.io/blog/stop-the-leak-scanning-containers-for-exposed-secrets) — Research findings from scanning 80,000+ Docker images across 54 organizations