@broberg/secret-scan 0.15.0 → 0.16.1

package/dist/cli.js

@@ -0,0 +1,688 @@
+#!/usr/bin/env node
+// src/index.ts
+var PATTERNS = [
+  {
+    label: "private-key",
+    description: "PEM private key block (RSA/EC/OPENSSH/DSA/PGP)",
+    regex: /-----BEGIN (?:RSA |EC |OPENSSH |DSA |PGP )?PRIVATE KEY-----[\s\S]*?-----END (?:RSA |EC |OPENSSH |DSA |PGP )?PRIVATE KEY-----/g
+  },
+  {
+    label: "anthropic-api-key",
+    description: "Anthropic API key (sk-ant-\u2026)",
+    regex: /sk-ant-(?:api03-)?[A-Za-z0-9_-]{20,}/g
+  },
+  {
+    // OpenRouter — distinct from OpenAI; runs BEFORE the generic sk- (which would
+    // otherwise also match + mislabel it).
+    label: "openrouter-api-key",
+    description: "OpenRouter API key (sk-or-v1- + 64 hex)",
+    regex: /\bsk-or-v1-[0-9a-f]{64}/g
+  },
+  {
+    // DeepSeek — shares the sk- prefix with OpenAI, so it MUST run before the
+    // generic openai pattern (specific-before-generic = correct attribution).
+    // DeepSeek's documented shape is sk- + 32 lowercase hex (GitGuardian confirms
+    // an sk- prefix but hides the exact regex); the hex-only body + {32,} length
+    // distinguishes it from OpenAI's mixed-case base62 keys, so a real OpenAI key
+    // is never mislabelled. The field-anchored fallback below catches any
+    // DEEPSEEK_API_KEY value that doesn't fit this canonical shape.
+    label: "deepseek-api-key",
+    description: "DeepSeek API key (sk- + 32 lowercase hex)",
+    regex: /\bsk-[0-9a-f]{32,}(?![0-9a-z])/g
+  },
+  {
+    label: "openai-api-key",
+    description: "OpenAI API key (sk-\u2026 / sk-proj-\u2026)",
+    regex: /sk-(?:proj-)?[A-Za-z0-9_-]{20,}/g
+  },
+  {
+    // ElevenLabs — sk_ with UNDERSCORE (vs OpenAI sk-), 48 hex.
+    label: "elevenlabs-api-key",
+    description: "ElevenLabs API key (sk_ + 48 hex)",
+    regex: /\bsk_[0-9a-f]{48}\b/g
+  },
+  {
+    // fal.ai — uuid:hex32 (key_id:key_secret); the colon is the signal.
+    label: "fal-api-key",
+    description: "fal.ai key (uuid:hex32)",
+    regex: /\b[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}:[0-9a-f]{32}\b/g
+  },
+  {
+    // Black Forest Labs (FLUX) API key — bfl_ prefix + a long token (sample
+    // bfl_Qo1…). The distinctive prefix + {20,} length keeps false positives near
+    // zero; image-provider sibling of the fal key above.
+    label: "bfl-api-key",
+    description: "Black Forest Labs / FLUX API key (bfl_ + token)",
+    regex: /\bbfl_[A-Za-z0-9_-]{20,}/g
+  },
+  {
+    label: "google-api-key",
+    description: "Google / Gemini API key (AIza\u2026)",
+    regex: /AIza[0-9A-Za-z_-]{35}/g
+  },
+  {
+    label: "google-oauth-secret",
+    description: "Google OAuth client secret (GOCSPX-\u2026)",
+    regex: /GOCSPX-[A-Za-z0-9_-]{28}/g
+  },
+  // ── AWS ─────────────────────────────────────────────────────────────────
+  //
+  // ORDER IS LOAD-BEARING HERE, and it is not the order you would write first.
+  // redactSecrets() applies patterns in sequence to the text it has ALREADY
+  // redacted, so the id pattern must run LAST: it replaces `AKIA…` with a
+  // marker, and the paired rule below anchors on that id. Put the id first and
+  // the pair rule silently stops firing — a guard that is present, tested in
+  // isolation, and dead in place.
+  {
+    // THE HALF THAT MATTERS, and it shipped unmatched for months. An access key
+    // id alone is useless to an attacker; the SECRET key is the credential. So
+    // redacting only the id — and stamping [REDACTED:…] right beside the live
+    // secret — is worse than redacting nothing, because the marker tells the
+    // reader the text was cleaned. Reported by cardmem the day they took AWS on.
+    //
+    // A bare 40-char base64 value CANNOT be matched: it is the shape of every
+    // git object hash and base64 body in every repo we own. So this is
+    // CONTEXT-ONLY, like every other prefix-less secret in this file.
+    //
+    // `access` is REQUIRED in the field name on purpose. A bare `secret_key`
+    // (Terraform's spelling) would drag in far too much; that case is caught by
+    // the paired rule below instead, which is the argument for having both.
+    //
+    // AND THE VALUE CLASS IS "ANYTHING THAT IS NOT A DELIMITER", not an
+    // alphabet. cardmem measured their Tigris secret's charset after 0.8.1 and
+    // it contains `+` — which our class happened to include, but only because
+    // we guessed base64 rather than base64url. Their warning is the one worth
+    // acting on: that is ONE key. It tells us what CAN occur, never what always
+    // occurs, and the next provider's alphabet is another guess we would make
+    // the same way. Under a field literally named `aws_secret_access_key`, the
+    // NAME is the evidence; the value's alphabet adds nothing and can only be
+    // wrong. So the value runs to the first delimiter and no further.
+    //
+    // ONE EXCLUSION, and it is a false positive our own docs produced the
+    // moment the class widened: a value that is a REFERENCE to a secret is not
+    // a secret. `secretAccessKey: process.env.R2_SECRET_ACCESS_KEY!` is code
+    // showing how to READ the credential, and redacting it would put a
+    // [REDACTED:…] marker in a README about wiring up storage. So a value that
+    // is ENTIRELY a dotted identifier path, or starts with a shell/template
+    // expansion, is skipped. It must be the WHOLE value — a real secret may
+    // contain dots, and the exclusion must not fire on one that does.
+    //
+    // THE LENGTH IS A FLOOR, NOT AWS'S 40 — measured by cardmem in production
+    // and it is the finding that matters most here. Their four AWS_*-named
+    // variables on Fly are NOT AWS: they are Tigris (Fly's S3-compatible
+    // store), with a 54-character `tid_` id and a 75-character secret. Every
+    // S3-compatible service — Tigris, R2, MinIO, Backblaze — reuses AWS's
+    // variable NAMES with its own key format.
+    //
+    // Pinning 40 put a shape assumption on top of a name anchor, so the field
+    // said AWS_SECRET_ACCESS_KEY, the value did not look like AWS, and the
+    // credential stayed in the clear with no marker anywhere near it. The field
+    // name is the signal in every context-only pattern in this file; that is
+    // the whole design, and requiring a second signal quietly undid it.
+    label: "aws-secret-access-key",
+    description: "AWS/S3-compatible secret access key ((aws-)secret-access-key field + 20+ non-delimiter chars)",
+    regex: /\b(?:aws[_-]?)?secret[_-]?access[_-]?key\b["'`]?\s*[:=]\s*["'`]?(?!(?:\$|\{)|(?:[A-Za-z_$][A-Za-z0-9_$]*(?:\.[A-Za-z_$][A-Za-z0-9_$]*)+!?)(?=[\s"'`,;]|$))[^\s"'`,;]{20,}/gi
+  },
+  {
+    // An STS session token is a live credential for as long as it lasts, and it
+    // travels in the same dump as the pair above.
+    label: "aws-session-token",
+    description: "AWS session token ((aws-)session-token field + 100+ base64)",
+    regex: /\b(?:aws[_-]?)?session[_-]?token\b["'`]?\s*[:=]\s*["'`]?(?!(?:\$|\{)|(?:[A-Za-z_$][A-Za-z0-9_$]*(?:\.[A-Za-z_$][A-Za-z0-9_$]*)+!?)(?=[\s"'`,;]|$))[^\s"'`,;]{100,}/gi
+  },
+  {
+    // THE WINDOW IS MEASURED, not chosen. Gap between the end of the id and the
+    // start of the secret, in the six formats these actually arrive in:
+    //
+    //   console CSV row            1     terraform provider block   18
+    //   sts assume-role JSON      21     aws CLI credentials file   25
+    //   env export pair           30     docker-compose env         30
+    //
+    // 80 is the largest real case plus room for one intervening line, and both
+    // sides of it are pinned by a fixture — a proximity threshold nothing can
+    // move is a magic number wearing a measurement's clothes (F035.12).
+    //
+    // The false-positive cost is near zero BECAUSE the id must be present: a
+    // 40-char base64 string is only redacted when an AWS access key id sits
+    // within 80 characters of it. That also catches the pair when the field is
+    // named something we never anticipated, which the rule above cannot.
+    label: "aws-secret-access-key-paired",
+    description: "A 40-char base64 value within 80 characters of an AWS access key id",
+    // `=` is deliberately NOT in the leading lookbehind, though it IS in the
+    // value class: base64 padding never STARTS a value, and excluding it there
+    // blocked every `KEY=value` form — measured, `blob=<secret>` went
+    // unredacted while the same pair in CSV and Terraform was caught.
+    //
+    // THE CHEAP LOOKBEHIND GOES FIRST (0.11.1). Both are zero-width at the same
+    // position, so the order does not change what matches — only what it costs.
+    // With the 100-char id search first, EVERY character of a long run paid it:
+    // 50,000 × 'A' took 3.7 s in this one pattern and a 400 KB blob 30+ s in
+    // redactSecrets. `(?<![A-Za-z0-9/+])` rejects every position inside a run
+    // in one step, and the lookahead then demands a whole 40-char value AHEAD
+    // before anything looks behind — so after a space or a colon (where the
+    // first guard passes) it fails in a character or two. The expensive id
+    // search only runs where a complete candidate already stands.
+    regex: /(?<![A-Za-z0-9/+])(?=[A-Za-z0-9/+=]{40}(?![A-Za-z0-9/+=]))(?<=(?:AKIA|ASIA)[0-9A-Z]{16}[\s\S]{0,80})[A-Za-z0-9/+=]{40}/g
+  },
+  {
+    // A SEPARATE LABEL FROM AKIA, and the reason is operational rather than
+    // tidy: the two demand different responses. A leaked long-term key must be
+    // rotated; a leaked STS key may already have expired on its own. A reader
+    // seeing [REDACTED:…] in a log can only make that call if the marker says
+    // which one it was. ASIA was unmatched entirely before 0.8.0, so an
+    // assumed-role dump read as clean.
+    label: "aws-temporary-access-key-id",
+    description: "AWS temporary (STS) access key id (ASIA\u2026)",
+    regex: /\bASIA[0-9A-Z]{16}\b/g
+  },
+  {
+    label: "aws-access-key-id",
+    description: "AWS long-term access key id (AKIA\u2026)",
+    regex: /\bAKIA[0-9A-Z]{16}\b/g
+  },
+  {
+    label: "github-token",
+    description: "GitHub token (ghp_/gho_/ghs_/ghu_/ghr_\u2026)",
+    regex: /\bgh[posru]_[A-Za-z0-9]{36,}\b/g
+  },
+  {
+    // GitHub fine-grained PAT — distinct prefix `github_pat_` (not caught by the
+    // classic gh[posru]_ above), then base62 + a `_` separator (~82 chars total).
+    // The prefix is so distinctive that {50,} keeps false positives at zero.
+    label: "github-fine-grained-pat",
+    description: "GitHub fine-grained personal access token (github_pat_\u2026)",
+    regex: /\bgithub_pat_[A-Za-z0-9_]{50,}/g
+  },
+  {
+    label: "gitlab-token",
+    description: "GitLab personal access token (glpat-\u2026)",
+    regex: /\bglpat-[A-Za-z0-9_-]{20,}/g
+  },
+  {
+    label: "slack-token",
+    description: "Slack token (xox[baprs]-\u2026)",
+    regex: /\bxox[baprs]-[A-Za-z0-9-]{10,}/g
+  },
+  {
+    label: "stripe-secret-key",
+    description: "Stripe live secret/restricted key (sk_live_/rk_live_\u2026)",
+    regex: /\b[rs]k_live_[A-Za-z0-9]{20,}/g
+  },
+  {
+    // Filed by buddy, who found REAL ones sitting in plaintext in their own
+    // transcription DB. Their scrub deliberately runs the format axis ONLY, so a
+    // prefixed secret we do not match is a secret nobody catches — a precise
+    // prefix is the only route that helps them. Zero false-positive risk: the
+    // literal `whsec_` does not occur by accident.
+    label: "stripe-webhook-secret",
+    description: "Stripe webhook signing secret (whsec_\u2026)",
+    regex: /\bwhsec_[A-Za-z0-9+/=_-]{20,}/g
+  },
+  {
+    // Resend (re_…). Lookahead requires a digit in the body so we don't redact
+    // long snake_case identifiers like re_compute_the_thing.
+    label: "resend-api-key",
+    description: "Resend API key (re_ + token)",
+    regex: /\bre_(?=[A-Za-z0-9_]*\d)[A-Za-z0-9_]{24,}\b/g
+  },
+  {
+    label: "supabase-access-token",
+    description: "Supabase personal/management access token (sbp_ + 40 hex)",
+    regex: /\bsbp_[0-9a-f]{40}/g
+  },
+  {
+    label: "supabase-secret-key",
+    description: "Supabase secret API key (sb_secret_\u2026)",
+    regex: /\bsb_secret_[A-Za-z0-9_-]{20,}/g
+  },
+  {
+    // Used by every @broberg/* publish — the highest-value leak from a .env / commit history.
+    label: "npm-token",
+    description: "npm publish/automation token (npm_ + 36 base62)",
+    regex: /\bnpm_[A-Za-z0-9]{36}\b/g
+  },
+  {
+    label: "fly-api-token",
+    description: "Fly.io API token (FlyV1 fm2_\u2026 / fo1_\u2026)",
+    regex: /(?:FlyV1 fm2_[A-Za-z0-9+/=_-]{20,}|\bfo1_[A-Za-z0-9_-]{20,})/g
+  },
+  {
+    // Also covers Turso DB/platform auth tokens AND Supabase anon/service_role
+    // keys — both are JWTs (eyJ…), so the single JWT pattern catches them.
+    label: "jwt",
+    description: "JSON Web Token (eyJ\u2026) \u2014 incl. Turso + Supabase service_role tokens",
+    regex: /\beyJ[A-Za-z0-9_-]{8,}\.eyJ[A-Za-z0-9_-]{8,}\.[A-Za-z0-9_-]{8,}/g
+  },
+  {
+    // genApiKey = randomBytes(24).hex → uk_ + 48 lowercase hex (components' real key,
+    // measured 4/11 2026). F090.6: widened to 32–64 alphanumerics — cardmem's fleet
+    // git gate (F036.23) planted uk_ + 40 mixed and it slipped through; a uk_ prefix
+    // with a tail that long has next to no false positives, and a key from another
+    // generator must not pass the gate because its alphabet differs.
+    label: "upmetrics-key",
+    description: "Upmetrics project key (uk_ + 32\u201364 alphanumerics; real keys are 48 hex)",
+    regex: /\buk_[A-Za-z0-9]{32,64}(?![A-Za-z0-9])/g
+  },
+  {
+    label: "cardmem-key",
+    description: "Cardmem personal/incident/project key (pa_/pi_/pk_ + 64 hex)",
+    regex: /\bp[aik]_[A-Za-z0-9]{20,}/g
+  },
+  {
+    // cardmem inbox-webhook key — piw_ isn't matched by p[aik]_ above (3rd char 'w' ≠ '_').
+    label: "cardmem-webhook-key",
+    description: "Cardmem inbox-webhook key (piw_ + 64 hex)",
+    regex: /\bpiw_[0-9a-f]{64}/g
+  },
+  {
+    // VERIFIED WITH THE OWNER, 2026-08-28: `trail_` + exactly 64 LOWERCASE HEX.
+    // trail generated 2000 keys through @broberg/apikey's generateKey('trail')
+    // and counted the alphabet: 0-9a-f only, length 64-64, no `-`, no `_`. Source
+    // is `${prefix}_${randomBytes(bytes).toString("hex")}`, bytes=32, with a hard
+    // floor of 16 — so even a future caller asking for the minimum yields 32 hex
+    // chars, still above {20,}.
+    //
+    // Recorded because the QUESTION is easy to re-ask and the ANSWER is not: this
+    // is one of the few patterns here assuming alphanumerics only, and had trail
+    // used base64url (the more common one-liner) the `-` and `_` would break the
+    // run, {20,} would never be satisfied, and the WHOLE key would pass through
+    // unredacted — not partially, entirely. Measured rather than assumed, because
+    // two sampled keys cannot tell hex from base64url that has not hit a `-` yet.
+    label: "trail-key",
+    description: "Trail personal API key (trail_ + 64 hex; verified 2026-08-28)",
+    regex: /\btrail_[A-Za-z0-9]{20,}/g
+  },
+  {
+    // Cronjobs API key (cronjobs.webhouse.net) — cj_ + randomBytes(32).base64url =
+    // exactly 43 base64url chars (46 total). Prefix + fixed length = very low FP.
+    // The UI's truncated cj_<8 chars>… preview is shorter than {43} → not matched.
+    // Negative lookahead (not \b) because base64url's `-` breaks a trailing \b.
+    label: "cronjobs-api-key",
+    description: "Cronjobs API key (cj_ + 43 base64url)",
+    regex: /\bcj_[A-Za-z0-9_-]{43}(?![A-Za-z0-9_-])/g
+  },
+  {
+    // HelpDesk API key (helpdesk.broberg.ai) — minted through @broberg/apikey,
+    // which is OURS: generateKey(prefix, 32) → `${prefix}_${randomBytes(32).hex}`,
+    // so exactly 64 LOWERCASE hex. Verified in packages/apikey/src/core.ts rather
+    // than taken from the report. There is no checksum and no internal structure
+    // to anchor on; prefix + fixed length + hex is everything there is, and it is
+    // enough — `hd_live_` followed by exactly 64 hex does not occur by accident.
+    //
+    // THE LENGTH IS EXACT ON PURPOSE, and this is the half that needs defending
+    // in six months. HelpDesk shows a PREVIEW — `hd_live_f4b4cf`, prefix + 6 hex
+    // — deliberately, in their UI and their logs, so a human can see WHICH key
+    // was revoked. It is not a secret. Redacting it breaks a value designed to be
+    // read, and then the preview stops doing its job.
+    //
+    // So the tempting loosening — "let us catch the shortened ones too" — is the
+    // one thing this pattern must never accept. `{64}` excludes the preview, and
+    // a NAMED test says so, because by then nobody will remember why.
+    //
+    // The trailing lookahead covers BOTH cases: 65 hex is not a key, and neither
+    // is 64 lowercase followed by an uppercase hex digit.
+    //
+    // NO PUBLISHABLE VARIANT, measured not assumed: HelpDesk is headless and its
+    // console is a client of the same API using a session token. `grep -c "hd_"`
+    // in the deployed bundle returns 0, so no key ever reaches a browser and the
+    // Stripe pk_live_ trap has no counterpart here. Re-check if that changes.
+    label: "helpdesk-api-key",
+    description: "HelpDesk API key (hd_live_ + 64 hex, minted by @broberg/apikey)",
+    regex: /\bhd_live_[0-9a-f]{64}(?![0-9a-fA-F])/g
+  },
+  {
+    // UpCloud API token — `ucat_` + a ULID: exactly 26 Crockford base32 chars
+    // (no I, L, O, U). Measured in three independent places, not inferred from
+    // the masked example that filed it: UpCloud's API docs (create response),
+    // UpCloud's own Go client fixture, and Kingfisher's rule — all three are in
+    // test/f035-16.test.ts. The token's `id` is a separate UUID and is not a
+    // secret.
+    //
+    // NO EXAMPLE VALUE IN THIS COMMENT, on purpose: the bundle keeps comments,
+    // so a literal token here ships in dist/ and the scanner flags ITSELF — the
+    // pre-commit gate's test caught exactly that on the first 0.10.0 tag.
+    //
+    // Case-insensitive like Kingfisher: Crockford decodes either case, and a
+    // lowercased token is still a live credential. The trailing lookahead keeps
+    // 27 chars from matching its first 26 — and leaves UpCloud's own
+    // `ucat_[REDACTED]` marker alone.
+    label: "upcloud-api-token",
+    description: "UpCloud API token (ucat_ + 26 Crockford base32)",
+    regex: /\bucat_[0-9A-HJKMNP-TV-Z]{26}(?![0-9A-Za-z])/gi
+  },
+  // ── F035.17 — the vault survey of 30 Sep 2026. Every shape below was MEASURED
+  // on values already stored in cardmem's vault (the script read them server-side
+  // and printed only prefix, length and charset), then checked against a source:
+  // Kingfisher's public rule set for vendor tokens, our own minters for fleet keys.
+  // No example value appears in these comments: the bundle keeps comments, and a
+  // literal here would make the scanner flag its own dist/ (see upcloud above).
+  {
+    // Cloudflare's prefixed user API token. 3 in the vault, all 48 after the
+    // prefix; Kingfisher allows 41-64. Runs before the context-only
+    // cloudflare-api-token below so a prefixed one is named by its prefix.
+    label: "cloudflare-user-api-token",
+    description: "Cloudflare user API token (cfut_ + 41-64 base64url)",
+    regex: /\bcfut_[A-Za-z0-9_-]{41,64}(?![A-Za-z0-9_-])/g
+  },
+  {
+    // Runpod: rpa_ + 40 uppercase/digit + a 6-char mixed-case checksum tail
+    // (Kingfisher runpod.1). 2 in the vault, both 46.
+    label: "runpod-api-key",
+    description: "Runpod API key (rpa_ + 46)",
+    regex: /\brpa_[A-Z0-9]{40}[A-Za-z0-9]{6}(?![A-Za-z0-9])/g
+  },
+  {
+    // Hugging Face user (hf_) and org (api_org_) tokens: 34 letters/digits.
+    label: "huggingface-token",
+    description: "Hugging Face token (hf_ / api_org_ + 34)",
+    regex: /\b(?:hf|api_org)_[A-Za-z0-9]{34}(?![A-Za-z0-9])/g
+  },
+  {
+    // Tailscale: tskey-<kind>-<id>-<secret>. The body carries its own dash, so
+    // the class includes it. Measured 50-51 after the kind; Kingfisher's {20,36}
+    // would stop short of those, so the ceiling is ours.
+    label: "tailscale-key",
+    description: "Tailscale key (tskey-<kind>-\u2026)",
+    regex: /\btskey-[a-z]{3,10}-[A-Za-z0-9_-]{20,64}(?![A-Za-z0-9_-])/g
+  },
+  {
+    // Tigris secret access key: tsec_ + exactly 70 (Kingfisher tigris.2).
+    label: "tigris-secret-key",
+    description: "Tigris secret access key (tsec_ + 70)",
+    regex: /\btsec_[A-Za-z0-9_+-]{70}(?![A-Za-z0-9_+-])/g
+  },
+  {
+    // Slack APP-level token. slack-token above only knows xox*, so an xapp-
+    // token went through untouched. Same label on purpose: the vault already
+    // stores it as slack-token, and a second name for one provider helps nobody.
+    label: "slack-token",
+    description: "Slack app-level token (xapp-\u2026)",
+    regex: /\bxapp-\d{1,3}-[A-Za-z0-9]{8,15}-\d{8,15}-[A-Za-z0-9]{20,70}(?![A-Za-z0-9])/g
+  },
+  {
+    // Aiven service password — the credential UpCloud's managed PostgreSQL hands
+    // out. AVNS_ + 19. One in the vault; [Likely] fixed length, and a password
+    // that silently stops matching is caught by the survey re-run, not by luck.
+    label: "aiven-service-password",
+    description: "Aiven service password (AVNS_ + 19) \u2014 UpCloud managed databases",
+    regex: /\bAVNS_[A-Za-z0-9_-]{19}(?![A-Za-z0-9_-])/g
+  },
+  {
+    // BID app key. OURS: broberg-id mints `bidk_${randomBytes(32).base64url}`,
+    // so exactly 43 base64url — a fact about our minter, not a guess.
+    label: "bid-app-key",
+    description: "BID app key (bidk_ + 43 base64url)",
+    regex: /\bbidk_[A-Za-z0-9_-]{43}(?![A-Za-z0-9_-])/g
+  },
+  {
+    // Fleet hex keys measured in the vault. Hex length is fixed by construction
+    // (randomBytes(n).hex), so the survey's lengths are the minter's lengths.
+    label: "beacon-token",
+    description: "Beacon token (bcn_ + 64 hex)",
+    regex: /\bbcn_[0-9a-f]{64}(?![0-9a-fA-F])/g
+  },
+  {
+    label: "mailworker-admin-key",
+    description: "mailworker admin key (mw_ + 64 hex)",
+    regex: /\bmw_[0-9a-f]{64}(?![0-9a-fA-F])/g
+  },
+  {
+    label: "upmetrics-remediation-token",
+    description: "Upmetrics remediation token (umrt_ + 48 hex)",
+    regex: /\bumrt_[0-9a-f]{48}(?![0-9a-fA-F])/g
+  },
+  {
+    // A database URL with a password in it. Matches ONLY the password (the
+    // lookbehind pins scheme://user: before it, the lookahead pins @ after), so
+    // a redacted URL still says which database it points at.
+    //
+    // The password must contain a digit or be 12+ characters — so the
+    // `user:password@` and `user:pass@` placeholders every README carries stay
+    // readable. A real generated DB password clears that bar trivially.
+    label: "connection-string",
+    description: "Password inside a database connection URL",
+    regex: /(?<=\b(?:postgres(?:ql)?|mysql|mariadb|mongodb(?:\+srv)?|rediss?|amqps?):\/\/[^\s:@/]+:)(?=[^\s@/]*\d|[^\s@/]{12})[^\s@/]+(?=@)/gi
+  },
+  {
+    // randomBytes(32).hex → wh_ + 64 lowercase hex (67 chars total).
+    // NOTE: unlike cj_ and hd_live_ above, this one has no trailing lookahead, so
+    // wh_ + 65 hex matches its first 64. Not a leak (the value is still redacted)
+    // and not changed here — flagged rather than silently altered in a card about
+    // something else.
+    label: "cms-access-token",
+    description: "webhouse.app CMS access token (wh_ + 64 hex)",
+    regex: /\bwh_[0-9a-f]{64}/g
+  },
+  {
+    // Cloudflare API token (R2 / DNS management) — 40 base64url chars, NO prefix.
+    // A bare {40} would false-positive broadly, so this is CONTEXT-ONLY: it only
+    // fires next to a cf/cloudflare-api-token-named field. Runs before
+    // labeled-hex-secret so a hex-valued CF token is attributed correctly.
+    label: "cloudflare-api-token",
+    description: "Cloudflare API token (cf/cloudflare-api-token field + 40 base64url)",
+    regex: /\b(?:cf|cloudflare)_?api_?token\b\s*[:=]\s*["'`]?[A-Za-z0-9_-]{40}(?![A-Za-z0-9_-])/gi
+  },
+  {
+    // F035.20 — Mistral's newer keys carry a prefix: `mstrl_` + 32 base62 + `_` +
+    // 6 base62 (45 chars). Measured by cardmem on ONE stored key, value never
+    // sent. The prefix makes it distinctive, so it runs by default (D-453d89).
+    // Exact shape only: a key with another split is left unlabelled, not guessed.
+    label: "mistral-api-key",
+    description: "Mistral API key (mstrl_ + 32 base62 + _ + 6 base62)",
+    regex: /\bmstrl_[A-Za-z0-9]{32}_[A-Za-z0-9]{6}(?![A-Za-z0-9_-])/g
+  },
+  {
+    // Mistral API key — prefix-less ~32 base62 (Christian-confirmed sample). A bare
+    // [A-Za-z0-9]{32} would FP on every ID/hash, so CONTEXT-ONLY: anchored on a
+    // mistral-(api-)key/token-named field. Runs before labeled-hex for attribution.
+    label: "mistral-api-key",
+    description: "Mistral API key (mistral-(api-)key/token field + 24+ base62)",
+    regex: /\bmistral(?:[_-]?api)?[_-]?(?:key|token)\b\s*[:=]\s*["'`]?[A-Za-z0-9]{24,}(?![A-Za-z0-9])/gi
+  },
+  {
+    // DeepSeek — field-anchored fallback for any DEEPSEEK_API_KEY/TOKEN value that
+    // doesn't fit the canonical sk-+hex shape (mirrors the Mistral context-only
+    // approach). The field name is the signal → near-zero false positives. The
+    // sk-+hex format pattern above already attributes the canonical shape; this
+    // backstops a format change or an opaque token.
+    label: "deepseek-api-key",
+    description: "DeepSeek API key (deepseek-(api-)key/token field + 20+ token)",
+    regex: /\bdeepseek(?:[_-]?api)?[_-]?(?:key|token)\b\s*[:=]\s*["'`]?[A-Za-z0-9_-]{20,}(?![A-Za-z0-9_-])/gi
+  },
+  {
+    // Vimeo personal access token — ~32 lowercase hex, no prefix (sanne). A bare
+    // hex32 would FP massively (MD5/UUID), so CONTEXT-ONLY: anchored on a
+    // vimeo-(access-)token-named field.
+    label: "vimeo-access-token",
+    description: "Vimeo access token (vimeo-(access-)token field + 20+ base62)",
+    regex: /\bvimeo(?:[_-]?access)?[_-]?token\b\s*[:=]\s*["'`]?[A-Za-z0-9]{20,}(?![A-Za-z0-9])/gi
+  },
+  {
+    // F035.22 — every key @broberg/apikey mints: generateKey(prefix) returns
+    // `${prefix}_${randomBytes(32).toString("hex")}`. The named fleet prefixes
+    // above (uk_, pa_, piw_, trail_ …) keep their own labels — they match first.
+    // Buzz's bz_ was not on any list and went to its log in clear text
+    // (buzzalert #4388); every new apikey consumer brings a new prefix, so a
+    // list by name always lags. Exactly 64 LOWER-case hex after a short
+    // lower-case prefix and an underscore, bounded both sides — a bare digest or
+    // `sha256:<hex>` has no `<prefix>_` and is left alone.
+    label: "apikey-prefixed-key",
+    description: "A key minted by @broberg/apikey generateKey (<prefix>_<64 hex>)",
+    regex: /(?<![A-Za-z0-9_])[a-z][a-z0-9]{1,15}_[0-9a-f]{64}(?![A-Za-z0-9_])/g
+  },
+  {
+    // Context-based catch for prefix-less high-entropy service secrets
+    // (CMS_JWT_SECRET, revalidateSecret, fleet openssl-rand-hex secrets): a 40+
+    // hex value assigned to a field whose name contains
+    // secret/token/password/api-key. The name requirement keeps the
+    // false-positive rate near zero (a bare 40/64-hex would hit shas/hashes).
+    label: "labeled-hex-secret",
+    description: "A 40+ hex value assigned to a secret/token/password/api-key-named field",
+    regex: /\b[A-Za-z0-9_-]*(?:secret|token|password|api[_-]?key)\b\s*[:=]\s*["'`]?[0-9a-f]{40,}/gi
+  },
+  {
+    // F090.6 — a bearer token with no known prefix (cardmem's git gate, F036.23).
+    // CONTEXT, not randomness: the word «Bearer» is the signal, like the field name
+    // is for labeled-hex-secret. The value must look like a secret, not a word or a
+    // placeholder: 24+ token chars, a digit AND a letter, and either an uppercase
+    // letter or four digits. «Bearer <token>», «Bearer ${TOKEN}» and «Bearer abc» are
+    // left alone. A JWT after Bearer is caught earlier by its own pattern.
+    label: "bearer-token",
+    description: "A high-entropy value after \xABBearer \xBB (no known prefix)",
+    regex: /\bBearer\s+(?=[A-Za-z0-9._~+\/-]*\d)(?=[A-Za-z0-9._~+\/-]*[A-Za-z])(?=[A-Za-z0-9._~+\/-]*[A-Z]|(?:[A-Za-z0-9._~+\/-]*\d){4})[A-Za-z0-9._~+\/-]{24,}={0,2}(?![A-Za-z0-9._~+\/-])/g
+  },
+  {
+    // F090.6 — the same shape assigned to token=/key=/secret= (a URL query or an
+    // env line) with no known prefix. Case-sensitive on purpose: /i would make the
+    // [A-Z] requirement match lowercase and let identifiers through.
+    label: "labeled-token-param",
+    description: "A high-entropy value in token=/key=/secret=/api_key=/access_token=",
+    regex: /(?<![A-Za-z0-9_])(?:access_token|api_key|apikey|token|key|secret|ACCESS_TOKEN|API_KEY|APIKEY|TOKEN|KEY|SECRET)=(?=[A-Za-z0-9._~+\/-]*\d)(?=[A-Za-z0-9._~+\/-]*[A-Za-z])(?=[A-Za-z0-9._~+\/-]*[A-Z]|(?:[A-Za-z0-9._~+\/-]*\d){4})[A-Za-z0-9._~+\/-]{24,}={0,2}(?![A-Za-z0-9._~+\/-])/g
+  },
+  {
+    // Discord bot token — three base64url segments. Anchored both sides so it
+    // can't partial-match a longer dotted string.
+    label: "discord-bot-token",
+    description: "Discord bot token (3 base64url segments)",
+    regex: /(?<![A-Za-z0-9_-])[A-Za-z0-9_-]{24,26}\.[A-Za-z0-9_-]{6}\.[A-Za-z0-9_-]{27,40}(?![A-Za-z0-9_-])/g
+  },
+  {
+    label: "discord-mfa-token",
+    description: "Discord MFA token (mfa. + 84 chars)",
+    regex: /\bmfa\.[A-Za-z0-9_-]{84}\b/g
+  },
+  {
+    // Cloudflare Turnstile PROD secret (sanne, verified 2/2) — 0x4 + 6×A prefix,
+    // then 26 base64url (35 total). The 24-char SITE key + 1x/2x/3x TEST keys are
+    // intentionally NOT matched (the {26} length gate misses them) so a public
+    // key is never redacted.
+    label: "cloudflare-turnstile-secret",
+    description: "Cloudflare Turnstile secret key (0x4AAAAAA + 26 base64url, 35 total)",
+    regex: /0x4AAAAAA[A-Za-z0-9_-]{26}(?![A-Za-z0-9_-])/g
+  },
+  {
+    label: "cloudflare-global-key",
+    description: "Cloudflare global API key (37-hex)",
+    regex: /\b[0-9a-f]{37}\b/g
+  },
+  {
+    // LAST on purpose: this is the only unprefixed shape in the list, so every
+    // anchored pattern above must get first refusal.
+    //
+    // Philips Hue v2 application key — 40 chars of [A-Za-z0-9-] with NO prefix,
+    // so there is nothing to anchor on. The negative lookahead is load-bearing,
+    // not decoration: a bare [A-Za-z0-9-]{40} also matches a GIT COMMIT SHA, and
+    // telemetry/error output is full of those. A redactor that eats commit
+    // hashes gets switched off within a week, after which it protects nothing.
+    //
+    // F035.10 — THAT SENTENCE CAME TRUE ABOUT THIS VERY PATTERN. It was the only
+    // prefix-less pattern here matching on ENTROPY ALONE, and base64 is
+    // mixed-case alphanumeric, so it fired inside npm integrity digests:
+    //
+    //   resolution: {integrity: sha512-ABkD1WhyfPZprKRQI3bhATjeiFuNWC9PXhfGWqL+sg/…}
+    //                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ matched
+    //
+    // 33 hits in components' own pnpm-lock.yaml, 32 of them digests. (`-` is in
+    // the class but is not a word character, so \b anchors happily mid-digest.)
+    // Reported by trail, whose gate then could not commit a lockfile change —
+    // i.e. no dependency update at all. A gate nobody can satisfy is a gate
+    // someone switches off, which costs more than the hole it closed.
+    //
+    // It is now CONTEXT-ONLY like every other prefix-less secret in this file
+    // (cloudflare-api-token, mistral-api-key, vimeo-access-token,
+    // labeled-hex-secret): the field name is the signal, not the randomness.
+    // Deliberately given up: a bare 40-char Hue key in prose with no field name.
+    // See the README's "Deliberately NOT detected" — do not remove the anchor to
+    // "fix" that; a pattern that cannot tell a key from a checksum is worse than
+    // no pattern. (Original pattern contributed by beacon, F035.7.)
+    label: "hue-application-key",
+    description: "Philips Hue application key (hue/bridge-named field + 40 chars)",
+    // The `["'`]?` BEFORE the separator is not decoration: a Hue key most often
+    // arrives as JSON — {"hue_application_key": "…"} — and the four older
+    // context-only patterns in this file all omit it, so they miss the quoted
+    // form. Noted rather than silently changed there; that is its own card.
+    regex: /\b(?:hue|bridge)[_-]?(?:application[_-]?key|username|user|key)\b["'`]?\s*[:=]\s*["'`]?[A-Za-z0-9-]{40}(?![A-Za-z0-9-])/gi
+  }
+];
+var HUE_KEY_BODY = String.raw`(?=[A-Za-z0-9-]*[a-z])(?=[A-Za-z0-9-]*[A-Z])[A-Za-z0-9-]{40}`;
+var VALUE_ONLY = [
+  {
+    label: "hue-application-key",
+    description: "Philips Hue application key (40 chars, no prefix)",
+    // Anchored: `classify` is handed ONE value and asks what it is.
+    regex: new RegExp(String.raw`^(?=[A-Za-z0-9-]{40}$)${HUE_KEY_BODY}$`)
+  }
+];
+var withoutGlobal = (list) => Object.freeze(
+  list.map(
+    (p) => Object.freeze({ ...p, regex: new RegExp(p.regex.source, p.regex.flags.replace("g", "")) })
+  )
+);
+withoutGlobal(PATTERNS);
+withoutGlobal(VALUE_ONLY);
+var SECRETS_NOT_EXAMINED = ["personal-data"];
+var redactionMarker = (label) => `[REDACTED:${label}]`;
+function patternsFor(opts) {
+  return opts?.extraPatterns && opts.extraPatterns.length > 0 ? [...PATTERNS, ...opts.extraPatterns] : PATTERNS;
+}
+function redactSecrets(text, opts) {
+  const scanned = opts?.announced ? ["format", "announced"] : ["format"];
+  const notExamined = SECRETS_NOT_EXAMINED;
+  if (!text) return { redacted: text, findings: [], scanned, notExamined };
+  let redacted = text;
+  const findings = [];
+  for (const p of patternsFor(opts)) {
+    let count = 0;
+    redacted = redacted.replace(p.regex, () => {
+      count++;
+      return redactionMarker(p.label);
+    });
+    if (count > 0) findings.push({ label: p.label, count, confidence: "format" });
+  }
+  return { redacted, findings, scanned, notExamined };
+}
+
+// src/cli.ts
+function scanText(text) {
+  const hits = [];
+  const perLine = /* @__PURE__ */ new Map();
+  text.split("\n").forEach((line, i) => {
+    for (const f of redactSecrets(line).findings) {
+      hits.push({ label: f.label, line: i + 1 });
+      perLine.set(f.label, (perLine.get(f.label) ?? 0) + f.count);
+    }
+  });
+  for (const f of redactSecrets(text).findings) {
+    if ((perLine.get(f.label) ?? 0) < f.count) hits.push({ label: f.label, line: null });
+  }
+  return hits;
+}
+async function main(argv) {
+  if (!argv.includes("--stdin")) {
+    process.stderr.write("usage: secret-scan --stdin   (reads text on stdin; exit 1 = secret found, 0 = none, 2 = error)\n");
+    return 2;
+  }
+  const chunks = [];
+  for await (const c of process.stdin) chunks.push(c);
+  const hits = scanText(Buffer.concat(chunks).toString("utf8"));
+  for (const h of hits) process.stderr.write(`secret-scan: ${h.label} ${h.line === null ? "(spans several lines)" : `line ${h.line}`}
+`);
+  if (hits.length) process.stderr.write(`secret-scan: ${hits.length} finding(s) \u2014 values not shown. Remove the secret; if it was ever committed or pushed, ROTATE it.
+`);
+  return hits.length ? 1 : 0;
+}
+var isMain = process.argv[1] && /secret-scan|cli\.(c?js|ts)$/.test(process.argv[1]);
+if (isMain) {
+  main(process.argv.slice(2)).then(
+    (code) => process.exit(code),
+    (e) => {
+      process.stderr.write(`secret-scan: could not scan: ${e instanceof Error ? e.message : String(e)}
+`);
+      process.exit(2);
+    }
+  );
+}
+
+export { scanText };
+//# sourceMappingURL=cli.js.map
+//# sourceMappingURL=cli.js.map