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.
At a glance
What this is: Veracode argues that software supply chain attacks are rising as complex delivery ecosystems create blind spots in artifact integrity, policy enforcement, and toolchain identity control.
Why it matters: It matters because practitioners have to govern both software provenance and the identities that can alter build, package, and deployment trust in CI/CD pipelines.
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.
Context
Software supply chain security is no longer a narrow build integrity problem. It now spans source dependencies, package ingestion, artifact signing, pipeline policy, and the identities that can approve or alter those stages. In practice, the control gap appears when teams can see code and packages but cannot reliably govern who or what is trusted to move them through delivery.
For identity and access teams, the important shift is that CI/CD systems now behave like high-value trust brokers. Service accounts, third-party integrations, and automation tokens can all become supply chain entry points when they are over-privileged, poorly inventoried, or difficult to trace back to ownership. That makes this topic relevant to NHI governance as much as to secure development.
The article frames this as a scaling problem rather than a single product gap. That is typical of modern supply chain risk: visibility, provenance, and enforcement all fail together when the delivery ecosystem is fragmented.
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. The break is not only technical compromise, but loss of assurance that released software is what the organisation intended to approve and deploy.
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. If those identities are shared across untrusted and privileged jobs, a compromise in one execution path can reach secrets, artifact signing, or deployment authority. That turns a code trust problem into an identity governance problem.
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. Those gaps usually mean policy enforcement is happening too late or not at all.
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.
Technical breakdown
Where software supply chain risk starts in the delivery chain
Software supply chain attacks typically begin where software is assembled rather than where it is written. Adversaries target open-source dependencies, third-party APIs, package registries, and CI/CD tooling because those layers are trusted by default and often operate with broad automation privileges. Once a malicious component enters the pipeline, the issue is not just malware but trust propagation through legitimate delivery mechanisms. In this environment, artifact provenance, package validation, and pipeline identity are inseparable from one another.
Practical implication: map every system that can introduce or approve build inputs, including service accounts and automation tokens, before trust assumptions spread.
Why artifact integrity fails when identities are not governed
Artifact integrity depends on being able to prove that what is built, signed, and deployed is the same thing that was approved. That proof weakens when signing keys, pipeline credentials, and deployment permissions are shared, untracked, or reused across environments. The article's emphasis on policy enforcement reflects a deeper issue: policy is only effective when the identities enforcing it are constrained and auditable. In supply chain environments, identity scope becomes part of integrity control, not a separate administrative concern.
Practical implication: tie signing, approval, and deployment permissions to distinct identities with narrow scope and auditable ownership.
How automation closes blind spots in CI/CD security
Automation matters because manual review cannot keep pace with modern delivery velocity or the number of dependencies in play. Security automation in SSCS is not just scanning; it is continuous policy enforcement, inventorying tools and artifacts, and flagging misconfigurations before they reach production. Without that automated layer, teams can know a risk exists but still fail to stop it at the right stage. For identity governance, the same logic applies to non-human identities that operate inside pipelines: if they are not continuously governed, the control gap reappears at runtime.
Practical implication: automate policy checks and inventory tracking for build and deployment identities so noncompliant artifacts are blocked before release.
Threat narrative
Attacker objective: The attacker aims to turn trusted software delivery infrastructure into a propagation path for tampered artifacts, unauthorized access, or downstream compromise.
- Entry occurs when attackers exploit trusted dependencies, compromised packages, third-party APIs, or CI/CD toolchain access to place malicious components into the delivery path.
- Credential and trust abuse follow when build or deployment identities have enough privilege to sign, approve, or promote artifacts without strong separation of duties.
- Impact occurs when poisoned artifacts or unapproved packages reach downstream environments, exposing software integrity, compliance posture, and production trust.
Breaches seen in the wild
- SpotBugs token leak 2025: A SpotBugs maintainer's PAT, stolen via a pull_request_target workflow in 2024, started the reviewdog and tj-actions supply chain attack.
- HashiCorp GPG key exposure 2021: Codecov's poisoned Bash Uploader exposed the GPG key HashiCorp used to sign download checksums; HashiCorp rotated it and re-signed its releases.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Supply chain defence fails when delivery trust is treated as static. The modern pipeline is a chain of delegated trust relationships across repositories, registries, signing systems, and automation accounts. If any of those identities can act broadly across environments, a single compromise can cascade from development to production. The practitioner conclusion is simple: reduce the number of identities that can move artifacts and make each one traceable to a named control owner.
Continuous policy enforcement is now the control boundary that matters most. Manual approvals, ad hoc package review, and intermittent audits do not scale against the pace of modern delivery. Automated blocking of unapproved components, restricted artifact promotion, and traceable signing and verification are the only reliable way to keep integrity decisions close to issuance. For teams, the governance question is no longer whether to automate, but which trust decisions must never be left to humans alone.
Artifact provenance is the named concept that now defines supply chain resilience. Provenance is not just knowing where software came from, but proving which identities touched it, which policies approved it, and whether it can be traced back after compromise. That makes provenance a governance control, not a documentation exercise. Practitioners should treat provenance as the bridge between build security and identity security.
From our research library:
- 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.
- Read next: CI/CD Pipeline Identity Security Guide
What this signals
Artifact provenance is now inseparable from identity governance. In a pipeline, the question is not just whether a package is trusted, but which non-human identities were able to introduce, approve, or move it. That makes service account ownership, signing authority, and promotion rights part of the same control surface.
Supply chain resilience will increasingly depend on controlling delegated trust inside CI/CD. The organisations that reduce blast radius are the ones that can trace every automation credential to a named owner and a bounded purpose. Without that discipline, policy enforcement becomes a retrospective audit exercise instead of an active control.
CI/CD pipeline identity security should be treated as a governance programme, not an engineering afterthought. The delivery system is now a high-value trust broker, so practitioners need lifecycle controls for tokens, clear separation between signing and deployment, and continuous review of external access.
For practitioners
- Inventory every CI/CD identity Map service accounts, tokens, signing identities, and third-party integrations that can move software through build and release stages. Assign an owner to each identity and remove any shared or orphaned access path.
- Enforce package admission controls Block unapproved or noncompliant packages at ingestion points so risky artifacts cannot enter pipelines. Pair the control with explicit allowlists and denial logging.
- Separate signing from deployment authority Use distinct identities for artifact signing, promotion, and deployment so one credential cannot both approve and release software. Review those permissions as part of access certification.
- Automate provenance verification Require artifact signing, verification, and traceability checks before release and after deployment. Make the checks continuous, not a one-time gate.
- Tie pipeline access to third-party governance Review any external developer, contractor, or vendor access that can reach repositories, registries, or build systems. Offboard access as soon as the business need ends.
Key takeaways
- 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.
- The article's evidence points to growing enterprise adoption of SSCS tools, but adoption alone does not close the gap if automation identities remain over-privileged or untracked.
- Practitioners should focus on provenance, pipeline access, and automated policy enforcement together, because any one control on its own leaves the trust chain incomplete.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party packages and integrations are central to the attack surface described here. |
| NHI-05 — Overprivileged NHI | Pipeline identities with broad rights can approve or move tampered artifacts. | |
| NHI-07 — Long-Lived Secrets | Persistent tokens and signing credentials extend the attack window across delivery stages. | |
| Recommendation — Inventory and constrain third-party NHIs that can introduce software into build and release paths. Reduce privilege for CI/CD accounts so no single NHI can both approve and deploy software. Shorten the lifetime of pipeline secrets and rotate them on a fixed schedule. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The threat pattern depends on abusing credentials to move through trusted delivery systems. |
| Recommendation — Map pipeline compromise paths to TA0006 and TA0008 to prioritise detection and containment. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centres on who can act inside software delivery systems and with what scope. |
| Recommendation — Apply PR.AA-05 to review entitlements for build, signing, and deployment identities. | ||
| CIS Controls v8 | CIS-5 — Account Management | CI/CD service accounts and third-party access need lifecycle governance and offboarding. |
| Recommendation — Use CIS-5 to manage creation, review, and removal of pipeline accounts and tokens. | ||
Key terms
- Software Supply Chain Security: Software supply chain security is the practice of protecting the people, code, tools, dependencies, and delivery paths used to build and ship software. It covers source integrity, dependency risk, build system hardening, artifact signing, provenance, and release controls so malicious changes are detected before software reaches production.
- Action Provenance: Action provenance is the record of who initiated a task, which identity executed it, what tool was used, and what decision was made at runtime. It is essential when delegated work crosses systems because it preserves accountability even when the original request and the final action are separated by many steps.
- CI/CD Identity: CI/CD identity is the set of credentials and permissions used by build, test, and deployment systems to act in software delivery pipelines. It includes service accounts, tokens, keys, and certificates that let automation access code, artifacts, cloud resources, and deployment targets. Strong governance limits exposure, scope, and lifetime.
- Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to align identity controls with broader security programmes.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org