Secrets Detection

A hardcoded credential in your code is a security problem. A hardcoded credential that still works is an emergency.

Trace's secrets engine distinguishes the two. Where a typical secrets scanner produces a long list of strings that match a regex, Trace surfaces a shorter list of confirmed-live credentials at the top — and supplies enough context for everything else to be triaged at the right priority.

How it works

The secrets engine runs in two stages:

1. Detection. Scans your code and git history for credential patterns using a curated, organization-wide rule set. Catches API keys, OAuth tokens, private keys, database connection strings, and the long tail of provider-specific formats.
2. Verification. For each candidate, Trace evaluates context (is this in a test fixture? a documentation example? a real config file?), and where possible probes the upstream provider with a read-only request to confirm whether the credential is still live.

Detection is the part most scanners get right. Verification is where Trace pulls ahead.

Live-secret verification

For credentials issued by providers with an authentication endpoint, Trace performs a read-only probe to determine whether the credential is still valid. We never write, mutate, or delete with a discovered credential — only call endpoints that exist specifically to test authentication.

Examples of what gets verified:

• AWS access keys — by calling sts:GetCallerIdentity (returns the account/user without making any changes).
• Stripe keys — by hitting a read-only metadata endpoint on the Stripe API.
• GitHub tokens — by calling /user and inspecting the response.
• Slack tokens — by calling auth.test.
• SendGrid API keys — by hitting a status endpoint.
• GitLab tokens, NPM tokens, Twilio, OpenAI, Anthropic, and a growing list of other providers.

If a probe returns success, the finding is flagged as verified live — and you should treat it as an immediate rotation. If the probe fails with auth-specific errors (401, 403), the credential is reported as confirmed inactive. If the network is unreachable or the probe is inconclusive, the finding falls back to context-based confidence.

Detection scope

Trace scans both your current file tree and your git history. A credential that was committed to a public repository two years ago and then "removed" in a follow-up commit is still in the repository's history — and still discoverable by anyone with read access. The first time we scan a new repository, we look at the entire history. From then on, incremental scans look at the new commits, and the daily scheduled scans re-attempt live-secret verification on findings where the original probe was inconclusive.

The detection rule set is centrally managed by Trace — there's nothing to install or maintain in your repository, and we deliberately ignore in-repo bypass mechanisms (inline comments, ignore files) to prevent accidental or malicious silencing of real findings.

Context-based filtering

A surprising amount of "secret" output from a naive scanner is noise — test fixtures with sk_test_1234567890, documentation examples, sample config files, mocked tokens. The verification stage classifies the surrounding context to determine whether a match is likely a real credential or a placeholder.

We err on the side of reporting. If the verifier isn't confident a finding is a placeholder, it stays on your dashboard so you can make the call.

What you get for each finding

Every Secrets vulnerability captures:

• Type — API key, OAuth token, private key, database URL, etc.
• Provider — AWS, GitHub, Stripe, etc., where the rule identifies one.
• File and line — exact location in source.
• Git history context — the commit that introduced the secret, the author, and how long it's been in the repository.
• Verification result — verified live, confirmed inactive, or not verified.
• Severity — CRITICAL for verified-live, calibrated based on provider sensitivity and exposure for the rest.
• CVSS score — for integration with your risk-tracking systems.
• Remediation guidance — what to rotate, where, and the order of operations (rotate first, then commit the fix, then purge if needed).

Rotation, not just removal

For a credential that's been committed to git, removing it from a future commit doesn't make it secret — git history is forever. Trace's remediation guidance always leads with rotation: change the credential at the provider, deploy the new value, then clean up the code. The vulnerability stays open until the credential is rotated; we won't auto-close based on a code change that didn't actually fix the exposure.