Secrets Scanning

​

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:

​

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.

​

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

​

Configuration

Secrets scanning is controlled through scanner settings with org/tag/repo-level inheritance: 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 enable Always Redact Secrets under Settings → General → Secret Masking. When enabled, 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.