TL;DR: Software supply chain attacks are growing in scope and sophistication, with Britive citing Gartner’s projection that 45% of organisations worldwide will experience them by 2025; the article says the governance gap extends beyond code integrity to static secrets, over-privileged service accounts, and weak least-privilege enforcement. Software supply chain security fails when build systems and DevOps identities are treated as durable trust zones rather than governed access surfaces.
Editorial analysis by NHI Mgmt Group, based on content published by Britive: “3 Steps Software Engineering Leaders Can Follow to Reduce Security Risks to Supply Chains”.
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.
Key questions
Q: What breaks when CI/CD pipelines rely on static secrets?
A: Static secrets create a reusable attack path into production infrastructure.
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.
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.
Practitioner guidance
- Inventory pipeline identities and credentials Map every CI/CD service account, token, API key, and certificate to the job, repository, and environment it supports.
- Replace static secrets with JIT credentials Use short-lived credentials for build and deployment tasks so access expires when the job ends.
- Right-size service account permissions Audit DevOps accounts for broad write, sign, and deploy privileges that exceed the task they perform.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full 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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Software supply chain risk and NHI governance for DevOps teams