Development stage secrets security: the governance gap teams miss

At a glance

What this is: This is an analysis of development-stage secrets security and the control gaps that let hard-coded and reused secrets persist in modern delivery pipelines.

Why it matters: It matters because IAM, NHI, and DevSecOps teams need consistent secrets governance across source code, pipelines, vaults, and access reviews before exposure becomes a breach.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Entro Security's analysis of development stage secrets security best practices

Context

Development stage secrets security is the practice of keeping API keys, tokens, passwords, and certificates out of places where they can be copied, leaked, or reused without control. In modern delivery pipelines, that means the security model has to cover source code, CI/CD, cloud-native tooling, and the handoff between developers and operations teams.

The problem is not just secret exposure. It is the governance gap between how fast software moves and how slowly many organisations can discover, classify, rotate, and revoke secrets once they are embedded in code or spread across environments.

For IAM and NHI teams, this is a lifecycle issue as much as a technical one. Secrets that are created quickly and forgotten just as quickly create long-lived access paths that outlive the release they were meant to support.

Key questions

Q: How should security teams prevent hard-coded secrets from becoming production access paths?

A: Teams should block secret commits, scan repositories and build logs continuously, and treat every found credential as a revocation event. The goal is not only to detect exposure but to remove the credential from every place it can still authenticate, including CI/CD jobs, caches, and downstream services.

Q: Why do development-stage secrets become a bigger risk in CI/CD pipelines?

A: CI/CD pipelines concentrate privilege in automated jobs that move quickly between environments. If the same secret is reused in multiple stages, one leak can reach production controls, artifact stores, or cloud APIs, which turns a local mistake into a broader identity exposure problem.

Q: What do teams get wrong about secret rotation in software delivery?

A: They often treat rotation as an occasional cleanup task instead of a live control tied to ownership, logging, and dependency mapping. If the team cannot see where the secret is used, rotation can break services or be delayed until after exposure has already been exploited.

Q: How should organisations respond when a development secret is exposed?

A: They should revoke the credential first, trace every system that used it, and verify whether the secret was reused across environments. The response must also include repository history, pipeline logs, and any service accounts or tokens that were chained to the exposed secret.

Technical breakdown

Hard-coded secrets and source control exposure

Hard-coded secrets become dangerous because source code is both collaborative and durable. Once a secret lands in a repository, it can be copied through forks, logs, caches, build artifacts, and developer machines long before anyone notices. Rotation then becomes awkward because the team must find every place that secret was propagated and every workload that still depends on it. The key failure is not only disclosure, but identity persistence after disclosure.

Practical implication: block secret commits at the edge, scan repositories continuously, and treat source control as an exposure surface, not a safe temporary store.

CI/CD pipeline secrets and blast radius

CI/CD pipelines increase speed, but they also concentrate privilege. Build jobs, runners, deployment tokens, and environment variables often hold credentials that can reach production systems, artifact stores, and cloud control planes. If those secrets are reused across stages or environments, a single leak can move from a developer tool into infrastructure access. Centralised secrets visibility matters here because a team cannot govern what it cannot inventory. The architectural issue is privilege reuse across automated steps that are assumed to be separate.

Practical implication: segment pipeline credentials by stage and environment, and review every CI/CD secret for the narrowest possible runtime scope.

Secret rotation, audits, and developer workflow

Secret rotation fails when it is treated as an occasional remediation task instead of a live control. Developers need to create, test, and replace credentials without waiting for manual approvals that delay release work, but they also need audit trails that show who changed what and when. Compliance depends on traceability, yet traceability collapses when secrets are scattered across vaults, code, and ad hoc scripts. The technical challenge is making rotation and auditing operationally normal rather than exceptional.

Practical implication: define rotation ownership, automate expiry where possible, and align audit logging with the systems that actually issue and consume secrets.

Threat narrative

Attacker objective: The attacker’s objective is to turn a leaked development secret into durable access that can be reused against production or adjacent systems.

1. Entry occurs when a secret is hard-coded into source code or published into a repository, exposing a valid credential to anyone who can read the code or its history.
2. Escalation follows when the exposed secret is reused across environments or tied to broader privileges, allowing an attacker to move from a leaked token to broader system access.
3. Impact emerges when the credential grants access long enough to exfiltrate data, alter systems, or remain undetected until the secret is finally rotated or revoked.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• 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

Hard-coded secrets are a lifecycle failure, not just a coding mistake. A secret that enters source control stops behaving like a short-lived credential and starts behaving like embedded access history. That creates a governance problem for NHI programmes because the credential now lives in code, builds, backups, and memory caches. The practitioner conclusion is that secret creation, storage, and revocation must be treated as one lifecycle, not three separate tasks.

