Secret Pattern Sample Checker

Introduction:

Secret pattern review looks for credential-shaped text before a config sample, log excerpt, support ticket, or code snippet is shared. API keys, private keys, bearer tokens, credentialed database URLs, and password-like assignments can appear in ordinary operational notes, especially when people copy a whole environment file or request header instead of trimming it first.

The main decision is not whether a string looks unusual. The useful question is whether the sample contains something that could authenticate to a service, sign a request, unlock a private resource, or reveal enough context for an attacker to try the value elsewhere. A single private key block or cloud access key ID deserves faster treatment than a weak placeholder, but both can distract reviewers if the result does not say why the value was flagged.

Pattern checks are useful because many secret types have recognizable shapes: an AWS key ID prefix, a GitHub token prefix, a PEM private-key boundary, or an authorization header with a long opaque value. Context checks matter too. A line such as client_secret=... may not match one provider's exact token format, yet the variable name and value shape can still justify a manual review.

A finding is a triage signal, not final proof that the credential is live. Placeholders, fixtures, and secret-manager references can look suspicious. Real exposed material should still be treated with care until the owning service confirms revocation, rotation, or invalidation.

Technical Details:

Secret detection usually combines exact token patterns with contextual heuristics. Exact patterns look for known visible structures, such as provider prefixes, HTTP authorization headers, credentialed connection strings, and private-key delimiters. Contextual heuristics look at nearby assignment names, value length, character variety, and entropy when the value does not belong to a known provider shape.

The scanner runs those two paths separately. Direct rules produce high-confidence rows for supported shapes. Generic assignment review is narrower: the key name must look sensitive, the value must score high enough for the selected profile, and the value must not overlap a direct-pattern match. This prevents the same visible credential from being counted again as a generic assignment.

Rule Core:

Generic assignment scoring uses Shannon entropy as one input. Entropy estimates how unpredictable the characters are per character position. It does not prove randomness, but it helps separate values such as abc123 from longer mixed strings that look closer to generated credentials.

Here, H is entropy in bits per character and p is the frequency share of each character in the value. Generic assignment scoring starts with a base score, adds points for length, entropy, and mixed character classes, adds weight for sensitive key names, then subtracts points for sample or placeholder wording.

The output severity order is Critical, High, Medium, Low, and Info. Direct rules set severity from the rule itself. Generic assignment severity follows confidence: High confidence becomes High severity, Medium confidence becomes Medium, and Low confidence becomes Low. Sample wording such as demo, test, placeholder, or your_token does not hide the row; it adds a caution to verify before treating the value as live.

The scan is deterministic for the same text and settings. It does not call secret providers, validate token status, inspect repository history, decode JWT claims, or prove whether a credential has already been used. Those checks belong in the owning platform, audit log, secret scanner, or incident workflow after the pattern review points to likely exposure.

Everyday Use & Decision Guide:

Start with Balanced review, leave Mask values on, and paste the smallest useful excerpt into Sample text. A complete deployment note can be helpful during an incident, but a smaller sample makes line numbers, contexts, and follow-up actions easier to check.

Use Source label to name the file, ticket, or snippet before you scan. That label appears in the summary and structured output, which keeps a later review from mixing a staging environment file with a production log or a redacted support case.

• Choose Strict high-confidence patterns when release review should focus on provider-shaped tokens, private keys, credentialed URLs, and strong generic assignments.
• Choose Broad triage when you are inventorying older config samples and can tolerate weaker rows that need human cleanup.
• Keep Generic assignments on for environment and config samples. Turn it off when you want only direct token formats and private-key blocks.
• Raise Entropy threshold when obvious placeholders are crowding the Finding Ledger. Lower it when short but sensitive migration values are being missed.
• Increase Finding row limit for CSV handoff. Keep it compact for screenshots and ticket summaries.

Read Triage Brief first. It shows the total finding count, critical and high count, scan profile, masking state, provider-validation caution, and immediate action. Move to Finding Ledger for line-by-line evidence and the recommended next step. Pattern Coverage is the audit view: it lists every supported pattern family, even when the current sample has no hits for that family.

The Clean sample button is useful for understanding false positives. With generic assignments enabled, values such as secret-manager or vault references may still appear because their names contain SECRET or TOKEN and their values look structured. That does not mean the reference is unsafe. It means the reviewer should confirm that the sample contains a reference path rather than the actual secret.

A good handoff has masked values, clear line numbers, one source label, and a short action for each real exposure. If any Critical or High row comes from real material, rotate or revoke before sharing the sample further, then replace the literal value with a secret-manager reference or a deliberately fake placeholder.

Step-by-Step Guide:

Review one sample at a time so the line numbers, counts, chart, and JSON describe the same source.

