NewStart your first free run
secret detection

The key somebody pasted in two years ago still works.

Credentials in your code and in what your app sends to the browser, found in what you ship today and in every version behind it, then checked for whether they still open anything.

criticalHardcoded AWS key
infra/terraform/outputs.tf
12output "deploy_credentials" {
13 value = {
14 access_key_id = "AKIA••••••••XYZ"
15 secret_access_key = "••••••••••••••••"
16 }
17}
Can write to production S3
In the git history for 14 months
01 / What it finds

In the code, and in what the browser receives.

What reaches the list, where a key leaks outside the repository, and what arrives when one is found.

Signal

A list short enough to work through.

Identifiers and hashes look random too, which is why scanners that score strings on randomness bury the real one. Judging a string by how it is built leaves the report with the credential and not much else.

  • Placeholders and fixtures judged by what surrounds them
  • Cloud keys, database URLs, private keys, tokens and CI credentials
Findings
5 open · secretsFindings.
Filter findings…WeaknessSecrets
criticalCloud access key exposed in Terraform outputinteropt/billing-api
criticalPrivate signing key committed to repositoryinteropt/auth-service
criticalDatabase URL exposed in deployment logsinteropt/infra
highCI token in workflow fileinteropt/web-dashboard
mediumWebhook signing secret in example configinteropt/notify-service
5 real secrets out of 1,284 random-looking stringsIDs, hashes and test values filtered out
In the browser

The key your frontend hands to every visitor.

A key bundled into your JavaScript is public the moment the page loads: anyone can open the browser's developer tools and read it. The run checks what your live application actually serves, not only the repository behind it.

  • Found in the running app, not just the code
  • Keys that belong on a server, flagged when the browser gets them
Web app pentest
app.acme.io/checkout
Sent to every visitor with the page
assets/checkout-3f9a2c.js
1const pay = async (cart) => {
2 const stripe = Stripe("sk_live_••••••••4Qe");
3 return stripe.charges.create(cart);
4};
criticalStripe secret key in the JavaScript bundleAnyone who opens app.acme.io can read it
The finding

What arrives when one is found.

The file and the line, with the code around it, so it is confirmed at a glance. What it reaches, because a read-only test key and a production write key are not the same finding. And how far back it goes, which decides whether rotating is enough.

  • The value itself is masked, never stored
  • Assign it, link a ticket, and track it to closed
Triage and status
criticalF-C1A6EAPrivate signing key committed to repository
Settings
FindingSuggested fixAIActivity3Notes
Risk

Anyone with the repository can sign tokens the service accepts, so they can mint a session for any user. The key stays compromised after it is removed from the current tree.

src/server/jwt.ts: 12 - 16
12const JWT_PRIVATE_KEY = `
13-----BEGIN PRIVATE KEY-----
14MIIEvQIBADANBgkqhkiG9w0BAQEFAASC••••••
15-----END PRIVATE KEY-----
16`;
Historya41c9eremoved from src/server/jwt.tstoday7d02b3refactor session signing4 mo19fe0cadd JWT_PRIVATE_KEY for local dev14 moNL Assigned to Noah Lin · rotate, then purge

Deleting the line does not remove the secret.

Today's code

Keys written into source, config and environment files — including the local fallback that quietly became the production value.

Every version behind it

The whole history. A secret removed last year is still in the commit before it, and in every clone anyone took.

Where it is not obvious

Values hidden behind a layer of encoding, and credentials sitting inside committed archives and build artefacts.

Cloud keysDatabase URLsPrivate keysAccess tokensWebhook secretsCI credentials
03 / Questions

Questions about secret detection.

start here

Find out what is already in your history.

Connect a repository and the first run reads every version behind what you ship today.