Source code secrets are driving lateral movement and supply chain risk

At a glance

What this is: This is an analysis of how plaintext secrets in source code repositories create a direct path to credential theft, lateral movement, and supply chain exposure.

Why it matters: It matters because IAM, PAM, and NHI teams have to govern code, pipelines, and repository access as one credential plane instead of treating source control as a developer-only concern.

Context

Source code repositories become a governance problem when they contain reusable credentials, not just code. In cloud-based development workflows, the repository can hold API keys, database credentials, service account tokens, and other secrets that extend far beyond the codebase itself.

The security gap is lifecycle control. Once secrets are embedded in code, exposed through a breached repository, or inherited by downstream packages and tools, traditional perimeter controls no longer contain the blast radius. That makes source code security part of identity and secrets governance across the software supply chain.

Key questions

Q: What breaks when secrets are committed to source control?

A: The main failure is that a credential becomes reusable outside the developer workflow and can authenticate directly to cloud storage, APIs, or SaaS integrations. Once a secret is exposed in source control, attackers often bypass the application entirely and use the identity the secret represents. That is why repository leakage is an identity governance issue, not just a coding mistake.

Q: Why does source code exposure increase lateral movement risk?

A: Source code exposure increases lateral movement risk because repositories often contain credentials that authenticate to cloud services, CI systems, databases, and package registries. Once attackers recover those secrets, they can move from the code layer into adjacent systems using valid access rather than noisy exploitation. The risk is amplified when the same credentials are reused across environments.

Q: How do identity teams know whether secrets governance is actually working?

A: Identity teams know secrets governance is working when they can prove that every active secret has an owner, an approved scope, and a tested revocation path. If they cannot quickly identify where a secret is used or remove it without breaking the workload, governance is still incomplete.

Q: What should teams do when a secret is compromised outside a code repository?

A: Teams should rotate the compromised key immediately, then trace where it was shared and used so related systems can be contained. They should also review adjacent tools and accounts for secondary exposure, because one leaked secret often reveals a wider trust path. Fast containment matters because remediation is resource intensive and affects engineering as well as security.

Technical breakdown

Why plaintext secrets in source code create credential reuse risk

Plaintext secrets are dangerous because they collapse the distinction between code and credential. A repository is supposed to store source, not reusable authentication material, but once keys or tokens are committed, every clone, build, backup, or downstream dependency becomes a potential exposure point. The risk is amplified in collaborative and cloud-based development because more systems and people can access the same artefact. From an identity perspective, the problem is not just leakage but persistence: a secret may remain valid long after it has spread across repositories, pipelines, and logs.

Practical implication: treat any secret that reaches source control as exposed and revoke it as part of credential lifecycle management.

How repository compromise turns into lateral movement

A compromised repository often provides more than read access to code. Secrets stored alongside the code can unlock cloud consoles, CI/CD systems, package registries, and application back ends, creating a shortcut from source access to broader enterprise access. That is why source code compromise frequently becomes lateral movement rather than a single isolated incident. The attacker’s value is not the code itself but the identity material embedded in it, which can be reused to authenticate elsewhere with legitimate-looking access patterns.

Practical implication: map repository access to downstream systems that trust the same credentials and remove shared trust paths.

Why software supply chain exposure magnifies the blast radius

Supply chain exposure changes source code risk from local to systemic. If a build tool, package, or dependency is compromised, secrets can be harvested from developer environments, build logs, and published artefacts across many organisations at once. That is why the source code problem sits inside a broader trust model: teams are not only protecting their own repositories, they are also depending on third-party tools and packages that may handle credentials during build and release. Once those trust points fail, the impact scales quickly across the ecosystem.

Practical implication: extend secrets governance into build tooling, dependency controls, and third-party package assurance.

Threat narrative

Attacker objective: The objective is to turn source code access into broader authenticated access that enables data theft, environment takeover, or downstream compromise.

1. Entry occurs when attackers gain access to a repository, package, or build path that contains embedded credentials or secret-handling workflows.
2. Credential access follows when plaintext secrets, tokens, or API keys are extracted from source, logs, or compromised developer tooling.
3. Escalation occurs when those credentials are reused to access cloud accounts, CI systems, or other internal services beyond the original repository.
4. Impact follows through lateral movement, data theft, or supply chain abuse that uses the compromised identities to reach more environments.

