Exposed .git repositories keep leaking live AWS, Stripe and GitHub keys

At a glance

What this is: This research shows that exposed .git repositories still leak active credentials at scale, with repository history often revealing secrets that are no longer visible in the latest code state.

Why it matters: It matters to IAM, PAM, and NHI teams because source-controlled secrets, service credentials, and personal access tokens can outlive normal review cycles and create direct access to cloud, code, and payment systems.

By the numbers:

• The scan uncovered 400 AWS access keys, 107 Stripe API keys, 123 OpenAI API keys, 80 Telegram tokens, and 17 GitHub personal access tokens.

👉 Read Intruder's research on exposed .git repositories and live credential leakage

Context

Exposed .git repositories are a security governance failure because they turn ordinary code storage into a credential leak path. The core problem is not just whether the latest branch looks clean, but whether historical commits, reflogs, and packed objects still contain live secrets that can be recovered without authentication.

For identity teams, this is an NHI issue as much as a source control issue. API keys, cloud access keys, secret tokens, and GitHub personal access tokens are machine identities or privileged authenticators in practice, and they often bypass the review and lifecycle controls applied to human accounts. The article’s findings are consistent with a widespread misalignment between developer workflow and identity governance.

The starting position here is not unusual. Many organisations still treat repository exposure as a narrow code hygiene problem, when it is actually a persistent access-control and secrets lifecycle problem.

Key questions

Q: What breaks when secrets are spread across multiple repositories and tools?

A: When secrets sprawl across repositories and toolchains, organisations lose the ability to find, classify, and revoke them quickly. Response slows, ownership becomes unclear, and different copies may survive even after one credential is rotated. That creates avoidable exposure and makes incident response far harder than it should be.

Q: Why do exposed repository secrets create a broader IAM problem than a simple code leak?

A: Because many repository secrets are live access paths into cloud, CI/CD, and vendor systems. A single leaked key can grant write access, runner control, or deployment visibility across multiple services. That turns a source-control incident into an identity governance event, with blast radius determined by privilege scope rather than repository size.

Q: How do security teams know if their repo-scanning controls are actually working?

A: Look for two signals: untrusted repositories are always cloned into a temporary workspace, and no scanner path shells out to Git on copied inputs. If either condition is missing, the control is incomplete. A working program makes repository provenance visible before execution and separates inspection from attacker-controlled metadata.

Q: Who is accountable when a compromised action leaks repository secrets?

A: Accountability usually spans platform engineering, application owners, and identity governance, because the failure crosses code integrity, workflow design, and credential lifecycle. The right question is not who owns the incident alone, but which team owns action trust, which team owns the secret, and which team owns the downstream access it enabled.

Technical breakdown

Why .git exposure leaks more than current source files

A Git repository is a content-addressed object database, not just a folder of files. Commits point to trees, and trees point to blobs, so a secret removed from the latest file can still remain in older commits, reflogs, or unreachable history. That is why a scan that checks only the current HEAD state misses a large class of exposures. At scale, full reconstruction of every repository is costly, which is why memory-only traversal is more practical for broad internet scanning.

Practical implication: scan repository history, not just current files, and treat historic commit access as part of secrets discovery.

Why exposed secrets become active identity risk

An AWS key, Stripe secret, or GitHub PAT is not just a string in a file. It is an authenticator that can grant cloud access, payment actions, or source code access depending on its scope. Once exposed, the key’s security depends on whether it is still valid, how much privilege it carries, and whether the surrounding platform can detect abuse. This is where NHI governance overlaps with application security: a secret in code is a credential lifecycle failure, not only a development mistake.

Practical implication: inventory exposed credentials by privilege level and revoke or rotate them as identity assets, not as code defects.

How attackers chain repository exposure into real impact

Publicly exposed repository material gives attackers both entry points and context. They can use hardcoded credentials for direct access, but they can also use repository content to identify systems, naming patterns, and operational dependencies for later social engineering or lateral movement. If commit history includes previously deleted secrets, attackers gain a wider recovery surface than the development team may realise. That makes secret discovery, validity checking, and rapid revocation central to reducing blast radius.

Practical implication: combine repo scanning with validation, revocation, and targeted monitoring for the systems those secrets can reach.

Threat narrative

Attacker objective: The attacker wants to turn repository exposure into authenticated access to live production systems, then use that access for theft, manipulation, or downstream compromise.

1. Entry occurs when attackers find public .git repositories or exposed historical objects that contain active secrets, keys, or tokens.
2. Escalation follows when those credentials are valid and grant access to cloud, payment, or source control systems with meaningful privilege.
3. Impact comes from unauthorized access, data exposure, fraudulent transactions, or code tampering depending on the secret’s scope.

Breaches seen in the wild

• Emerald Whale breach — exposed Git config files led to 15K secrets stolen and 10K repo compromises.
• Millions of Misconfigured Git Servers Leaking Secrets — Nearly 5 million misconfigured Git servers expose sensitive secrets and credentials online.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Secret history is the real attack surface: the risk is not limited to what a repository exposes today, but to everything its history still reveals. That matters because many scanning and review processes still focus on current-state files rather than commit graphs, reflogs, and recovered objects. In identity terms, the credential lifecycle is longer than the visible code lifecycle, and that mismatch is where exposure persists. Practitioners should treat repository history as a governed secrets store and not as archival noise.

