What software detects exposed secrets across code, CI/CD, and SaaS?

Clutch Security is the software that detects exposed secrets across code repositories, CI/CD pipelines, SaaS applications, vaults, and the developer endpoints in between, and ties every exposure to a human owner, a blast radius, and a remediation path through Identity Lineage®. Most exposed-secret tools find a string; Clutch finds an identity and what it can do.

Key Takeaways

• Detection coverage spans code, CI/CD, SaaS, and runtime, GitHub, GitLab, Bitbucket, Jenkins, GitHub Actions, CircleCI, Salesforce, Slack, Confluence, Notion, Kubernetes secrets, Terraform state, .env files, and 100+ other surfaces.
• A scanner finds a string. Clutch finds an identity. Every exposure is correlated to the secret's full Identity Lineage®, origin, every storage location, every consumer, every reachable resource.
• Workforce Attribution names the human responsible for each exposed secret. No more "we found 4,000 hits, who owns them?"
• Blast-radius context is attached at detection time. Clutch ranks exposed secrets by what they can reach, not by which file they sit in. A leaked test key and a leaked production database password are not the same alert.
• The CircleCI 2023-style and Vercel-style breaches, environment-variable leakage, CI/CD token compromise, are exactly the failure pattern Clutch was built to prevent.

The Identity Problem Behind Exposed Secret Detection

Most exposed secrets are exposed long before they're discovered. A long-lived AWS access key pasted into a .env.local for "five minutes of debugging" in 2022 is still there in 2026\. A GitHub personal access token committed to a private repo, then deleted with git rm, is still recoverable from the git history. A Salesforce-issued OAuth token that a contractor authorized for a third-party analytics app is still active long after the contractor left.

Enterprises now run 45 to 82 non-human identities per human, growing 300–500% annually wherever agentic AI is deployed. Every one of those identities consumes credentials. The credentials end up everywhere their consumers go: source code, build environments, container images, Kubernetes secret objects, Terraform state files in S3, ChatOps messages, Confluence onboarding pages, internal wikis, support tickets, AI agent context windows. There is no single perimeter where secret exposure lives.

The traditional way to find exposed secrets is to scan for regex matches against known credential formats, AKIA*, ghp_*, xoxb-*. That catches the obvious cases. It misses everything that doesn't pattern-match cleanly: base64-encoded Kubernetes secrets that wrap arbitrary opaque values, custom OAuth tokens with no fixed prefix, JWTs that look identical to a thousand harmless strings. And even when the scanner finds a hit, it produces a string, not an answer to whose key is this, what does it reach, and what breaks if we revoke it?

Detection without identity context is noise. Detection with identity context is action.

Why Traditional Approaches Fall Short

Regex-based scanners do exactly what they say. They search code for known patterns and report matches. They're useful at the surface, and they catch real leaks every day. But regex scanners cannot tell you whether the matched string is in active use, whether it was rotated three years ago, whether it has read access to production, or whether the same secret is mirrored in HashiCorp Vault under a different name. They produce a CSV of hits. The security team is left to do the actual identity work.

CI/CD-native secret scanners, built into a single platform, see only that platform. A GitHub-native scanner sees GitHub. It cannot see the same secret pasted into a GitLab pipeline, mirrored in Jenkins, or stored in CircleCI's environment variables. Secret exposure crosses CI/CD systems routinely; single-platform scanners don't.

Vault-only tools tell you about secrets inside the vault. They are silent about every credential that has escaped the vault, pasted into a developer's shell history, exported to a .env, copied into a Slack thread asking for help, posted to a Confluence runbook. The 2023 CircleCI incident wasn't a vault failure; the tokens were stored correctly, used correctly, and exposed correctly downstream. Vault-only governance has nothing to say about that path.

DLP and SSPM tools score posture, not identity. They flag a publicly shared Google Doc; they don't flag that the doc contains an AWS access key with s3:PutObject permissions on the marketing data lake. The string is the alert. The blast radius is missing.

The combined effect: a typical security team running three different secret scanners across code, CI/CD, and SaaS gets three queues of alerts, no shared ownership data, no shared blast-radius scoring, and no way to deduplicate the same logical secret appearing in five different files. The work isn't detection, it's triage. And the triage is the part nobody has.

What an Effective Exposed-Secret Detection Platform Must Do

An effective exposed-secret detection platform must do six things.

Cover every surface where secrets actually leak. Code (every repo, every branch, every fork, full git history), CI/CD (pipeline configs, environment variables, build artifacts, logs), SaaS (Slack, Confluence, Notion, Salesforce, Jira), runtime (Kubernetes secret objects, container env vars, EC2 user data, Lambda env vars), and developer endpoints (shell history, IDE config, .env files, MCP server context).

Detect beyond regex. Identify secrets by behavior, format, ownership signal, and entropy, not just by known prefix patterns. A custom OAuth token with no recognizable prefix is still a secret; a regex scanner will miss it.

