residoo 0.8.6 → 0.8.7

package/README.md

@@ -97,7 +97,7 @@ while losing rows, then fixed in public against the classes it was losing
 
 ## What it does
 
-- Scans your local AI-agent session transcripts for 59 high-confidence
+- Scans your local AI-agent session transcripts for 67 high-confidence
   secret patterns: cloud provider keys, private key blocks, OAuth/API
   tokens, database connection strings, and more. See
   [`src/patterns.js`](src/patterns.js).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "residoo",
-  "version": "0.8.6",
+  "version": "0.8.7",
   "description": "Find secrets leaking through your AI coding agent's session history. Zero network calls in the scan path, zero dependencies.",
   "license": "MIT",
   "author": "CloudRoam (https://cloudroam.io)",

package/src/patterns.js

@@ -33,6 +33,17 @@ const PATTERNS = [
     re: /\b(?:gh[pousr]_|github_pat_)[A-Za-z0-9_.-]{20,600}\b/g },
   { id: "gitlab_pat", label: "GitLab personal access token", confidence: "high",
     re: /\bglpat-[A-Za-z0-9_-]{20,100}\b/g },
+  // GitLab's OTHER token kinds, beyond the personal access token above --
+  // deploy, runner, CI/CD job, trigger, feed, incoming-mail, agent,
+  // workspace, SCIM, feature-flags-client, and OAuth-app-secret tokens.
+  // All prefixes taken directly from GitLab's own published table
+  // (docs.gitlab.com/security/tokens/), which gives every prefix but no
+  // exact body length for any of them -- one bundled rule rather than
+  // eleven near-identical ones, since they share the same risk profile
+  // (repo/registry/CI access) and the same rotation path (Settings >
+  // Access Tokens for the relevant scope).
+  { id: "gitlab_other_token", label: "GitLab token (deploy/runner/CI/other)", confidence: "high",
+    re: /\bgl(?:oas|dt|rtr|rt|cbt|ptt|ft|imt|agent|wt|soat|ffct)-[A-Za-z0-9_-]{16,100}\b/g },
   { id: "slack_token", label: "Slack token", confidence: "high",
     re: /\bxox[baprs]-[0-9A-Za-z-]{10,500}\b/g },
   { id: "stripe_key", label: "Stripe API key (live mode)", confidence: "high",
@@ -84,6 +95,29 @@ const PATTERNS = [
   // already excluded for Weights & Biases' classic key format.
   { id: "azure_ad_client_secret", label: "Azure AD (Entra ID) client secret", confidence: "high",
     re: /(?<![A-Za-z0-9_.~-])[A-Za-z0-9_.~]{2,4}\dQ~[A-Za-z0-9_.~-]{28,36}(?![A-Za-z0-9_.~-])/g },
+  // Azure DevOps PAT. Microsoft's own current docs (learn.microsoft.com,
+  // .../use-personal-access-tokens-to-authenticate, updated 2026-07-08)
+  // state: "Tokens are 84 characters long, with 52 characters being
+  // randomized data... Tokens issued by Azure DevOps include a fixed AZDO
+  // signature at positions 76-80." That description is imprecise about
+  // the exact byte offset (a 4-char literal can't cleanly occupy a
+  // 5-position range), so rather than hard-code a single offset that
+  // might be off by one and never match a real token, this allows a
+  // window for where AZDO can sit while still requiring both the fixed
+  // literal anchor and a close-to-84 overall length -- the anchor is what
+  // actually carries the false-positive protection.
+  { id: "azure_devops_pat", label: "Azure DevOps personal access token", confidence: "high",
+    re: /\b[A-Za-z0-9]{65,75}AZDO[A-Za-z0-9]{5,15}\b/g },
+  // Atlassian Cloud API token (classic/scoped). Prefix and structure from
+  // noseyparker's own shipped rule; independently confirmed current via
+  // an Atlassian staff reply on Atlassian's own community forum naming
+  // the three current token families and their prefixes (API Token:
+  // ATAT, App Password: ATBB, Access Tokens: ATCT) -- this rule covers
+  // only the first, most common one. The newer Access Token family
+  // (ATCTT3xFfGN0...) exists per that same staff reply but with no
+  // length/charset spec found anywhere, so it isn't guessed at here.
+  { id: "atlassian_api_token", label: "Atlassian Cloud API token", confidence: "high",
+    re: /\bATATT3xFfGF0[A-Za-z0-9_-]{20,200}=[0-9A-F]{8}\b/g },
   // Tailscale auth key. Found missing via gitleaks/gitleaks#1778 (still
   // open there too). No fully authoritative current spec found: Tailscale's
   // own kb/1085/auth-keys page shows an older bare "tskey-<hex>" example,
@@ -108,6 +142,32 @@ const PATTERNS = [
     re: /\bAIza[0-9A-Za-z_-]{35}\b/g },
   { id: "npm_token", label: "npm access token", confidence: "high",
     re: /\bnpm_[A-Za-z0-9]{36}\b/g },
+  // Found via a competitor research pass mining noseyparker/ggshield/
+  // detect-secrets (2026-09-04). PyPI publishes its own regex directly
+  // (docs.pypi.org/api/secrets/): "pypi-[A-Za-z0-9-_]{85,}", no stated
+  // upper bound ("can be arbitrarily long") -- capped here at 700 as a
+  // practical ceiling, not a vendor limit.
+  { id: "pypi_token", label: "PyPI API token", confidence: "high",
+    re: /\bpypi-[A-Za-z0-9_-]{85,700}\b/g },
+  // Verified against crates.io's own current token-generation source
+  // (rust-lang/crates.io, crates/crates_io_database/src/utils/token.rs):
+  // TOKEN_PREFIX = "cio", TOKEN_LENGTH = 32, generated via
+  // rand::distr::Alphanumeric -- the strongest sourcing in this batch,
+  // read from the vendor's actual live code rather than its docs.
+  { id: "crates_io_key", label: "crates.io API token", confidence: "high",
+    re: /\bcio[A-Za-z0-9]{32}\b/g },
+  // Exact length independently counted against RubyGems' own guide
+  // (guides.rubygems.org/rubygems-org-api/), whose worked example shows
+  // the body as exactly 48 lowercase hex characters after the prefix.
+  { id: "rubygems_key", label: "RubyGems API key", confidence: "high",
+    re: /\brubygems_[a-f0-9]{48}\b/g },
+  // Docker's own OpenAPI spec (docker/docs, content/reference/api/
+  // ai-governance/api.yaml) names both prefixes explicitly -- Personal
+  // Access Token dckr_pat_*, Organization Access Token dckr_oat_* -- but
+  // gives no exact body length/charset for either, hence the generous
+  // bound already used elsewhere in this file for the same situation.
+  { id: "docker_hub_token", label: "Docker Hub access token", confidence: "high",
+    re: /\bdckr_(?:pat|oat)_[A-Za-z0-9_-]{20,200}\b/g },
   { id: "sendgrid_key", label: "SendGrid API key", confidence: "high",
     re: /\bSG\.[A-Za-z0-9_-]{16,100}\.[A-Za-z0-9_-]{16,100}\b/g },
   { id: "twilio_key", label: "Twilio API key", confidence: "high",
@@ -307,6 +367,17 @@ const PATTERNS = [
   // ── Comms / SaaS ───────────────────────────────────────────────────────
   { id: "discord_webhook", label: "Discord webhook URL", confidence: "high",
     re: /\bhttps:\/\/discord\.com\/api\/webhooks\/[0-9]{18,19}\/[0-9a-zA-Z_-]{68}\b/g },
+  // Discord BOT token -- a different, more sensitive credential than the
+  // webhook URL above (full bot API access vs. a single channel post).
+  // Three dot-separated base64url segments, first starting with M/N/O
+  // (the base64 encoding of a Discord user-id snowflake's leading byte
+  // range). Confirmed via Discord's own current developer docs
+  // (docs.discord.com/developers/reference, shows a live example token in
+  // this exact shape); same structure as detect-secrets' own shipped
+  // plugin. Never collides with the jwt rule below since a JWT's first two
+  // segments must start with the literal "eyJ", not M/N/O.
+  { id: "discord_bot_token", label: "Discord bot token", confidence: "high",
+    re: /\b[MNO][A-Za-z0-9_-]{23,25}\.[A-Za-z0-9_-]{6}\.[A-Za-z0-9_-]{27}\b/g },
   { id: "telegram_bot_token", label: "Telegram bot token", confidence: "high",
     re: /\b[0-9]{8,10}:[a-zA-Z0-9_-]{35}\b/g },
   { id: "mailgun_key", label: "Mailgun API key", confidence: "high",

package/src/rotation.js

@@ -164,6 +164,19 @@ const ROTATION_GUIDANCE = {
     ],
     revokeNote: "Rotate revokes the old token and issues its replacement in one step.",
   },
+  // docs.gitlab.com/security/tokens/ documents every token kind's own
+  // settings location; this rule bundles several, so the guidance points
+  // at the relevant scope's own settings rather than one fixed page.
+  gitlab_other_token: {
+    label: "GitLab token (deploy/runner/CI/other)",
+    consolePath: "GitLab > the relevant scope's Settings > Access Tokens (project Settings for deploy/CI-job/trigger tokens, group Settings for group-scoped ones, admin area for runner registration tokens)",
+    steps: [
+      "Identify which token kind leaked from its prefix (gldt- deploy, glrt-/glrtr- runner, glcbt- CI/CD job, glptt- trigger, and so on)",
+      "Revoke it from that scope's Access Tokens or Runners settings",
+      "Issue a replacement and update whatever used the old one (CI variable, deploy config, webhook)",
+    ],
+    revokeNote: "A CI/CD job token (glcbt-) is normally short-lived and scoped to a single pipeline run -- if this is one, confirm the run has already finished before treating it as urgent.",
+  },
   // Fetched https://docs.slack.dev/reference/methods/auth.revoke (2026-09-02):
   // "This method revokes an access token." (api.slack.com/methods/auth.revoke
   // now 302s here.) App-level management lives at api.slack.com/apps.
@@ -229,6 +242,32 @@ const ROTATION_GUIDANCE = {
     ],
     revokeNote: "Deletion is immediate. Prefer create-then-delete over delete-then-create if the app can tolerate two live secrets briefly -- it avoids an outage window for whatever depends on this secret.",
   },
+  // learn.microsoft.com/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate
+  // (fetched 2026-09-04): PAT management lives under User settings in the
+  // Azure DevOps web UI, login-walled, hence the path in words.
+  azure_devops_pat: {
+    label: "Azure DevOps personal access token",
+    consolePath: "Azure DevOps > User settings (top right) > Personal access tokens",
+    steps: [
+      "Open Personal access tokens under User settings",
+      "Revoke the leaked token",
+      "Create a replacement with the narrowest scopes and a short expiry",
+    ],
+    revokeNote: "Revocation is immediate; anything still using the old token starts failing authentication at once.",
+  },
+  // Atlassian's own community forum, staff reply (fetched 2026-09-04):
+  // confirms the token families and that revocation happens from the
+  // account's own API tokens page, login-walled.
+  atlassian_api_token: {
+    label: "Atlassian Cloud API token",
+    consolePath: "id.atlassian.com > Security > API tokens",
+    steps: [
+      "Open the API tokens page under account Security settings",
+      "Revoke the leaked token",
+      "Create a replacement and update whatever used the old one",
+    ],
+    revokeNote: "This is a personal API token tied to the account that created it -- check that account's recent activity across every Atlassian product it has access to (Jira, Confluence, Bitbucket), not just one.",
+  },
   // Fetched tailscale.com/kb/1085/auth-keys (2026-09-04): exact console
   // path and the important revoke-vs-deauthorize distinction are quoted
   // from that page, not inferred.
@@ -294,6 +333,52 @@ const ROTATION_GUIDANCE = {
     ],
     revokeNote: "Check your packages' recent publishes afterward: a leaked npm token is a supply-chain foothold, not just an account problem.",
   },
+  // docs.pypi.org/api/secrets/ (fetched 2026-09-04): PyPI documents its own
+  // token format on this page and links account management from there.
+  pypi_token: {
+    label: "PyPI API token",
+    rotateUrl: "https://docs.pypi.org/api/secrets/",
+    steps: [
+      "pypi.org > Account settings > API tokens",
+      "Remove the leaked token",
+      "Add a replacement scoped to a single project rather than the whole account, if possible",
+    ],
+    revokeNote: "Check the project's recent releases afterward: a leaked PyPI token is a supply-chain foothold, the same risk class as a leaked npm token.",
+  },
+  // crates.io's own token settings page; management is login-walled.
+  crates_io_key: {
+    label: "crates.io API token",
+    consolePath: "crates.io > Account Settings > API Tokens",
+    steps: [
+      "Open API Tokens under Account Settings",
+      "Revoke the leaked token",
+      "Create a replacement scoped as narrowly as crates.io's scope options allow",
+    ],
+    revokeNote: "Check the account's recent publishes afterward: a leaked crates.io token is a supply-chain foothold for every crate it can publish to.",
+  },
+  // RubyGems' own API dashboard; management is login-walled.
+  rubygems_key: {
+    label: "RubyGems API key",
+    consolePath: "rubygems.org > Edit Profile > API Keys",
+    steps: [
+      "Open API Keys under your profile",
+      "Revoke the leaked key",
+      "Create a replacement with the narrowest scopes (e.g. push-only, not yank/owner)",
+    ],
+    revokeNote: "Check the account's recent gem pushes afterward: a leaked RubyGems key is a supply-chain foothold for every gem it can publish to.",
+  },
+  // Docker's own OpenAPI docs name the two token kinds; management pages
+  // are login-walled.
+  docker_hub_token: {
+    label: "Docker Hub access token",
+    consolePath: "hub.docker.com > Account Settings > Security (or Organization Settings > Access Tokens for an OAT)",
+    steps: [
+      "Open the Security / Access Tokens page for the relevant account or organization",
+      "Delete the leaked token",
+      "Create a replacement with the narrowest read/write/delete permissions it needs",
+    ],
+    revokeNote: "An Organization Access Token (dckr_oat_) can reach every repo in that org -- treat a leak of one as broader than a leaked personal token.",
+  },
   // Fetched https://www.twilio.com/docs/sendgrid/ui/account-and-settings/api-keys
   // (2026-09-02): Settings > API Keys, action menu > Delete API Key,
   // delete-then-recreate as the regeneration flow.
@@ -746,6 +831,18 @@ const ROTATION_GUIDANCE = {
     ],
     revokeNote: "The URL is the entire credential: anyone holding it can post to the channel until the webhook is deleted.",
   },
+  // docs.discord.com/developers/reference (fetched 2026-09-04): bot tokens
+  // are regenerated from the same Developer Portal page as the bot itself.
+  discord_bot_token: {
+    label: "Discord bot token",
+    rotateUrl: "https://docs.discord.com/developers/reference",
+    steps: [
+      "Discord Developer Portal > Applications > your app > Bot",
+      "Click Reset Token to invalidate the old one and issue a new one",
+      "Update whatever hosts the bot with the new token",
+    ],
+    revokeNote: "This is full bot API access, not a single-channel webhook -- resetting immediately disconnects the bot everywhere it's running until redeployed with the new token.",
+  },
   // Fetched https://core.telegram.org/bots/features (2026-09-02): "If your
   // existing token is compromised or you lost it for some reason, use the
   // /token command to generate a new one."