Source code secrets are driving lateral movement and supply chain risk

At a glance

What this is: This is an analysis of how source code repositories, build systems, and open-source workflows expose plaintext secrets that attackers can abuse for access and lateral movement.

Why it matters: It matters because source code security now sits inside IAM, NHI, and supply chain governance, where leaked credentials can outlive the code change that exposed them.

By the numbers:

• 85% of organizations have plaintext secrets embedded in their source code repositories.
• The average cost of a data breach reached $4.88 million in 2024.
• 1,732 data breaches occurred in the first half of 2025.
• Attackers attempt access within an average of 17 minutes when AWS credentials are exposed publicly.

👉 Read Orca Security's analysis of source code secrets and supply chain risk

Context

Source code is now a credentials repository as much as a development asset. When plaintext secrets, API keys, and database connection strings land in Git-based workflows, the exposure window becomes a direct identity problem because attackers do not need to break the application if they can reuse the embedded access.

For IAM and NHI programmes, the real issue is not just code hygiene. Repository exposure turns developer workflow mistakes into privileged access events, which means source control governance, secrets rotation, and access review discipline all need to be treated as one control plane.

Key questions

Q: How should security teams handle secrets found in source code repositories?

A: They should treat the finding as an access incident, not a housekeeping task. The right response is to revoke or rotate the exposed credential, check all systems that may have accepted it, and scan the full repository history, build artefacts, and forks for copies. Secrets in code create reusable identity material, so remediation must focus on access removal, not just file cleanup.

Q: Why do plaintext secrets in repositories create such a large security risk?

A: Because they collapse the distance between code access and production access. A single committed secret can unlock cloud consoles, APIs, or internal services, and attackers often move faster than teams can remediate. Source code exposure therefore becomes an identity event with a potentially wide blast radius, especially when the same secret is reused across environments.

Q: What do organisations get wrong about source code security?

A: They often treat it as a developer practice problem rather than a governance problem. That misses the fact that repositories can contain live credentials, and those credentials may remain valid long after the code changes. Effective control requires secrets discovery, ownership, revocation discipline, and environment separation, not just secure coding guidance.

Q: How can teams reduce the blast radius of a leaked repository secret?

A: They should scope credentials to one environment, one service, and the shortest practical lifetime, then rotate them automatically. They also need branch protection, commit signing, and secret scanning so the same exposure pattern is less likely to recur. Blast-radius reduction only works when secret lifecycle and source control governance are managed together.

Technical breakdown

Plaintext secrets in repositories create reusable identity material

Source code repositories often contain credentials because developers embed secrets for convenience, testing, or automation. Once committed, those values are durable, searchable, and easy to harvest at scale. A leaked API key, token, or service account credential is not just data exposure. It is an identity event because the secret can be replayed against cloud services, CI/CD systems, and internal APIs. The danger increases when the same secret is copied into forks, build logs, or mirrored repositories, which makes cleanup incomplete even after the original file is removed.

Practical implication: treat source control as an identity exposure surface and scan every branch, fork, and build artefact for secrets.

Supply chain compromise turns trusted tooling into an access path

Build platforms and package ecosystems extend the attack surface beyond the repository itself. When an attacker compromises a trusted developer tool or dependency, they can harvest secrets from pipelines, impersonate maintainers, or pivot into downstream accounts that trust the package. This is why supply chain attacks matter to identity teams. They convert software trust into credential trust. Source code management posture therefore needs branch protection, commit signing, dependency verification, and repository-level policy enforcement, not just malware detection.

Practical implication: require signing, verification, and policy controls around development tooling before secrets in code become account compromise.

Secrets rotation matters because exposure is often already silent

Secrets management only works if exposed credentials are discovered and replaced faster than attackers can use them. Static credentials are especially dangerous because they have no natural expiry and often remain valid long after the developer who used them has moved on. In practice, this creates hidden standing privilege inside code. Automated rotation, repository scanning, and environment separation reduce the blast radius, but the core problem is governance drift between secret creation, storage, and revocation.

Practical implication: enforce automated rotation and rapid revocation for any credential that may have been committed to source control.

Threat narrative

Attacker objective: The attacker wants reusable credentials that convert source code exposure into cloud access, lateral movement, and downstream data theft.

1. Entry occurs when attackers obtain source code access through exposed repositories or compromised development tooling, giving them a low-friction path to harvest embedded secrets.
2. Escalation follows when stolen API keys, cloud credentials, or service account tokens are replayed against production systems, allowing the attacker to move from code access to privileged access.
3. Impact lands when the compromised credentials enable data exfiltration, account creation inside victim environments, or lateral movement into cloud and SaaS services.

