Software supply chain risk and NHI governance for DevOps teams

At a glance

What this is: This is a supply chain risk analysis showing that DevOps pipelines, CI/CD tooling, and privileged service accounts create identity governance gaps when code integrity, secrets, and access controls are managed separately.

Why it matters: It matters because IAM, PAM, and NHI teams must govern build-time identities and secrets as part of supply chain resilience, not as a separate operational concern.

By the numbers:

• 45% of organisations worldwide will have experienced attacks on their software supply chains by 2025, according to Gartner research cited by Britive.
• Gartner said the increase would represent a three-fold increase from 2021.
• By 2023, 75% of security failures will result from inadequate management of identities, access, and privileges, according to Britive.

Context

Software supply chain risk is an identity governance problem as much as a code-integrity problem. When DevOps teams rely on static secrets, broad service account permissions, and CI/CD tools that can move code from source to production, the access model becomes part of the attack surface. In this context, software supply chain security means governing who and what can alter, sign, ship, or consume build artifacts.

The article’s core point is that conventional controls focused only on scanning or patching are not enough. Once attackers can inject malicious code, tamper with build pipelines, or abuse privileged automation, the issue shifts from software quality to non-human identity governance, least privilege, and operational trust boundaries.

That makes the DevOps operating environment a lifecycle problem, not just a tooling problem. If service accounts, secrets, and deployment credentials are not governed with the same discipline as human access, then compromise can spread laterally from development systems into production delivery paths.

Key questions

Q: What breaks when CI/CD pipelines rely on static secrets?

A: Static secrets create a reusable attack path into production infrastructure. Once they are copied into workflow files, logs, runner images, or environment variables, a single compromise can expose broad access long after the original job finishes. That is why pipeline secrets should be treated as production identity, not temporary configuration.

Q: Why do supply chain attacks so often turn into identity incidents?

A: Because attackers are not only changing code, they are harvesting the non-human identities that code runs beside. API keys, cloud credentials, SSH keys, and registry tokens give direct access to infrastructure and publishing systems, so a compromised package becomes an identity compromise with wider blast radius.

Q: What signs show that DevOps access is too broad for supply chain security?

A: Common signs include one service account used across multiple environments, secrets shared between tools, credentials that never expire, and deployment rights that are not tied to a specific release task. Those patterns indicate the pipeline is relying on standing trust instead of governed access.

Q: How should security teams apply zero trust to software delivery environments?

A: They should treat each pipeline step as a separate access event and require explicit authorisation for every privileged action. That means narrowing network assumptions, verifying machine identities continuously, and using temporary credentials that expire as soon as the task is complete.

Technical breakdown

How supply chain compromise turns into identity abuse

Software supply chain attacks often begin by targeting the systems that build, package, sign, or distribute code. Those systems rely on non-human identities such as service accounts, tokens, API keys, and certificates, which are frequently embedded in automation. Once an attacker reaches that layer, they do not need to attack the application directly. They can tamper with dependencies, replace trusted artifacts, or use privileged build credentials to move into the delivery chain. The key technical issue is that build automation often trusts the identity running it more than the code it is processing. That reverses the normal security assumption and gives attackers a path to persistence inside release infrastructure.

Practical implication: Map every build and release credential to an owner, scope, and expiry so CI/CD access cannot outlive the job it supports.

Why static secrets and over-privileged service accounts widen blast radius

Static secrets are long-lived credentials that remain valid until someone rotates or revokes them. In supply chain environments, they are especially risky because a leaked secret may be reused across repositories, pipelines, and environments. Over-privileged service accounts compound the problem by allowing a compromised identity to do more than the task requires. That creates a blast radius that extends beyond one system or one deployment. Least privilege is therefore not just an access policy, but a containment mechanism for build systems. If the identity behind automation can sign releases, read repositories, and reach infrastructure, compromise of that one credential can become cross-environment exposure.

Practical implication: Reduce standing privilege on automation identities and replace reusable secrets with short-lived credentials wherever possible.

How zero trust and PAM apply to DevOps pipelines

Zero Trust Architecture assumes no implicit trust based on network location or pipeline membership. In DevOps, that means each action taken by a build or deployment identity should be authenticated, authorised, and limited to the minimum necessary scope. PAM extends that discipline to elevated access, where temporary administration or deployment rights must be visible and controlled. The article’s emphasis on dynamic secrets and just-in-time credentials reflects this model. Rather than treating CI/CD tooling as a trusted lane, practitioners should treat each pipeline step as a privilege event. That changes how approvals, session scope, and revocation are designed across the delivery lifecycle.

Practical implication: Apply zero trust and PAM controls to pipeline identities so elevated actions are temporary, scoped, and reviewable.

Threat narrative

