Secrets sprawl and static privileges still fuel software supply chains

At a glance

What this is: This is a software supply chain and secrets management analysis showing that secret sprawl, static privileges, and weak rotation create the conditions attackers exploit to plant malicious code.

Why it matters: It matters because IAM, PAM, and NHI programmes must govern credentials as short-lived access paths, not as durable assets hidden in repositories, logs, and build workflows.

By the numbers:

• 17 minutes

👉 Read Akeyless' analysis of software supply chain risk and secret sprawl

Context

Software supply chain attacks succeed when attackers compromise the least-protected element in the build or delivery chain and use that trust relationship to introduce malicious code. In this case, the identity problem is not the software itself, but the credentials and secrets that unlock repositories, build systems, and update paths.

Secret sprawl is the operational gap underneath that risk. When developers store keys, tokens, or certificates in code, configuration files, or logs, the organisation loses control over who can use them, how long they remain valid, and whether they can be detected before abuse begins.

For identity programmes, this is a non-human identity problem with direct impact on human IAM governance as well. Secrets become durable access paths unless they are centrally governed, rotated, and constrained with policy.

Key questions

Q: How should security teams stop leaked secrets from turning into supply chain compromise?

A: They should reduce the lifetime and reuse potential of every secret that can reach source control, build, or deployment systems. Centralised storage helps, but the real control is limiting standing validity, enforcing rotation, and eliminating hidden copies in logs, configs, and developer workarounds.

Q: Why do static secrets create so much supply chain risk?

A: Static secrets create risk because they turn a single leak into a long abuse window. If a credential remains valid for weeks or months, an attacker has time to discover it, reuse it, and pivot into trusted build or release paths before detection or revocation.

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: Who is accountable when stolen software supply chain credentials are used to publish malicious code?

A: Accountability sits across the maintainer, platform, and security functions because publishing rights, token scope, and runner governance all contribute to the failure. Under NHI governance, the owner of the credential lifecycle is responsible for limiting the blast radius of any stolen token.

Technical breakdown

How leaked secrets become trusted supply chain access

A leaked secret is often enough to turn a public artefact into a trusted identity. OAuth tokens, API keys, and certificates can authenticate directly to repositories, cloud services, or CI/CD systems without triggering a human login flow. Once used, that credential may inherit standing privilege, meaning the attacker can move from initial access to code alteration or pipeline abuse without needing to defeat another control. In supply chain environments, trust is frequently granted to the secret, not the actor using it.

Practical implication: inventory every secret that can reach source control, build, or release systems, and treat each one as a recoverable identity path.

Why secret sprawl defeats centralised governance

Secret sprawl occurs when credentials are duplicated across code, configs, environment variables, developer laptops, and logs. That fragmentation breaks visibility and makes lifecycle control inconsistent, because a single credential can exist in multiple unmanaged places with different exposure states. A vault may hold one copy, but developers often create untracked copies outside it to keep pipelines moving. The result is governance by exception rather than policy, which is exactly what supply chain attackers exploit.

Practical implication: map where secrets are created, copied, and consumed before you try to rotate them, or you will miss the real exposure surface.

Why JIT access changes the exposure window

Just-in-Time access changes the security model by making credentials ephemeral instead of durable. Rather than granting a static secret that remains valid for weeks or months, the system issues a limited-use credential for a specific target and session, then revokes it automatically. That matters in machine-to-machine and human-to-machine workflows because the attacker no longer has a long-lived artefact to reuse after exfiltration. This is not just shorter rotation; it is a different assumption about how access should exist at all.

Practical implication: reserve JIT for the highest-risk integrations and pair it with rotation for the legacy flows that cannot yet be made ephemeral.

Threat narrative

Attacker objective: The attacker aims to insert malicious code into a trusted software supply chain path and have it propagate to downstream organisations as legitimate software.

1. Entry occurs when attackers obtain a leaked secret from code, logs, or a public repository and use it to authenticate into the software delivery chain.
2. Escalation follows when the stolen credential provides standing privilege across repositories, build systems, or update mechanisms, allowing the attacker to alter trusted components.
3. Impact occurs when the compromised component is signed or distributed as legitimate software, spreading malicious code to downstream customers and environments.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• Code Formatting Tools Credential Leaks — Widely used code formatting tools cause massive credential and secrets leaks in enterprise environments.

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 sprawl is the real supply chain control failure, not just a hygiene problem. When keys, tokens, and certificates are embedded across code, logs, and configuration files, the organisation loses the ability to govern access as a lifecycle. That creates multiple unmanaged copies of the same identity artefact, each with a different exposure state. The practitioner conclusion is that supply chain defence starts with knowing where secrets exist, not just where they are supposed to live.

