Secrets Detection

The Secret Scanner reads every indexed file and the repository's own file tree, looking for credentials that were committed by accident — provider keys, connection strings, private key blocks, and files that should never have been checked in at all.

How it works

Detection is pattern-based. Mapnostics carries more than fifty provider-specific patterns rather than one generic “looks like a key” rule, because a pattern that knows what a Stripe live key looks like can be confident where a generic one can only guess. Coverage spans:

• Cloud and infrastructure — AWS, GCP service account JSON, Azure storage, DigitalOcean, Vercel, PlanetScale, Doppler.
• AI providers — OpenAI, Anthropic, Groq, xAI, Perplexity, Replicate, HuggingFace.
• Payments and comms — Stripe live, restricted and webhook keys, Twilio, SendGrid, Resend, Mailgun, Mailchimp, Slack, Discord, Telegram.
• Source control and project tools — GitHub PATs and fine-grained tokens, npm, Shopify, Linear, Notion, Sentry.
• Structural patterns — database and Redis connection strings with embedded credentials, URLs with credentials, private key blocks, JWT secrets, and high-entropy values behind a secret-sounding name.

The file-tree pass

Before reading any content, the scanner walks the repository tree for files whose extension should never be committed — key files, keystores, credential dumps. Those are reported as Sensitive File Exposed in Repository at critical severity, whatever is inside them.

Suppressing the obvious fakes

Documented example keys are allowlisted, and any matched value containing a placeholder marker — EXAMPLE, CHANGE_ME, YOUR_API_KEY, DUMMY — is dropped. Real keys are random; those words inside a matched value are a strong signal it is not one.

The tab

Severity levels

Findings carry one of three severities, set by the pattern that matched rather than by anything about your repository.

Critical

Credentials that can compromise production on their own: cloud provider keys, live payment keys, service-role database keys, private key blocks, and committed sensitive files. Rotate immediately.

High

Keys that expose a sensitive system if the file is reachable: most provider API keys, connection strings, webhook URLs. Move them before the next deployment.

Medium

Likely development credentials — a hardcoded password in a fixture, a config value that should be an environment variable. Low risk in a private repository, still worth cleaning up.

Inside a finding

The value is masked by default; the eye toggle reveals the surrounding code context rather than the secret itself. Expanding a finding gives you three things:

• Code context — the line as it appears in the file, so you can judge whether the match is real.
• Why this matters — what an attacker could do with a credential at this severity.
• Recommended fix — the ordered steps for that severity, starting with rotation.

The file path links straight to the line on GitHub. Once you have rotated a credential, Mark as rotated resolves the finding, and the Scan History tab keeps every past scan so you can see whether the count is going down.

How to respond

• 1. Rotate the credential. Do this first, before touching the code.
• 2. Check the provider’s logs for use during the exposure window.
• 3. Replace the literal with an environment variable or a secrets manager reference.
• 4. Purge it from git history, then confirm with a fresh scan.
• 5. Mark the finding as rotated so the count reflects the work.