Breaches seen in the wild

• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
• PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Source code secrets are now an identity security problem, not a developer mistake. The article is right to frame plaintext secrets as a governance failure because the asset being exposed is not code in the abstract but reusable authentication material. Once secrets live in repositories, the organisation has already lost control of their lifecycle. Practitioners should treat source control as part of the credential estate, not a separate engineering domain.

Repository access often becomes a hidden privilege pathway. When source code contains API keys, service tokens, or database credentials, repository compromise can unlock systems that were never meant to be reachable from the code layer. That changes repository hardening from a software hygiene issue into a privilege containment problem. Security teams need to think in terms of trust inheritance across build, deploy, and runtime boundaries.

Secret sprawl in code creates blast radius that outlives the original exposure. The article’s emphasis on lateral movement is important because a leaked secret is not a single event, it is a reusable identity fragment that may remain active across multiple environments. That is why static credentials in source code are governance debt, not just technical debt. The practical conclusion is that exposure should be assumed to persist until revocation proves otherwise.

Supply chain attacks turn local secret mistakes into ecosystem-wide risk. The s1ngularity case illustrates how a compromise in a trusted development tool can expose secrets at scale and then reuse them across victim environments. This is the point where source code security and third-party trust management converge. Practitioners should re-evaluate how much of their credential estate is implicitly trusted by external tools and packages.

Ephemeral development access does not fix embedded secrets. Temporary access controls help, but they do not address the deeper assumption that credentials remain safe if the surrounding access is short-lived. Once the secret itself is committed to code, the problem survives the session, the user, and the repository event. The governance task is to stop treating code as a safe place to store live identity material.

From our research library:

• Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, according to the State of Secrets Sprawl 2026.
• Read next: Secrets Management Guide

What this signals

Ephemeral repository access does not eliminate secret risk: the control failure sits in credential persistence, not just in who can view the code. Once a live secret is embedded in a repository, the exposure window survives review cycles, branch protection, and most developer workflow guardrails.

Source code governance has to be read as part of identity governance because the same credential can appear in code, CI logs, package artefacts, and cloud access paths. That makes secrets management a lifecycle discipline, not a one-off scanning exercise.

For practitioners

• Implement secret scanning in repositories and pipelines Scan source, commits, pull requests, and build logs for API keys, tokens, certificates, and database credentials, then block merges when live secrets are detected.
• Rotate exposed credentials as a mandatory response Treat any secret found in source code as compromised and revoke or rotate it before the credential can be reused in downstream systems.
• Separate credentials by environment and workload Use different secrets for development, staging, and production so a repository leak does not automatically expand into full production access.
• Tighten repository and branch protections Require pull request review, status checks, commit signing, and least-privilege access so repository compromise is harder to convert into supply chain abuse.
• Inventory third-party build and package trust paths Identify which tools, packages, and automation accounts can read or surface secrets during build and release, then scope their access to the minimum needed.

Key takeaways

• Plaintext secrets in source code create a reusable identity exposure that repository controls alone do not contain.
• The breach pattern matters because stolen code secrets can convert into cloud access, lateral movement, and supply chain abuse.
• The limiting control is lifecycle discipline: detect secrets early, revoke them immediately, and separate credentials by environment and workload.

Key terms

• Secrets Leakage: Secrets leakage is the exposure of credentials such as API keys, tokens, or certificates in places where they can be discovered and reused. The risk is not just disclosure, but unauthorized authentication that turns a coding or pipeline mistake into active access.
• Credential Reuse: Credential reuse happens when the same password, token, or secret can unlock multiple systems or sessions. It increases breach impact because one stolen credential can become a wide-ranging access path. The control problem is not only theft, but the amount of trust packed into each reusable secret.
• Supply Chain Exposure: Supply chain exposure is the risk that a weakness in a connected supplier, partner, component, or service can affect your own environment. It includes compromised software, third-party access, shared credentials, and dependencies that expand attack paths. In identity security, exposure often appears through trusted integrations, unmanaged accounts, and inherited privileges.
• Lateral Movement: A post-compromise technique where an attacker uses a compromised NHI to move through a network, accessing additional systems and escalating impact without triggering detection.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.