Identity blast radius: development teams rarely know how far one leaked secret can travel. A single token may touch repositories, CI/CD runners, cloud APIs, and downstream service accounts before anyone detects the leak. That hidden spread is why secrets management must be governed as access architecture, not just vault administration. The practitioner conclusion is to map every credential to its runtime reach before assuming it is isolated.

Shift-left security is incomplete when it stops at detection. Catching secrets early is useful, but development environments still create pressure to reuse credentials, skip rotation, and keep deployments moving. The result is a control environment that can detect exposure yet still leave standing access in place. The practitioner conclusion is that governance must follow the secret after discovery, not stop at alerting.

Centralisation without lifecycle control does not solve secrets sprawl. A single inventory view helps, but it does not by itself answer who owns the secret, which workloads depend on it, or when it should die. Secrets management becomes credible only when ownership, rotation, and offboarding are tied to the same control record. The practitioner conclusion is that inventory is a starting point, not a governance outcome.

Developer convenience and IAM assurance are now competing design constraints. Development-stage secrets security only works when security controls fit the delivery path instead of fighting it. If controls are too slow, teams route around them; if they are too loose, credentials spread faster than governance can catch up. The practitioner conclusion is to design for usable control, not aspirational policy.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• Use Guide to the Secret Sprawl Challenge to trace how secret sprawl turns discovery into an offboarding and rotation problem.

What this signals

Identity blast radius is the right way to think about development-stage secrets now. A credential is no longer just a key in a vault or a line in code, it is a movable access path whose reach depends on how it is copied through pipelines, logs, and deployment workflows.

When teams are already facing a 27-day average remediation window for leaked secrets, the practical constraint is not detection alone but coordination across engineering and identity operations. That is why a linked control view matters more than isolated repo scanning.

The next maturity step is to make secret ownership, rotation, and offboarding visible in the same operational record. Teams that rely on separate tooling for code, pipelines, and access management will keep discovering exposure after the credential has already spread.

For practitioners

• Map every secret to an owner and expiry state Create a system of record that ties each credential to a business owner, technical owner, consumer workload, and rotation date. Without ownership and expiry state, you cannot prove that a secret is still required or revoke it safely.
• Scan source control and build artefacts continuously Inspect repositories, commit history, CI logs, build artifacts, and deployment metadata for exposed credentials. Pair detection with automated revocation steps so that discovery does not end as a stale alert.
• Separate pipeline credentials by stage and environment Use distinct secrets for development, test, and production, and limit each one to the smallest runtime scope that still lets the job complete. Reuse across environments turns a single leak into a broader access problem.
• Build rotation into delivery workflows Make secret replacement a normal release activity, not an emergency task. The faster a team can rotate a credential after exposure, the less time an attacker has to exploit it.
• Tie offboarding to every secret issuer When a developer, contractor, service, or pipeline is retired, revoke the associated secrets at the same time. Offboarding that misses credential cleanup leaves access behind after the relationship has ended.

Key takeaways

• Development-stage secrets security fails when credentials are allowed to outlive the code and pipelines that depend on them.
• The evidence points to a control gap, not just a developer habit problem: remediation is slow, and leaked secrets can remain usable for weeks.
• The strongest response is to tie secret discovery, rotation, and offboarding into one lifecycle control rather than treating them as separate tasks.

Key terms

• Secrets sprawl: Secrets sprawl is the uncontrolled spread of credentials across code, pipelines, vaults, logs, and cloud services. It creates a governance problem because no single team can reliably inventory, rotate, or revoke every copy before a leak becomes a sustained access path.
• Credential rotation: Credential rotation is the process of replacing a secret with a new one and invalidating the old value. In mature environments it is tied to ownership, dependency mapping, and audit logging so the change can happen without breaking the workloads that still need access.
• Development-stage secrets security: Development-stage secrets security is the discipline of protecting credentials while software is being built, tested, and deployed. It covers source control, CI/CD, and developer tooling, where speed pressures often cause secrets to be embedded, reused, or left active far too long.
• Identity blast radius: Identity blast radius is the amount of access and downstream reach a credential can create if it is exposed or misused. It is a useful way to judge whether a secret is truly narrow and ephemeral, or whether it can open multiple systems, environments, or service paths.

What's in the full article

Entro Security's full blog covers the operational detail this post intentionally leaves for the source:

• Specific examples of how hard-coded secrets surface in development workflows and why they are missed.
• Entro's out-of-band approach to reading APIs and logs for secrets enrichment across environments.
• The article's practical breakdown of centralized secrets management across multiple vault types.
• The incident discussion around Toyota T-Connect and the consequences of undiscovered source-code exposure.

👉 Entro Security's full post covers hard-coded secret risks, pipeline controls, and the Toyota case study.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 NHI governance in your organisation, it is worth exploring.