Topic starter
02/08/2026 12:29 pm
TL;DR: Software supply chain attacks are accelerating as teams rely on ecosystems that make up 70 to 90% of modern applications, while 60% of large enterprises already deploy SSCS tools and Gartner expects that to reach 85% by 2028, according to Veracode's reading of Gartner research. The practical issue is not just provenance, but whether identity, policy, and automation can keep pace with fragmented build and delivery trust.
Editorial analysis by NHI Mgmt Group, based on content published by Veracode: “Software Supply Chain Attacks in 2025: What We Learned from Gartner®”.
By the numbers:
- 70 to 90% of a modern application often comes from open-source software and vendor components, according to Veracode.
- 60% of large enterprises are already deploying SSCS tools in 2025, according to Veracode.
- 85% by 2028 is Gartner's forecast for large enterprises deploying SSCS tools, as cited by Veracode.
Key questions
Q: What breaks when software supply chain identity controls are missing?
A: When build and release identities are not tightly governed, attackers can exploit trusted packages, signing paths, or automation accounts to push malicious artifacts through delivery.
Q: Why does pipeline compromise create identity risk beyond software supply chain risk?
A: Because runners, action permissions, and promotion credentials behave like non-human identities with scope and lifecycle.
Q: What are the signs that artifact provenance controls are failing?
A: Common warning signs include undocumented package sources, inconsistent signing practices, missing ownership for automation accounts, and inability to trace an artifact back to a verified build path.
Practitioner guidance
- Inventory every CI/CD identity Map service accounts, tokens, signing identities, and third-party integrations that can move software through build and release stages.
- Enforce package admission controls Block unapproved or noncompliant packages at ingestion points so risky artifacts cannot enter pipelines.
- Separate signing from deployment authority Use distinct identities for artifact signing, promotion, and deployment so one credential cannot both approve and release software.
Bottom line: Software supply chain attacks are exploiting delivery trust relationships, not just vulnerable code, which means identity governance now sits inside the build and release problem.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:27 pm
Software supply chain security has become an identity governance problem as much as a code integrity problem. The article is right to emphasise visibility, but visibility alone does not stop a compromised package or poisoned pipeline. What matters is whether every non-human identity that can introduce, approve, or deploy software is owned, scoped, and revocable. For practitioners, SSCS and NHI governance now need to be designed together, not managed as separate programmes.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: Should teams prioritise CI/CD access governance or package scanning first?
A: Teams should not treat them as separate choices. Package scanning finds risky components, but CI/CD access governance determines who can introduce or approve them. In a high-velocity pipeline, governance over build identities and promotion rights is the control that keeps scanning findings from becoming live exposure.
👉 Read our full editorial: Software supply chain attacks in 2025 expose identity blind spots