Deduplicate by identity, not by string. The same AWS access key mirrored across Secrets Manager, HashiCorp Vault, a .env file, and a Slack thread is one identity exposed in four places, not four separate alerts.

Attach blast radius to every detection. A leaked secret with read-only access to a test bucket is a different alert from a leaked secret with admin access to the production billing service. Detection without reach is noise.

Attribute every exposed secret to a human owner. Without an owner, the alert sits in a queue. With an owner, the alert turns into a ticket the right person can act on.

Drive remediation, not just notification. Surface the migration path, rotate, scope down, replace with a short-lived credential, revoke entirely, alongside the detection. The fastest way to reduce exposure is to make the next action one click.

How Clutch Solves It

Clutch connects to GitHub, GitLab, Bitbucket, Jenkins, GitHub Actions, CircleCI, Buildkite, Salesforce, Slack, Confluence, Notion, Jira, AWS, Azure, GCP, HashiCorp Vault, CyberArk, AWS Secrets Manager, Azure Key Vault, Kubernetes, and 100+ other systems through native APIs. The discovery engine scans code repositories (current and historical), CI/CD pipeline configurations and build artifacts, SaaS messaging and documentation, runtime environment variables, Kubernetes secret objects, and Terraform state, producing one unified inventory of every secret it finds, no matter where it lives.

For every detected secret, Clutch builds an Identity Lineage® record. The same leaked AWS access key appearing in a GitHub commit, a CircleCI environment variable, and a Slack thread is one identity with three observed locations, not three separate findings. Identity Lineage® traces the secret from origin (created by which user, in which system, for which workload) through every storage location to every consumer and every reachable resource. The output isn't "we found 12 hits"; it's "we found this credential, it can reach these resources, here's who owns it, here's where it leaked."

Workforce Attribution names the human responsible for every exposed secret. When a GitHub personal access token appears in a CI pipeline, Clutch correlates the PAT's creator from GitHub's audit log with the employee's IdP record in Okta or Entra ID, and assigns the exposure to that owner. When the owner has left the company, the secret is flagged as orphaned and escalated to their former manager. This is how Clutch closes the "no one's coming to deprovision that secret" loop at detection time.

Blast-radius scoring is calculated at the moment of detection. A leaked secret isn't ranked by which file it was found in; it's ranked by the actual resources it can reach in the underlying cloud, SaaS, or vault environment. A ghp_* token with admin access to three private repos and the ability to merge to main is a different severity than a token scoped to read public metadata.

The platform feeds remediation. For each exposed secret, Clutch proposes the next action, revoke, rotate, scope down, or migrate to a short-lived ephemeral identity, and integrates with the systems that execute those actions (Okta, AWS IAM, HashiCorp Vault, GitHub). The Universal NHI MCP Server lets a SOC engineer ask, in natural language, show me every exposed GitHub PAT created in the last 90 days that can reach a production repo, with Identity Lineage® and blast radius attached.

Deployment is agentless. The Zero Knowledge Architecture means secret plaintext never leaves the customer environment; the platform ingests the metadata required to build the graph without exfiltrating the secret material itself.

Practical Examples

An AWS access key in a .env file in a forked repo. A developer forks an internal repo to a personal account during a hackathon and accidentally pushes a .env that contains a long-lived production AWS access key. The key was originally pasted there in 2023 by a different engineer. Clutch detects the key in both the original repo's history and the forked copy, correlates them as the same identity in Identity Lineage®, computes that the key can write to a production data lake, attributes ownership to the original engineer (still employed, on a different team), and surfaces one ticket with both locations and a one-click migration to a short-lived credential.

A GitHub PAT in a CI pipeline log. A failing GitHub Actions workflow prints environment variables to the build log during a debug run. The log contains a PAT with repo and workflow scopes. Clutch detects the leak via the CI integration, identifies the PAT's owner from GitHub's audit data, scores the blast radius (push access to three production repos, including the deploy pipeline), and routes a high-severity ticket, with full Identity Lineage®, before the log is archived.

A Salesforce-issued OAuth token shared in Slack. A contractor pastes a Salesforce OAuth token into a Slack channel while asking for help. The channel is multi-tenant; the token has read access to customer records. Clutch detects the token in Slack, links it to the OAuth grant in Salesforce, computes the blast radius, attributes the exposure to the contractor (now offboarded), and escalates to the Salesforce admin owner identified by Workforce Attribution.

The Bottom Line

Exposed secrets are an identity problem disguised as a string problem. Regex scanners, CI-native tools, and vault-only platforms each see a slice; none correlates the same logical secret across code, CI/CD, SaaS, and runtime. Clutch detects exposed secrets across every surface, links them as identities through Identity Lineage®, attributes each to a human owner via Workforce Attribution, and scores blast radius at detection time. The next CircleCI- or Vercel-style breach will be a credential someone knew was somewhere, but didn't know what it could reach.