Why do plaintext secrets keep showing up in code repositories?

Why This Matters for Security Teams

Plaintext secrets keep reappearing in repositories because the underlying problem is not just developer carelessness, but weak governance over how credentials are created, shared, reviewed, and revoked. Once a secret is committed, it becomes durable access material that can be copied into forks, build logs, tickets, and agent workflows. NHI Management Group’s The State of Secrets in AppSec notes that the average time to remediate a leaked secret is 27 days, which is long enough for abuse to move well beyond the original commit.

That delay matters because modern development environments amplify exposure: repositories are only one leak path, and AI-assisted tooling can reproduce sensitive patterns faster than traditional review catches them. Guidance from the OWASP Non-Human Identity Top 10 aligns with what practitioners are seeing in the field, where secrets are increasingly treated as embedded infrastructure rather than temporary mistakes. In practice, many security teams encounter the real blast radius only after a token has already been reused elsewhere, rather than through intentional secret lifecycle control.

How It Works in Practice

The practical fix starts with treating secrets as governed NHI assets, not development conveniences. A repository scan can tell a team that something is exposed, but it does not remove the access path. Effective programs combine detection, ownership, and automatic revocation so the exposed credential cannot survive long enough to be reused. That is why current guidance from the Guide to the Secret Sprawl Challenge emphasizes central visibility across code, CI/CD, chat, and documentation systems.

Operationally, this usually means four controls working together:

• Prevent hardcoding by injecting short-lived secrets from a trusted broker at runtime.
• Scan commits, pull requests, and CI artifacts before merge, then again after deploy.
• Assign an owner to every credential so alerting leads to action, not triage drift.
• Revoke and rotate immediately when exposure is confirmed, with TTLs short enough to limit reuse.

For agentic and automation-heavy environments, this becomes even more important because toolchains may copy secrets into prompts, logs, caches, or generated code. The CI/CD pipeline exploitation case study shows why pipeline runners, not just developer laptops, must be treated as high-risk secret holders. Where organisations rely on long-lived static tokens in ephemeral build systems, this guidance breaks down because the credential outlives the job that needed it.

Common Variations and Edge Cases

Tighter secret controls often increase developer friction, requiring organisations to balance speed against the cost of repeated exception handling. That tradeoff is most visible in legacy applications, small teams without platform support, and fast-moving AI projects where secrets are embedded in notebooks, prompts, or configuration files. Best practice is evolving, and there is no universal standard for how aggressively every environment should block commits versus alert and remediate.

One common edge case is the “private repo is safe” assumption. NHI Management Group research shows internal repositories can still be high-risk because exposure often happens through forks, inherited permissions, CI logs, or copied artifacts rather than public visibility alone. Another issue is that detection-only programs create a false sense of control when revoked access is not enforced automatically. The Shai Hulud npm malware campaign is a reminder that once a secret leaves the repo, downstream abuse can spread through package workflows and related automation.

Where AI tooling is involved, review policies need extra care because models and assistants can echo patterns from codebases. That makes prevention, redaction, and ephemeral credentials more reliable than relying on human memory alone. Security teams should assume that any plaintext secret in a repository will eventually be copied beyond the repository boundary.

Related resources from NHI Mgmt Group

• Why do collaboration tools create such a large secrets risk?
• Why do leaked secrets remain such a persistent NHI risk?
• What makes idle secrets such a serious NHI risk?
• What should security teams do about secrets hidden in SharePoint?