> ## 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 in context to reduce false positives — distinguishing real production credentials from test fixtures, example values, and placeholder strings. All detection engines now use the same AI validation pipeline, so findings from every engine receive consistent false-positive filtering.
* **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, the finding is retained with an
error indicator rather than silently dropped, ensuring no secrets are lost due to transient
validation failures.

## Remediation Guidance

Each detected secret includes:

* **Redacted secret preview** — a partially masked version showing enough to identify the credential without exposing the full value.
* **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.