NHI Kill Chain: Over-shared Key — One Stripe Key, 14 Repositories, and Nobody Knows Who Owns It
A single Stripe API key was copied to 14 locations over three years. When a QA repo went public, the key was exposed — and revoking it meant breaking 14 services simultaneously.
"If We Revoke This Key, 14 Systems Go Down Simultaneously"
Early 2025. A 200-person B2B SaaS company. Microservices architecture, over 40 repositories, Series B freshly closed. The kind of organization that moves fast, ships constantly, and trusts its engineers to make pragmatic decisions under deadline pressure.
Three years ago, when the payment service was first built, a senior backend engineer — call him P — generated a Stripe live API key. It went into the payment-service repository. One key, one repo, one owner. Clean.
Then time happened.
The QA team needed to run end-to-end payment tests. They copied the key into the e2e-tests repository. A new team built a refund processing service. They copied the key into refund-service. The settlement batch service needed Stripe access. Copied. The mobile app backend needed payment integration. Copied. Someone pinned the key in the #payments Slack channel with the note "test key" — it was the live key. The Confluence page for payment integration included the key as a "working example." Three Jenkins pipelines had it injected as environment variables. Three developers had it in their local .env files.
Three years later, the same Stripe live API key exists in 14 locations. P, the engineer who created it, left the company a year ago. Ask who owns this key and you get silence.
When the security team lead proposed rotating the key, the payments team lead responded with a sentence that captures the entire Over-shared Key problem:
"If we rotate this key, the payment service, the refund service, the settlement batch, and the mobile backend all go down at the same time. I know where maybe 5 of the 14 copies are. I don't know where the other 9 are."
Rotation was postponed indefinitely.
Then the weakest link broke. The QA repository was temporarily set to public for an internal code review convenience. The person who made it public didn't know the repository contained a hardcoded Stripe live key. Automated bots that continuously scan public GitHub repositories found the key within four minutes.
The attacker used the key to access the Stripe API. Customer payment data was queried. Fraudulent refunds were initiated. When the security team detected the anomalous transactions and immediately revoked the key, 13 other systems broke simultaneously. Payments stopped processing. Refunds stopped processing. The settlement batch failed. The mobile app flooded with payment errors.
Finding every location where the key existed took two days. Updating all 14 locations with new, per-service keys took four days. In the intervening period, approximately $50,000 in fraudulent refunds were processed.
Why This Key Is Dangerous
An Over-shared Key is a single credential that has proliferated — through copying, sharing, and hardcoding — across multiple systems. The core danger is not the key itself. It's that nobody knows the complete list of everywhere it exists.
Credentials spread for structural reasons, not because of negligence.
First, development velocity outpaces security processes. When a team needs to ship a new service by the end of the sprint, the choice between provisioning a new key through Secrets Manager — with proper scoping, access policies, and deployment pipeline updates — and copying an existing key into a .env file is not a real choice. One takes an hour. The other takes thirty seconds. Under deadline pressure, the thirty-second option wins almost every time.
Second, every temporary copy becomes permanent. Every instance of credential copying starts with the same assumption: "We'll separate this later." But "later" never arrives. Splitting shared keys into per-service credentials is technical debt that never reaches the top of the backlog. Temporary configurations become permanent infrastructure. Temporary keys become permanent keys.
Third, organizational growth erases institutional memory. The engineer who created the key leaves. The engineer who copied it moves to a different team. The engineer who hardcoded it into the batch service was a contractor whose engagement ended six months ago. Over time, the chain of custody dissolves. What remains is a key that exists in 14 places with no documented owner, no inventory of its locations, and a warning passed down like folklore: "Don't touch that key. Something will break."
The gap between what security leadership believes and what the organization actually practices is consistent.
"We have a key rotation policy." A rotation policy requires knowing where the key is. If you know 3 of 14 locations and rotate, the other 11 break. The policy exists on paper. Execution requires a complete inventory that doesn't exist.
"We use a Secrets Manager." Correct — the original payment-service retrieves the key from Secrets Manager. The other 13 copies are hardcoded. Secrets Manager manages the lifecycle of the original. Copies are outside its scope entirely.
"We told teams to use per-service keys." The instruction was issued. In practice, teams copy the working key because generating a new one, configuring minimum-privilege permissions, and updating deployment pipelines is additional work. Additional work gets skipped when deadlines approach.
GitGuardian's 2025 State of Secrets Sprawl report quantifies this problem. Over 90% of secrets discovered in GitHub repositories were still valid five days after detection. Secrets are found but not revoked — because when a key is spread across multiple systems, revoking it is frightening. "I know this key is exposed, but I don't know what breaks if I kill it" is the sentence that keeps Over-shared Keys alive.
The security posture of an Over-shared Key is defined by the weakest of its 14 locations. Thirteen locations can be perfectly secured. If the fourteenth — a QA repository, a developer's local machine, a pinned Slack message — is compromised, the key is compromised. Attackers don't scale the highest wall. They walk through the lowest gate.
Kill Chain — How an Over-shared Key Becomes an Organizational Incident
The Over-shared Key attack chain has a distinguishing characteristic: the breach occurs at a single location, but the impact — and the response failure — cascades across every location where the key exists. Five stages.
Stage 1: Single Point of Origin. The key is born with a legitimate purpose. Engineer P generates a Stripe live API key for the payment-service. At this point, the key exists in exactly one location, has a clear owner, and poses near-zero risk. This is how every Over-shared Key begins — as a perfectly normal, well-managed credential.
Stage 2: Organic Sprawl. Over time, the key propagates. The QA team copies it for end-to-end testing. Another team copies it for the refund service. Someone shares it in Slack. It gets documented in Confluence. It's injected into CI/CD pipelines. It lands in developers' local .env files. Each copy feels reasonable at the moment it happens. "This key already works. Why generate a new one?" The key moves from 1 location to 14, and no system tracks the proliferation. No alert fires when the same credential appears in a new repository. The sprawl is silent.
Stage 3: Ownership Dissolution. Engineer P — the person who created the key — departs the company. P's HR offboarding is complete, but no system links this particular Stripe key back to P. The key now exists in 14 locations with no identifiable owner. When someone suggests rotation, the response is always the same: "We don't know everywhere that key is used. If we rotate it and miss a location, production breaks." Risk is acknowledged. Action is deferred indefinitely.
Stage 4: Weakest Link Breach. The key leaks from the least-secured location among the 14. A QA repository is accidentally made public. A developer's local .env file is harvested by infostealer malware. A Slack message is exposed through an integration vulnerability. If the key existed in only one location, the attack surface would be one system's security posture. With 14 locations, the attack surface is the security posture of the weakest one. The probability of breach scales not linearly with the number of copies, but to the minimum security level across all copies.
Stage 5: Cascading Response Failure. The security team detects the breach and revokes the key. Immediately, every other system that depends on the same key fails. Payments stop. Refunds stop. The settlement batch crashes. The mobile app throws errors. The organization is now fighting two battles simultaneously: incident response against the attacker, and production recovery against the service outages caused by their own remediation. Finding all 14 locations takes days. Only 5 were documented. The remaining 9 must be discovered through full codebase searches, CI/CD pipeline audits, and Slack channel archaeology. While the team searches, the attacker has already exfiltrated data using the window before revocation.
Why Traditional Security Tools Miss It
The Over-shared Key problem exists in the gaps between tools that were each designed for a different purpose. Each tool does its job well. None of them were built to solve credential sprawl.
Secrets Manager protects the original, not the copies. AWS Secrets Manager, HashiCorp Vault, Azure Key Vault — these tools are designed for secure secret storage and access control. The payment-service retrieves its Stripe key from Vault through a properly authenticated call. But when someone copies that key value and hardcodes it into refund-service/config.yaml, Vault has no way to know. Vault manages the original. Copies are invisible to it.
Secret scanning detects existence, not duplication. GitHub Secret Scanning, GitLeaks, TruffleHog — these tools find secrets in repositories. They report "this repository contains a Stripe key." They do not report "this Stripe key also exists in 13 other locations." Each detection is an independent alert. No tool connects the alerts to show that the same key has been found 14 times across different systems.
IAM and RBAC manage what a key can do, not where it is. The Stripe API key might be properly scoped to payment read/write permissions. But the fact that this same key has been copied to 14 locations is not IAM's concern. IAM governs "what can this key access." It does not track "where does this key physically exist."
Log monitoring sees usage patterns, not copy patterns. Stripe's API logs might show requests from the same key arriving from multiple IP addresses. But determining whether those IPs represent legitimate services or unauthorized access requires knowing where the key is deployed. Without a complete inventory of all 14 locations, the 15th access cannot be classified as an attack.
Manual inventories are outdated the moment they're completed. A team can build a spreadsheet documenting which keys exist in which systems. The next day, a developer copies a key to a new service, and the spreadsheet no longer reflects reality. Manual tracking cannot keep pace with the speed of development.
The fundamental gap is this: existing tools can each tell you "this secret exists in this system," but no tool tells you "this same secret exists in N systems across your organization." Cross-source credential duplicate detection is the missing capability in the existing security stack.
Real-World Breaches and Industry Data
Over-shared Keys are not a theoretical risk category. They are a documented, recurring factor in major security incidents, and industry data quantifies the scale of the problem.
OWASP's NHI Top 10 identifies Secret Sprawl — the uncontrolled proliferation of secrets across systems — as a critical risk in non-human identity security. When a single credential spreads to multiple systems, the attack surface expands, incident response time increases, and blast radius assessment becomes impossible.
CSA's 2026 State of NHI Security report found that only 12% of organizations report high confidence in their ability to prevent NHI-based attacks. When credentials are spreading across systems without tracking, confidence is difficult to justify. You cannot protect a key if you don't know where it is.
The Verizon 2025 Data Breach Investigations Report found that credential exploitation was a factor in approximately 20% of all analyzed breaches. Stolen, leaked, and orphaned credentials remain one of the most consistent and effective intrusion vectors year after year.
The Uber breach of September 2022 is a definitive example of credential chaining — the pattern that Over-shared Keys enable. An attacker used credentials found in internal systems — PowerShell scripts, network shares — to reach Uber's AWS environment, Google Workspace, Slack, and HackerOne. Shared credentials scattered across internal systems created lateral movement paths that the attacker followed from one system to the next. When the same credential exists in multiple places, compromising one gives access to all.
GitGuardian's 2025 State of Secrets Sprawl report documents that secrets routinely exist as duplicates across multiple locations within an organization. Secret sprawl — single keys replicated across dozens of systems — is the norm, not the exception. Over 90% of discovered secrets remain valid more than five days after detection. The reason is straightforward: revoking a shared key causes service outages. "I know this key is a risk, but I can't touch it" becomes a recurring conversation that stretches across months and quarters.
Payment system credential sprawl is particularly consequential. PCI DSS compliance requires strict management of keys that access cardholder data, but in practice, live API keys for Stripe, PayPal, and Adyen routinely appear hardcoded in development and testing environments. Compliance checklists pass. The keys exist in places the checklist doesn't check.
Detection and Response Guide
Detecting and remediating Over-shared Keys requires shifting the fundamental question from "does this system contain a secret?" to "how many systems contain this same secret?"
Build cross-source credential duplicate detection. Move beyond single-system secret scanning. Implement detection that identifies the same secret across multiple sources — GitHub repositories, Slack messages, Confluence documents, CI/CD environment variables, cloud Secrets Managers, developer local environments. When the same key hash appears in three or more locations, classify it as an Over-shared Key.
Enforce per-service key isolation as automated policy. One service, one dedicated key. Enforce this as an automated gate, not a guideline. If a CI/CD pipeline detects the same key used across multiple services, block deployment. Make generating a new key faster and easier than copying an existing one. The path of least resistance must lead to key isolation, not key sharing.
Map blast radius proactively. On a quarterly basis, or whenever credential inventory changes, map the blast radius of every key. "If this key is revoked, which services are affected?" Answer this question before a breach forces you to answer it under pressure. Any key with a blast radius spanning three or more services is an immediate isolation target.
Establish a controlled rotation strategy. When an Over-shared Key is discovered, immediate revocation may be the worst option. Instead, follow this sequence: (1) enumerate every location where the key exists, (2) generate a new, dedicated key for each location, (3) deploy and verify each new key, (4) confirm all locations have transitioned, (5) only then revoke the old key. This is controlled rotation — designed to eliminate the key without causing cascading outages.
During active incidents, accept the blast radius. If the key is being actively exploited, there is no time for controlled rotation. Revoke immediately and handle the resulting service outages in parallel. This is where pre-mapped blast radius data becomes critical — if you already know the key exists in 14 locations, recovery can begin in hours instead of days. Without that map, you start with a full codebase search while the attacker operates.
Monitor for credential copying in real time. When a secret matching an existing tracked key appears in a new source, alert immediately. Sprawl must be caught early. Remediating 2 copies is a fundamentally different problem than remediating 14. Every day without detection is another potential copy.
For detailed implementation guidance, see Secret Detection: Complete Guide for 2026 and Git Secret Scanning: Complete Implementation Guide.
How Cremit Argus Detects Over-shared Keys
The root causes that keep Over-shared Keys alive — inability to track where a key exists, inability to detect duplication across sources, inability to calculate blast radius — are exactly the problems Cremit Argus was built to solve.
Argus performs cross-source credential duplicate detection. GitHub repositories, Slack workspaces, Confluence documents, CI/CD pipelines, cloud environments — Argus correlates secrets discovered across all of these sources to show how many locations contain the same key in real time. When the Stripe key in payment-service and the Stripe key in e2e-tests are the same value, Argus connects them. Where traditional secret scanning tools generate independent alerts for each discovery, Argus surfaces a single fact: "This key exists in 14 locations."
Argus visualizes sprawl maps. For each Over-shared Key, Argus generates a radial diagram showing which systems, repositories, channels, and environments contain the key. A CISO asking "what is the blast radius of this key?" gets an immediate, visual answer. Before rotation begins, the impact scope is clear and the staged transition plan can be built with confidence.
Argus detects new sprawl in real time. When a tracked key's value appears in a new source — a new repository, a new Slack channel, a new CI/CD pipeline — Argus alerts immediately. Catch it at 2 copies, not 14. Secret sprawl compounds over time. Early detection is the difference between a five-minute fix and a four-day organizational incident.
See how Argus identifies and eliminates Over-shared Keys at cremit.io.
NHI Kill Chain Series Overview
This post is the fourth installment in the NHI Kill Chain series. Across nine posts, we analyze the most dangerous types of NHI credentials hiding inside organizations, each representing a distinct — and interconnected — risk.
A key exposed in a public repository, if left unrotated, becomes an Aged Key. A departed employee's key, if never revoked, becomes a Ghost Key. A single key copied across systems becomes an Over-shared Key — and when one copy is compromised, incident response itself becomes the disaster. Understanding how one credential management failure cascades into another risk category is the central purpose of this series.
- Public Key — What Happens 4 Minutes After a .env Hits GitHub
- Ghost Key — The Departed Developer Whose AWS Key Still Clocks In Every Morning
- Aged Key — The Skeleton Key That Held Production Together for 3 Years
- Over-shared Key — One Stripe Key, 14 Repositories, and Nobody Knows Who Owns It (current post)
- Zombie Key — Deleting It from Code Doesn't Mean It's Dead (coming soon)
- Drifted Key — When the CI/CD Bot Auto-Attaches a DB Password to Jira (coming soon)
- Shadow Key — Quietly Hardcoded Right Next to the Secrets Manager (coming soon)
- Unattributed Key — This Key Was Created by... Nobody Knows (coming soon)
- Series Synthesis — The Complete NHI Kill Chain Framework and Unified Response Guide (coming soon)
Previous post: [NHI Kill Chain: Aged Key — The Skeleton Key That Held Production Together for 3 Years](/blog/nhi-kill-chain-aged-key)
Next post: NHI Kill Chain: Zombie Key — Deleting It from Code Doesn't Mean It's Dead
Cremit is an NHI security company. [Learn more at cremit.io](https://argus.cremit.io)