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 under the Secrets category tab on the Issues page 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

​

Exposure Snapshot

For hardcoded credential findings, you can view a point-in-time exposure snapshot that captures the credential’s exposure state at the time of detection. The snapshot is available on the finding’s detail page for users with the appropriate permissions. Organization admins, MSP members, and organization-wide (service or MSP) API tokens can view the full snapshot details. Other users who can view the finding see only “An exposure snapshot exists. Org admins can view it.” The snapshot has two sections:

• Readers on the VCS — who could read the repository on the version control provider at the time the secret was detected. For repositories on GitHub or GitLab, this includes the repository’s visibility setting and a roster of users with access, showing each user’s login, display name, permission level (e.g. “maintain” or “Developer”), how access was granted (direct, team, organization role, organization base permission, inherited group, or outside collaborator), and which teams or organization roles provided it. The roster may be complete, partial (when some access sources could not be read, such as organization roles or base permissions), or unavailable (when ZeroPath’s credentials could not read the repository’s access data). For repositories on other providers (Bitbucket, Azure DevOps, Gerrit, or a generic Git remote) and for uploaded repositories, ZeroPath does not record a roster, so this section always shows as unavailable.
• Viewers in ZeroPath — which ZeroPath principals could view the finding at that time. This includes organization members, MSP members, service tokens, and MSP tokens, along with each viewer’s kind and the basis for their access (such as organization admin, team grants scoped to the repository or its tags, or disabled access control). The API response also records each viewer’s role and whether the organization’s secret masking setting was active; the app does not show these.

​

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 click Hide Descriptions under 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.