Skip to main content

​
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.
  • 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:
  • AWS access keys and secret keys
  • Google Cloud service account keys
  • Azure credentials and connection strings
  • DigitalOcean tokens
  • Heroku API keys

​
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

​
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.
Even if a secret was only briefly committed, treat it as compromised. Git history preserves all committed data.
1

Rotate the Credential

Generate a new secret/key in the affected service and revoke the old one.
2

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.
3

Audit Access Logs

Check the associated service for unauthorized access during the exposure window.
4

Prevent Future Leaks

Add configuration files containing secrets to .gitignore to prevent accidental commits.

​
Configuration

Secrets scanning is controlled through scanner settings with org/tag/repo-level inheritance:
SettingDefaultWhat It Controls
Secrets scanning enabled (full scan)OnRun secrets scanning during full repository scans
Secrets scanning enabled (PR scan)OnRun 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.