Software supply chain risk and NHI governance for DevOps teams

At a glance

What this is: This is a vendor-authored analysis of software supply chain risk that ties code integrity failures to secrets exposure and over-privileged NHI access in DevOps environments.

Why it matters: It matters because IAM and NHI controls are now part of supply chain defence, not just a back-office security layer for operations teams.

By the numbers:

• Gartner assumes that by 2025, 45% of organizations worldwide will have experienced attacks on their software supply chains, a three-fold increase from 2021.
• Here at Britive, we know that by 2023, 75% of security failures will result from inadequate management of identities, access, and privileges.

👉 Read Britive's analysis of software supply chain risk and least privilege

Context

Software supply chain risk is not only a code problem. In DevOps environments, the same pipelines that build and deploy software also hold service accounts, API keys, certificates, and automation permissions that can be abused if they are static or over-scoped. That makes NHI governance part of supply chain defence, especially where CI/CD systems and privileged build identities sit close to production.

The article argues for a tighter combination of secrets management, least privilege, and just-in-time access because attackers increasingly target trusted build paths rather than only application code. The starting point is typical for modern engineering organisations: security controls are present, but they are often bolted onto fast-moving delivery systems rather than embedded into identity design.

Key questions

Q: How should security teams reduce risk in software delivery pipelines with NHI controls?

A: Start by inventorying every automation identity in the delivery chain, then convert long-lived credentials into short-lived, task-scoped access. Pair that with least privilege, separate approval for signing and promotion steps, and regular revocation of stale tokens. The goal is to prevent one compromised pipeline identity from reaching production or modifying trusted artifacts.

Q: Why do software supply chains create such a high NHI governance burden?

A: Because the delivery chain depends on machine identities that can deploy code, fetch dependencies, sign artifacts, and reach production systems. If those identities are over-privileged or poorly tracked, an attacker can turn one pipeline compromise into broad operational impact. NHI governance matters here because the access layer is part of the supply chain itself.

Q: What is the difference between just-in-time access and static secrets in DevOps?

A: Just-in-time access issues credentials only when a task needs them and revokes them after use, while static secrets remain valid until someone changes them. In DevOps, that difference changes the blast radius of compromise. Ephemeral access limits reuse, but static secrets give attackers a reusable path into builds and deployments.

Q: When should organisations prioritise privileged access management over network controls in supply chains?

A: Prioritise privileged access management when the main risk comes from service accounts, deployment tokens, or build identities that can move across systems. Network controls still matter, but they do not stop an over-privileged token from doing approved work in the wrong context. In supply chains, identity scope often matters more than location.

Technical breakdown

Why CI/CD pipelines become NHI attack surfaces

CI/CD environments concentrate machine identities, automation tokens, and deployment credentials in one place, which makes them high-value targets. If an attacker compromises a build worker, source repository, or artifact pipeline, they may inherit access to signing keys, secrets stores, and downstream deployment permissions. The core issue is that software delivery systems often trust identities for speed rather than continuously verifying context. In NHI terms, the pipeline becomes a privilege corridor where one abused service account can expose multiple environments. Practical implication: treat build and release systems as identity-rich production systems, not just engineering tools.

Practical implication: Segment pipeline identities, narrow token scope, and require re-authentication for privileged build actions.

Dynamic secrets and just-in-time access in DevSecOps

Dynamic secrets replace long-lived credentials with time-bound credentials issued for a specific task, while just-in-time access grants privilege only when needed and revokes it after use. In supply chain contexts, this reduces the blast radius of a leaked token or compromised automation job. The mechanism works best when the issuing system can bind access to workload identity, approval state, and short expiration windows. The limitation is operational discipline: if teams leave exceptions in place, the model degrades back into standing privilege. Practical implication: make ephemeral access the default for deployment, testing, and infrastructure automation.

Practical implication: Use ephemeral credentials for build and deploy workflows, and reserve standing access for only the smallest set of break-glass cases.

Least privilege, zero trust, and the operating environment

Least privilege limits what an identity can do, while zero trust assumes access requests must be verified continuously instead of being trusted because they originate inside the network. In software supply chains, this matters because developers, automation, and third parties all interact with the same delivery fabric. If network flatness and broad entitlements persist, one compromised account can move laterally from build systems to repositories to production. The article’s core warning is that identity controls and network controls must reinforce one another. Practical implication: combine access review, workload segmentation, and strong privileged access boundaries around the delivery path.

Practical implication: Map pipeline permissions explicitly and remove broad trust between development, build, and release layers.

Threat narrative

Attacker objective: The attacker wants to compromise trusted software delivery paths so that legitimate releases carry malicious code, exposed secrets, or widened access into production.

1. Entry occurs when attackers target CI/CD systems, open-source artifacts, or DevOps pipelines that already hold trusted build identities and secrets.
2. Escalation happens when a compromised service account, token, or dependency allows the attacker to tamper with code, inject malware, or access additional privileged resources.
3. Impact follows when malicious code is shipped or sensitive data is exposed through the delivery pipeline, creating downstream compromise across production environments.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• 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