Hardcoded credentials are now NHI assets with blast radius: when a repository leaks an access key or PAT, the issue is not the file format, it is the privilege carried by the credential. These secrets function as non-human identities with authentication power, but they rarely receive the same ownership, expiry discipline, or revocation urgency as user accounts. The control gap is lifecycle ownership, not just developer awareness. Teams need a clear inventory of which services each secret can reach and who is accountable for immediate revocation.

Repository exposure creates an access-control problem, not just a detection problem: secret scanners can find tokens, but only governance can ensure they stop working quickly enough to matter. This is where OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 become relevant, especially around authenticator management and access enforcement. The most durable reduction in risk comes from pairing discovery with short-lived credentials, scoped permissions, and revocation workflows that do not depend on manual ticket handling.

Dynamic secrets are becoming the practical baseline: long-lived tokens in source-controlled workflows are increasingly out of step with how attackers operate. Exposed credentials are often usable within minutes of disclosure, which compresses the response window well below many organisations’ current rotation and review cycles. That makes ephemeral access, workload identity, and stronger secrets hygiene a governance requirement rather than an optimisation. Practitioners should assume that any static secret committed once may be recovered many times.

Repository scanning should be integrated into identity governance operations: the signal here is that source control exposure belongs in the same operational conversation as IAM, PAM, and NHI management. The organisations that fare better are the ones that can map a secret back to an owner, a workload, and a revocation path without delay. That is the difference between finding a leak and actually controlling it.

From our research:

• 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to 2024 Non-Human Identity Security Report.
• Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities.
• From our research: The 2024 Non-Human Identity Security Report also found that 35.6% of organisations cite managing consistent access across hybrid and multi-cloud environments as their top NHI security challenge, according to 2024 Non-Human Identity Security Report.

What this signals

Credential sprawl is becoming a governance problem, not a point-in-time leak problem: the operational failure is not just that secrets appear in repositories, but that they remain live long enough to be reused. That is why a programme should align repository scanning with secrets ownership, revocation automation, and service-account inventory. For identity teams, this is the same control pattern that applies to NHI lifecycle management: discover, bind to an owner, expire quickly, and prove revocation.

Secret history is the hidden boundary most teams still underprotect: Git history, reflogs, and packed objects create a persistence layer that many scanning programmes ignore. A mature programme needs to treat historical repository content as part of the attack surface and connect it to the broader control set in the OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5. The practical outcome is fewer dormant secrets, faster triage, and better evidence for audit and incident response.

Blastradius control is now the deciding variable: when exposed credentials can be used within minutes, the question is not whether leaks happen, but how quickly their reach is reduced. That means pairing static-secret reduction with workload identity, short-lived credentials, and a tighter response loop around any repository exposure. Teams that can shorten validity windows will lower the chance that discovery becomes compromise.

For practitioners

• Scan commit history, not just HEAD Use repository inspection that traverses historical commits, reflogs, and packed objects so deleted secrets remain detectable. Treat any repository with public exposure as compromised until the full history has been checked.
• Classify exposed credentials by reachable system Map each leaked key or token to the cloud account, code repository, payment system, or API it can access, then prioritise revocation by blast radius. A low-value token can still become a pivot if it has broad write scope.
• Automate revocation and rotation workflows Link secret discovery to owned runbooks that revoke or rotate credentials immediately, including service ownership lookup and confirmation that replacement credentials are deployed. Manual ticket queues are too slow for internet-exposed secrets.
• Separate human and non-human credential governance Track service accounts, API keys, and personal access tokens as governed identity assets with lifecycle owners, expiry expectations, and access reviews. Do not rely on developer memory to retire secrets that remain valid after code removal.
• Reduce future exposure at the source Block secret commits with pre-commit and CI checks, then replace static secrets with short-lived credentials or workload identity where possible. That lowers the chance that source control becomes a durable authentication store.

Key takeaways

• Exposed .git repositories remain a live identity risk because repository history can preserve secrets long after they disappear from current code.
• The scale matters because hundreds of AWS, Stripe, and GitHub credentials were recoverable from a scan of 3.5 million active hosts.
• The most effective control is not only detection but rapid revocation, short-lived credentials, and governance that treats secrets as managed identities.

Key terms

• Repository History Exposure: Repository history exposure is the situation where secrets, code, or configuration remain recoverable in past commits, reflogs, or packed Git objects after being removed from the current branch. It matters because deletion in the working tree does not equal revocation of access or removal from attack surface.
• Non-Human Credential: A non-human credential is a secret used by software, automation, or an AI agent to authenticate or act on a system’s behalf. Examples include API keys, tokens, certificates, and service account secrets. These credentials need lifecycle governance because they often persist beyond the human task that created them.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials — API keys, tokens, passwords, certificates — across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.

What's in the full report

Intruder's full research covers the operational detail this post intentionally leaves for the source:

• The repository-walking approach used to inspect commit history in memory at internet scale.
• The exact detection logic for false positives, including entropy checks, placeholders, and runtime-value filtering.
• The patterns behind AWS, Stripe, OpenAI, Telegram, and GitHub credential exposure across real repositories.
• The disclosure and remediation process used after sensitive exposures were identified.

👉 The full Intruder article covers the scanning method, extracted secret types, and remediation examples in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle controls. It helps practitioners align credential governance with the operational realities of modern development and cloud environments.