Attacker objective: The attacker wants to compromise trusted software delivery so malicious code, stolen secrets, or tampered artifacts can be distributed at scale.

1. Entry occurs through compromised software development systems, open-source artifacts, or DevOps pipeline dependencies that the organisation already trusts.
2. Credential access follows when attackers obtain secrets, tokens, or privileged service account credentials used by build and delivery automation.
3. Escalation and lateral movement happen when over-privileged identities let the attacker alter code, sign artifacts, or move across environments.
4. Impact is achieved when malicious or tampered software is delivered into the operating environment, exposing secrets, code, or production trust chains.

Breaches seen in the wild

• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
• GitHub code signing certificate theft 2022: A machine account's compromised token cloned GitHub's Desktop and Atom repos, exposing encrypted signing certificates later revoked.

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 governance fails when teams separate code integrity from identity control. This article shows that malicious code injection, pipeline tampering, and secret exposure are the same governance problem viewed at different layers. If the build system can act with broad authority, then integrity checks alone cannot prevent delivery compromise. Practitioners should treat pipeline identity as part of the supply chain security model, not as an operational afterthought.

Static secrets are a structural weakness, not just a hygiene issue. Long-lived credentials create a persistence window that attackers can exploit long after initial compromise. In DevOps environments, that window expands because secrets are often reused across repositories, environments, and automation jobs. The implication is that credential lifetime, not just code scanning, determines how far supply chain compromise can spread.

Least privilege becomes a containment control for software delivery. The article is right to connect flat network assumptions and over-privileged service accounts to lateral movement risk. If a build identity can reach more systems than a single job requires, the supply chain has already exceeded its intended trust boundary. Practitioners should redefine privilege scope around release tasks, not around convenience for automation.

Identity blast radius: Supply chain attacks succeed when one automation identity can alter too many downstream systems, artifacts, or secrets. That is why DevOps governance has to focus on who can sign, ship, and deploy, not just who can code. The stronger the delegation chain, the larger the blast radius when any link is compromised. Security teams should measure that blast radius explicitly.

Zero trust for DevOps is about continuous verification of machine actions. The operating environment for software engineers is no longer a trusted enclave. Every privileged pipeline step needs its own access boundary, especially where authentication, authorisation, and JIT credentials are involved. Practitioners should align release governance with verified, ephemeral access rather than enduring trust.

From our research library:

• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Secrets Management Guide

What this signals

Supply chain security programmes now need to treat DevOps identities as first-class governance objects. If build automation still relies on durable credentials and broad deployment rights, the organisation has already accepted a hidden trust boundary that attackers can exploit.

Identity blast radius: The practical question is not whether code can be scanned, but how far a compromised build identity can move before detection. Teams should measure privilege scope, secret lifetime, and revocation speed as core supply chain risk indicators.

For practitioners

• Inventory pipeline identities and credentials Map every CI/CD service account, token, API key, and certificate to the job, repository, and environment it supports. Remove credentials that cannot be tied to a named automation purpose.
• Replace static secrets with JIT credentials Use short-lived credentials for build and deployment tasks so access expires when the job ends. Eliminate reusable secrets where temporary services or temporary releases can use dynamic issuance instead.
• Right-size service account permissions Audit DevOps accounts for broad write, sign, and deploy privileges that exceed the task they perform. Reduce access to the minimum set of repositories, registries, and environments required.
• Harden build and release controls Require trusted artifact repositories, code signing, and security controls inside CI/CD tools so tampering is harder to introduce and easier to detect before release.
• Apply zero trust to engineering environments Treat developer and pipeline access as high-risk access paths. Verify each action, constrain each session, and assume the operating environment itself is part of the attack surface.

Key takeaways

• Software supply chain attacks are not only about malicious code. They also exploit the identities, secrets, and permissions that let code move through CI/CD systems.
• The article links the risk to broad exposure, including Gartner’s projection that 45% of organisations worldwide will experience supply chain attacks by 2025.
• The strongest control pattern is governed, temporary access for build and deployment identities, backed by least privilege and trusted release controls.

Key terms

• 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.
• Dynamic Secret: A secret generated on-demand for a specific task and automatically revoked after use or expiry. Dynamic secrets dramatically reduce the risk of credential exposure compared to static, long-lived secrets and are considered best practice.
• Service Account: A special-purpose account used by applications, automated tools, or services rather than a human user to interact with systems, APIs, and infrastructure. Service accounts are a primary category of NHI and one of the most frequently exploited attack vectors.
• Least Privilege: A security principle requiring that every identity, human or non-human, is granted only the minimum permissions necessary to perform its function. Least privilege is the single most effective control for reducing NHI blast radius.

Deepen your knowledge

NHI governance, secrets management, and workload identity security 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.