1. Enter Source label with a file name, ticket ID, or short sample name. The default label is sample.env.
2. Choose Scan profile. Use Balanced review for a first pass unless you already know you need strict release review or broad migration triage.
3. Paste into Sample text, drop a text-like file onto the text area, or use Browse file. Files larger than 1 MiB are rejected, and very large pasted samples show an input review error asking you to trim the excerpt.
4. Keep Mask values on for normal review. Turn it off only inside a controlled evidence workflow where exact values are required.
5. Open Advanced when generic assignment noise needs tuning. Adjust Entropy threshold, Finding row limit, and Generic assignments before relying on the row set.
6. Check the summary. No findings means no supported pattern matched under the current settings. It does not replace commit scanning, provider validation, or log review.
7. Open Finding Ledger and review the highest severity rows first. The Evidence column explains the pattern, while Next action names the likely follow-up.
8. Use Pattern Coverage when someone asks which rules were considered. Use Secret Exposure Mix Chart to see whether the sample is dominated by Critical, High, Medium, Low, or Info rows.
9. Copy or download the result only after masking and source labeling are correct. If the input error says the sample is empty, paste text or load a file before treating any output as meaningful.

Interpreting Results:

Start with Critical and High rows, not the total count. One private-key block matters more than a dozen low-confidence generic assignments. The summary line shows how many critical or high findings exist and how many pattern families are involved, which is the fastest way to decide whether the sample needs immediate containment.

• Private key block, cloud access keys, provider tokens, Slack webhooks, and credentialed URLs should be treated as exposed when they came from real systems.
• HTTP Bearer token and JWT-like token rows flag token-shaped material. Verify expiry, scope, and issuer elsewhere before deciding that no action is needed.
• Generic secret assignment rows are context cues. Confirm the key name, value shape, sample wording, and whether the value is an actual secret or a reference path.
• Sample cue badges lower confidence in live exposure, but they do not make the row harmless. A real credential can still contain words such as demo or appear in a test ticket.
• No findings only describes the supported local rules and current settings. It does not prove that the sample is safe to publish.

Use the Next action column as a starting point, then verify with the owning service. For real critical and high findings, the corrective path is usually revoke or rotate, inspect recent use, remove the literal value from shared text, and replace it with a secret reference or masked evidence.

Worked Examples:

A mixed environment leak sample

The built-in leak sample includes a credentialed PostgreSQL URL, an AWS access key ID, a GitHub token, a Bearer header, a JWT-like value, a client_secret assignment, and a private-key block. With Balanced review, default entropy, and Mask values on, the summary reports 7 findings, including 5 critical/high findings. Finding Ledger puts the private-key block first, then the high-severity provider and credential rows. That result should be handled as exposed material if it came from a real ticket or file.

A reference file that still raises review rows

The built-in clean reference sample uses values such as aws-secretsmanager:/orders/staging/db and vault://kv/orders/api. With generic assignments enabled, the scanner can report 2 findings, both Medium generic assignment rows, because the names contain SECRET and TOKEN. Turning Generic assignments off leaves No findings for the same sample. The right interpretation is not automatic rotation; it is a check that the text contains references rather than literal credentials.

A broad sweep that catches a weak token

A short sample with API_TOKEN=abc123 and CLIENT_SECRET=sample-client-secret-9f8e7d6c5b4a3 behaves differently by profile. Strict high-confidence patterns keeps only the stronger CLIENT_SECRET row at Medium severity. Broad triage with a lower entropy threshold can also surface the weak API_TOKEN value as Low severity. That is useful during migration cleanup, but the lower row should be reviewed as a clue, not treated as confirmed compromise.

Responsible Use Note:

Use this checker to reduce accidental exposure in samples and review notes. Avoid pasting production secrets unless the review is authorized and the exact evidence is necessary. The scan itself runs in the browser and does not perform a dedicated server-side checking step, but copied output, screenshots, downloaded files, shared links, and pasted tickets can still expose values if masking is turned off.

FAQ:

Glossary:

Secret pattern

A visible text shape commonly associated with credentials, such as a provider token prefix, authorization header, or private-key boundary.

Generic assignment

A key-value line whose name and value look sensitive even though the value does not match a known provider token shape.

Entropy threshold

The bits-per-character cutoff used when scoring generic assignment values for generated-looking character mix.

Sample cue

Wording such as demo, sample, fake, test, or placeholder that warns the reviewer to confirm whether a finding is live.

Credentialed URL

A connection string that includes username and password material before the host name.

Rotation

Replacing a credential with a new value and retiring the exposed value in the owning service.

References:

• Supported secret scanning patterns, GitHub Docs.
• Secrets Management Cheat Sheet, OWASP Cheat Sheet Series.
• Secure access keys, AWS Identity and Access Management User Guide.