Software supply chain defence now includes NHI governance. The article is right to connect code integrity with secrets and privilege, because modern delivery pipelines are identity systems as much as they are build systems. Service accounts, API keys, and automation tokens determine what code can do after it is assembled. Practitioners should stop treating pipeline access as an engineering exception and govern it as a privileged identity surface.

Static credentials remain the easiest supply chain failure mode. Long-lived secrets in build tooling create a durable foothold for attackers and an audit problem for defenders. When a token can be copied once and reused indefinitely, a single compromise becomes a repeatable access path. The better model is time-bounded, task-scoped credentials with strong revocation and review. Practitioners should make credential lifespan a policy control, not an implementation detail.

Identity blast radius is the right concept for DevSecOps risk. The most useful question is not whether a pipeline is trusted, but how far one compromised identity can move before controls stop it. That shifts attention to scope, segmentation, and approval boundaries across build, test, and release stages. Practitioners should design access so one stolen secret cannot pivot from artifact integrity to production privilege.

JIT access is necessary but not sufficient for pipeline security. Just-in-time controls reduce standing privilege, but they do not fix weak repository hygiene, flat networks, or unsigned artifacts. The article implicitly shows that access control and software integrity have to be managed together. Practitioners should pair ephemeral credentials with signing, artifact trust, and continuous validation.

DevOps security programs need identity ownership, not just tooling. Supply chain controls fail when no one is accountable for service accounts, approval paths, and revocation hygiene. The governance model has to assign ownership for machine identities just as clearly as it does for human users. Practitioners should place pipeline identities under the same policy, review, and exception management discipline as other privileged accounts.

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, according to The State of Secrets in AppSec.
• For a broader governance lens, see The 52 NHI Breaches Report for the breach patterns that make secret sprawl and overprivilege so costly.

What this signals

Static secrets are still the easiest way for supply chain risk to survive process maturity. Even when teams believe their secrets program is strong, the remediation lag tells a different story. With the average leaked secret taking 27 days to remediate, the operational issue is not awareness but response speed, ownership, and scope control. Practitioners should expect AI-assisted code generation and faster delivery to increase secret exposure unless rotation and revocation become automated.

Identity blast radius should become a standard metric for DevSecOps programmes. If one automation token can sign artifacts, deploy code, and touch production, then the environment is already over-coupled. The stronger program signal is whether teams can prove that each machine identity has a narrow, auditable reach. Practitioners should use access reviews and pipeline segmentation to shrink the distance between compromise and impact.

As software teams adopt more autonomous tooling, NHI governance needs to align with OWASP guidance and workload identity standards. The policy question is no longer whether a pipeline is trusted, but whether its identities are bounded, observable, and revocable at machine speed. Teams should use OWASP Non-Human Identity Top 10 and workload identity patterns to set expectations for access design.

For practitioners

• Inventory all pipeline NHIs Map service accounts, API keys, certificates, and automation tokens across source control, CI/CD, artifact repositories, and deployment systems. Classify each identity by owner, scope, and expiry so you can see where standing privilege still exists.
• Replace static secrets with ephemeral credentials Issue time-bound credentials for build, test, and release tasks wherever the workflow allows it. Tie issuance to workload identity and revoke access automatically when the job completes.
• Constrain privileged build paths Segment repositories, build runners, signing services, and deployment targets so one compromised account cannot traverse the entire delivery chain. Require separate approval for actions that modify artifacts, sign releases, or promote code.
• Harden artifact trust and code integrity Use signing, hashing, and trusted artifact repositories to verify what enters the pipeline and what leaves it. Pair those controls with routine review of vendor dependencies and third-party risk.
• Run recurring access reviews on automation accounts Review who owns each automation identity, what it can reach, and whether it still needs production access. Remove orphaned secrets and stale entitlements before they become part of the attack surface.

Key takeaways

• Software supply chains are now identity problems as much as code problems, because build and release systems depend on privileged non-human identities.
• Long-lived secrets and broad automation permissions create a large blast radius, which is why leaked credentials and pipeline compromise remain high-impact paths.
• Security teams should pair just-in-time access, least privilege, and artifact trust controls to reduce the chance that one compromised workflow can reach production.

Key terms

• Non-Human Identity: A non-human identity is any credentialed account or artifact used by software, services, or automation rather than a person. In practice, this includes service accounts, API keys, tokens, certificates, and agent credentials that need ownership, scope, lifecycle control, and auditability just like human identities.
• Just-in-Time Access: Just-in-time access grants privilege only when a task needs it and removes it when the task ends. For NHI programmes, the value is reducing standing privilege and shrinking the time window in which a stolen token or compromised workflow can be abused.
• Identity Blast Radius: Identity blast radius is the amount of damage an attacker can cause after compromising a single credential or account. It depends on scope, segmentation, approval boundaries, and how many systems a machine identity can reach before a control stops it.
• Software Supply Chain: A software supply chain is the set of tools, identities, dependencies, and processes that turn source code into deployed software. Because it relies on automation and privileged machine identities, it becomes a governance problem when access, signing, and deployment controls are too broad.

Deepen your knowledge

Software supply chain identity governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are formalising access control for CI/CD, it is worth exploring.

This post draws on content published by Britive: 3 Steps Software Engineering Leaders Can Follow to Reduce Security Risks to Supply Chains. Read the original.