> ## Documentation Index
> Fetch the complete documentation index at: https://zeropath.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Secrets Scanning

> Detect hardcoded secrets, API keys, and credentials across your codebase

## How It Works

ZeroPath's secrets scanner identifies hardcoded credentials, API keys, tokens, and other sensitive material across your codebase. It runs as part of both full repository scans and PR scans, catching secrets before they reach production.

* **Automated detection** runs alongside every SAST scan and PR scan. When secrets scanning is enabled, every code change is checked for accidentally committed credentials.
* **AI-powered validation** reviews each detected secret using a repository-reading AI agent that can examine the full file and related configuration — not just the lines immediately surrounding the detection. This deeper context lets the validator distinguish real production credentials from encrypted values, test fixtures, example values, and placeholder strings, even when the deciding evidence (such as an encryption header, a provider declaration, or a metadata block) is far from the flagged line. All detection engines use the same validation pipeline, so findings from every engine receive consistent false-positive filtering. The validator recognizes common non-secret high-entropy patterns — such as Subresource Integrity (SRI) hashes, content/asset fingerprints, base64-encoded images and fonts, public keys, and cache-busting tokens — and filters them automatically, even when they appear in source or build directories. When a repository contains a very large number of secret detections, ZeroPath prioritizes verified (confirmed active) findings for validation first, ensuring the most critical credentials are always fully evaluated. Findings that exceed the validation budget are not dropped — they are preserved in the database and withheld from the active findings queue until a subsequent scan can validate them, so no finding is silently lost or mistakenly resolved as fixed.
* **Multi-engine detection** — ZeroPath uses multiple detection engines in parallel to maximize coverage. Findings are automatically deduplicated across engines so you see each secret only once, regardless of how many engines flagged it.
* **Verification status** — detected secrets are classified as **verified** (confirmed active), **unknown** (could not confirm status), or **false positive** (test/placeholder). Only verified and unknown findings are surfaced by default.

## Detected Secret Types

ZeroPath detects a wide range of secret types across all major cloud providers and services. Some of which are:

<Tabs>
  <Tab title="Cloud & Infrastructure">
    * AWS access keys and secret keys
    * Google Cloud service account keys
    * Azure credentials and connection strings
    * DigitalOcean tokens
    * Heroku API keys
  </Tab>

  <Tab title="APIs & SaaS">
    * Stripe API keys (publishable and secret)
    * Twilio account SIDs and auth tokens
    * SendGrid API keys
    * Slack tokens (bot, user, webhook)
    * GitHub personal access tokens and OAuth tokens
    * GitLab tokens
    * Bitbucket app passwords
  </Tab>

  <Tab title="Databases & Auth">
    * Database connection strings (PostgreSQL, MySQL, MongoDB, Redis)
    * Firebase and Supabase credentials
    * JWT signing secrets
    * OAuth client secrets
    * SSH and TLS/SSL private keys
    * SAML private keys
  </Tab>

  <Tab title="Generic Patterns">
    * High-entropy strings in configuration files
    * Base64-encoded credentials
    * Password assignments in code
  </Tab>
</Tabs>

## Scan Modes

### Full Repository Scan

During a full scan, ZeroPath scans every file in your repository for secrets. Results appear in the Secrets tab of your dashboard alongside other findings.

### PR Scan

During PR scanning, only files changed in the pull request are checked for secrets. Any newly introduced secrets appear as inline comments on the PR and count toward the check status.

### Verification

Detected secrets undergo a verification step where ZeroPath attempts to determine whether the credential is currently active. This produces three statuses:

* **Verified** — the secret was confirmed to be active
* **Unknown** — the verification could not determine status (treated as potentially live)
* **False positive** — determined to be a test value, example, or placeholder

When AI validation encounters an error for a specific finding or a batch of findings, the affected
findings are left without a verdict and withheld from the active findings queue rather than being
shown as confirmed. This prevents findings that no agent actually assessed from appearing as
validated true positives. The findings remain in the database and will be re-evaluated on the next
scan.

## Partial Scan Warning