Breaches seen in the wild

• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

Source code secrecy is now identity governance, not just application security. Once plaintext secrets live in repositories, the control problem shifts from code review to credential lifecycle. That means source code security has to be governed like NHI security because the object being stolen is access, not merely information. Practitioners should treat every repository as a potential identity inventory.

Secret sprawl creates an identity blast radius that developers cannot see. The repository may expose one token, but the real impact is the set of systems that token can reach, including cloud control planes, CI/CD systems, and production APIs. This is why source code compromise often produces disproportionate downstream damage. Security teams need to map where each credential can be used, not just where it was found.

Standing privilege in code is the failure mode the article exposes most clearly. Static secrets in source repositories are durable access grants that outlive the development event that created them. That is a governance failure because access persists outside of any review, ownership, or offboarding process. The implication is that source control programmes must be managed with the same lifecycle discipline used for privileged accounts.

Commit signing and branch protection are identity controls in disguise. They are often discussed as software engineering hygiene, but in practice they are trust controls for who can alter the provenance of code and dependencies. When attacker behaviour targets build pipelines and maintained packages, provenance matters as much as content. Practitioners should align SCM posture with PAM and supply chain assurance.

Secret sprawl challenge: fragmented storage, long-lived credentials, and incomplete revocation create a trust gap that attackers exploit after repository exposure. The article shows that the problem is not one secret in one file but repeated secret placement across tools and environments. That pattern turns every leak into a multi-system access event. Security teams should therefore measure exposure by reachable systems, not by the count of committed secrets alone.

From our research:

• DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• Our research also shows that when AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• For deeper context, see Guide to the Secret Sprawl Challenge for how secret sprawl turns repository exposure into repeatable access risk.

What this signals

Source code security is becoming a programme-level issue because it now intersects with secrets management, CI/CD governance, and cloud identity. With secret sprawl creating multiple places where credentials can persist, teams need to measure whether discovery, revocation, and ownership are actually aligned across engineering and IAM.

Secret sprawl challenge: when credentials are duplicated across repositories, build systems, and environments, revocation becomes inconsistent and the same leak can remain exploitable in several places at once. That is why source code controls need to be connected to lifecycle governance, not treated as a separate engineering workflow.

For practitioners, the signal to watch is whether secret findings can be tied to a named owner, a clear system of record, and a tested revocation path. Where that chain is missing, the repository is functioning as an unmanaged NHI distribution point rather than a secure development asset.

For practitioners

• Scan every repository and pipeline for committed secrets Run continuous secret discovery across source control, pull requests, build logs, forks, and artefacts so exposed credentials are found before attackers use them.
• Rotate credentials immediately after any exposure event Replace API keys, database credentials, and service account tokens as soon as a leak is suspected, then verify that old values no longer authenticate anywhere.
• Separate credentials by environment and use short-lived access where possible Keep development, staging, and production credentials distinct so a single repository leak does not provide direct access to all environments.
• Harden source control with provenance controls Require branch protection, commit signing, and dependency verification for repositories that can influence builds, releases, or secret-bearing configuration.

Key takeaways

• Source code repositories are now a credential exposure surface, which makes this an IAM and NHI governance problem as much as a development problem.
• The scale of the issue is large, with Oraca Security citing 85% of organisations embedding plaintext secrets in source repositories and breach costs continuing to rise.
• Teams should combine secret scanning, rapid rotation, environment separation, and provenance controls so exposed code cannot translate into reusable access.

Key terms

• Secret Sprawl: Secret sprawl is the uncontrolled spread of credentials, tokens, and keys across code, pipelines, repositories, and environments. It creates hidden copies that are hard to track and harder to revoke, which means one leak can remain active in multiple places long after the original issue is found.
• Source Control Posture Management: Source control posture management is the discipline of governing repository security settings, access, provenance, and policy enforcement across the software lifecycle. It extends beyond developer workflow hygiene by treating source control as a security control plane that can expose identities, credentials, and trust relationships.
• Identity Blast Radius: Identity blast radius is the set of systems, accounts, and services that can be reached if a credential or token is compromised. In source code incidents, it measures how far a leaked secret can travel before detection, containment, and revocation reduce the damage.
• Standing Privilege: Standing privilege is access that remains valid until someone removes it, rather than access that expires automatically. In repository and secret management contexts, it is dangerous because a committed credential can keep working silently, even when no current business need justifies its existence.

Deepen your knowledge

NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by Orca Security: source code security and supply chain risk analysis. Read the original.