Long-standing privileges are an access assumption built for static systems, and that assumption is breaking. Static secrets assume the credential can remain valid long enough to be protected, reviewed, and rotated on a predictable schedule. Supply chain attackers exploit the gap between issuance and revocation, because a valid secret can outlast the controls meant to contain it. The practitioner conclusion is that standing access windows, not only breach detection, must be treated as a primary risk metric.

JIT access creates a different governance model for NHI and H2M flows. A secret created for a single session changes the trust boundary from durable identity to time-bound authorisation, which is more aligned to attack reality in build and deployment pipelines. That makes JIT especially relevant where machine identities interact with software delivery systems. The practitioner conclusion is that ephemeral access should become the default design target for high-risk integrations.

Ephemeral credential trust debt: the more an organisation relies on static secrets for operational convenience, the more remediation work it defers into the future. That debt is paid when one leaked credential can still authenticate across multiple systems. The practitioner conclusion is to treat every long-lived secret as accumulated blast radius.

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, which helps explain why secret sprawl persists across engineering teams.
• 52 NHI Breaches Analysis is the right next step when you want breach patterns that show how exposed credentials become real-world compromise.

What this signals

Secret lifecycle management is now a delivery-chain control, not a back-office IAM task. The practical question is whether your organisation can find, classify, and revoke every credential before it becomes reusable in build and release systems. A vault alone is not enough if developers can still create unmanaged copies, so policy has to follow the software path as closely as the identity path.

With 43% of security professionals worried that AI systems may learn and reproduce sensitive patterns from codebases, secret governance is now part of AI risk management too. That concern widens the problem beyond leakage into model exposure, which means code scanning, log hygiene, and access scope all feed into the same control surface. Practitioners should treat secrets and AI data exposure as a shared governance problem, not separate queues.

Ephemeral credential trust debt: organisations that keep long-lived secrets to preserve pipeline convenience are accumulating future breach impact. The forward-looking programme change is to shift high-risk integrations toward session-scoped access and to use 52 NHI Breaches Analysis as a breach-pattern benchmark when prioritising remediation.

For practitioners

• Map every secret path into the software supply chain Trace where credentials are created, stored, copied, and consumed across repositories, build jobs, logs, artifact stores, and deployment targets. Include developer workarounds and shadow copies outside the vault, because that is where secret sprawl usually hides.
• Replace durable secrets with ephemeral access where possible Use Just-in-Time credentials for high-risk machine-to-machine and human-to-machine flows so leaked credentials expire before attackers can reuse them. Keep the session scope narrow and ensure revocation happens automatically at session end.
• Rotate and revoke by exposure state, not calendar date Prioritise secrets found in public code, logs, or exposed repositories and revoke them immediately, then rotate secrets with standing privilege on a shorter lifecycle than your current standard allows.
• Align developer workflows with governed secret access Provide approved patterns that let developers retrieve secrets without embedding them in source files or configuration. The goal is to remove the incentive to bypass controls while preserving pipeline speed.
• Monitor unusual secret use across delivery systems Alert on secrets used from unexpected hosts, at unusual times, or against repositories and targets outside their normal pattern. In supply chain contexts, misuse often appears first as valid access from the wrong place.

Key takeaways

• Secret sprawl turns ordinary code and log hygiene failures into supply chain entry points that attackers can reuse as trusted access.
• Long-lived credentials extend the attacker’s window, so rotation speed and revocation coverage are central controls, not supporting controls.
• Ephemeral access and governed developer workflows reduce the blast radius more effectively than vaulting alone.

Key terms

• 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.
• JIT — Just-in-Time Access: A security approach that grants access permissions only for the duration needed to complete a specific task, then automatically revokes them. JIT access eliminates standing privileges for NHIs, dramatically reducing attack surface.
• Software Supply Chain Attack: A software supply chain attack targets the path software takes from source code to production. The attacker corrupts code, dependencies, build steps, or artifacts so that trusted delivery mechanisms spread malicious logic into environments that would otherwise reject direct intrusion.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.

What's in the full article

Akeyless' full article covers the operational detail this post intentionally leaves for the source:

• Practical examples of how leaked secrets enter code repositories, logs, and configuration files.
• Implementation detail on how Just-in-Time access is applied to human-to-machine and machine-to-machine workflows.
• The vendor's explanation of vault-based secret storage and high-frequency rotation in hybrid and multicloud environments.
• Specific workflow guidance for security teams trying to reduce secret sprawl without slowing delivery.

👉 Akeyless' full article covers vaulting, rotation, and Just-in-Time access for supply chain defence.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.