To keep secrets scanning within its time budget, ZeroPath automatically skips files that exceed
a size threshold (5 MB by default) before the scan runs. Entropy-based detection on very large
files — such as committed build artifacts, database dumps, or image exports — accounts for most
timeout overruns, while the source files where real credentials live are nearly always well under
this limit. Skipped files are always reported in the scan log; nothing is silently excluded.

If secrets scanning still does not finish within its time budget after large files have been
excluded, ZeroPath surfaces a warning on the scan result to make the incompleteness visible.
The warning reads:

> Secrets scanning did not finish this scan, so this result is partial: it is not a confirmation
> that the repository is free of secrets. This usually means the repository contains very large
> files that exceed the scanner's time budget; the next scan will re-check.

When a timeout is detected, the scan is marked as incomplete rather than returning zero findings.
This prevents a scan that ran out of time from being mistaken for a repository that is free of
secrets.

A partial secrets scan result does **not** mean existing findings are dismissed or auto-resolved —
findings already recorded are kept. The next scheduled scan will re-check the repository and
attempt to complete coverage.

## Remediation Guidance

Each detected secret includes:

* **Redacted secret preview** — a masked version showing only enough to identify the credential (such as the last four characters, or the algorithm label for key material) without exposing the full value. Secret values are masked on every surface — including the dashboard, the API, webhook payloads, notifications, exports, and integration tickets — for all callers.
* **Redacted finding title** — for secret findings, the vulnerability title is automatically replaced with a deterministic, location-based title that does not contain the secret value. This applies everywhere the title appears, including webhook payloads (such as `VULNERABILITY_PATCHED` and `PATCH_PR_DENIED` events), notification messages, and API responses.
* **Redacted false-positive reasoning** — when a secret finding is marked as a false positive, the reasoning text is not stored. Because the validation agent's reasoning can quote the credential it was asked to judge, this prevents the secret value from being persisted in or served through the false-positive reasoning field.
* **Rotation guide** — platform-specific instructions for rotating the compromised credential (e.g., how to regenerate an AWS access key, revoke a GitHub token, or rotate a Stripe API key).
* **Detector information** — the type of secret detected and how it was identified.
* **File location** — the exact file and line where the secret was found.

### Recommended Response

<Warning>
  Even if a secret was only briefly committed, treat it as compromised. Git history preserves all
  committed data.
</Warning>

<Steps>
  <Step title="Rotate the Credential">
    Generate a new secret/key in the affected service and revoke the old one.
  </Step>

  <Step title="Remove from Code">
    Move the secret to environment variables, a secrets manager (AWS Secrets Manager, HashiCorp
    Vault, etc.), or your CI/CD system's secret storage.
  </Step>

  <Step title="Audit Access Logs">
    Check the associated service for unauthorized access during the exposure window.
  </Step>

  <Step title="Prevent Future Leaks">
    Add configuration files containing secrets to `.gitignore` to prevent accidental commits.
  </Step>
</Steps>

## Configuration

Secrets scanning is controlled through scanner settings with org/tag/repo-level inheritance:

| Setting                                  | Default | What It Controls                                  |
| ---------------------------------------- | ------- | ------------------------------------------------- |
| **Secrets scanning enabled (full scan)** | On      | Run secrets scanning during full repository scans |
| **Secrets scanning enabled (PR scan)**   | On      | Run secrets scanning during pull request scans    |

Secrets scanning runs as part of the broader scanning pipeline and shares the same scheduling, notification, and integration configurations as SAST findings.

### Organization-Level Secret Masking

Organization admins can click **Hide Descriptions** under [**Settings → General → Secret Masking**](https://zeropath.com/app/settings/general#secret-masking), in the **Repositories & data** section. When descriptions are hidden, the AI-generated description and exploit walkthrough for secret findings are redacted on every surface — including the dashboard, API responses, webhook payloads, notifications, and exported tickets — so that prose that might quote the secret value is never shown. The code snippet and finding title are always masked regardless of this setting; the organization toggle controls only the narrative fields (description and exploit walkthrough).

This setting is useful for organizations that want to ensure secret values cannot be inferred from finding descriptions, even by authenticated dashboard users. Developers who need the actual value can open the file in the repository via the permalink on the finding.