Software supply chain attacks in 2025 expose identity blind spots

At a glance

What this is: This analysis argues that software supply chain security is now a governance problem across development, delivery, and post-deployment, with visibility, artifact integrity, and automated policy enforcement as the central gaps.

Why it matters: For IAM, PAM, and NHI practitioners, the identity dimension sits in toolchain accounts, secrets, signing workflows, and access to CI/CD systems that attackers can abuse to alter software delivery.

By the numbers:

• The Gartner 2025 Market Guide for Software Supply Chain Security says 60% of large enterprises are already deploying SSCS tools in 2025, and that figure will rise to 85% by 2028.
• Much software relies on open-source software and vendor components that often make up 70 to 90% of a modern application.

👉 Read Veracode's analysis of Gartner's 2025 software supply chain security guide

Context

Software supply chain security is about controlling trust in the components, tools, and identities that move code from development to production. The risk is not confined to vulnerable libraries, because attackers also target build systems, signing workflows, package registries, and the access paths that let untrusted artifacts reach production. In software-heavy environments, the supply chain has become an identity and governance surface as much as a code-quality issue.

The article’s core point is that fragmented interdependencies create blind spots, and those blind spots are where policy enforcement fails. That matters to identity teams because CI/CD systems depend on service accounts, tokens, secrets, and elevated tooling access that often sit outside normal IAM review cycles. When software delivery becomes a security control plane, the governance model has to follow the trust chain, not just the application.

Key questions

Q: How should security teams govern machine identities in software supply chains?

A: They should treat machine identities as first-class supply chain assets with owners, expiry rules, and revocation paths. The practical goal is to prove provenance for code, build systems, and release automation. Without that lineage, teams cannot reliably detect whether a trusted pipeline credential has been abused or replaced.

Q: Why do software supply chain attacks create an IAM problem?

A: Because attackers frequently abuse trusted access paths rather than exploit the application itself. When a build token, signing key, or deployment account can alter production artefacts, identity control becomes the enforcement layer for software integrity. Without least privilege and strong provenance checks, the supply chain can be used as a privileged distribution channel.

Q: What breaks when organisations rely only on vulnerability scanning in SSCS?

A: Vulnerability scanning finds known flaws in dependencies, but it does not prove that a package is authentic, approved, or untampered. Attackers can still inject malicious code, hijack build access, or use exposed secrets to alter delivery. Organisations need provenance, policy enforcement, and identity governance alongside scanning.

Q: Which control should teams prioritise first in software supply chain governance?

A: Prioritise the control that reduces trust ambiguity in the pipeline. In most environments that means artefact signing, verified package sources, and strict access control for build and release identities. If teams cannot prove who or what changed a component, incident response and compliance both become slower and less reliable.

Technical breakdown

Where supply chain trust breaks in modern delivery pipelines

Software supply chain attacks usually succeed by compromising one of three trust points: the source dependency, the build step, or the release artifact. Open-source packages and third-party APIs expand the attack surface, but the real failure is weak provenance, meaning the organisation cannot prove where a package came from, who changed it, or whether it was altered in transit. Signing, verification, SBOMs, and traceability are the controls that make that trust chain visible.

Practical implication: teams need provenance checks at each promotion step, not just vulnerability scanning at development time.

Why secrets and toolchain identities matter in SSCS

The source article explicitly ties SSCS to scanning code for secrets and preventing unauthorized access to SDLC tools. That matters because CI/CD systems are governed by non-human identities such as service accounts, API keys, and automation tokens, which can bypass human review when they have standing access. If those identities are overprivileged or poorly rotated, attackers can inject packages, tamper with build outputs, or access release systems without touching a developer workstation.

Practical implication: inventory toolchain identities as part of your NHI programme, not as an isolated DevOps hygiene task.

How automated policy enforcement protects software integrity

Policy enforcement in SSCS is the control that stops unapproved or noncompliant artefacts from entering a pipeline. In practice, this means comparing packages, dependencies, and build outputs against policy before release, then preserving audit trails so teams can trace what changed after deployment. Automation matters because manual approval cannot keep up with modern delivery rates, and inconsistent human review creates an integrity gap that attackers can exploit.

Practical implication: enforce policy gates in the pipeline itself, with logging that supports both incident response and compliance review.

Threat narrative

Attacker objective: The attacker wants to turn trusted software delivery into a distribution channel for malicious code, stolen secrets, or unauthorized access.

1. Entry occurs through compromised third-party dependencies, exposed secrets, or unauthorized access to SDLC tooling.
2. Escalation follows when the attacker uses build or release privileges to sign, modify, or insert malicious artefacts into the pipeline.
3. Impact arrives when poisoned packages or tampered artefacts reach production, creating downstream compromise across customers and internal systems.

NHI Mgmt Group analysis

Software supply chain security is now an identity governance problem as much as a code integrity problem. The article correctly frames SSCS as a trust issue across development, delivery, and post-deployment, but the identity surface is what lets attackers turn trust into action. Service accounts, API keys, signing privileges, and CI/CD access often sit outside the controls that IAM teams apply to human users. Practitioners should treat delivery tooling identities as production-grade assets, not developer convenience accounts.

Artifact provenance is the named concept the market still underestimates. Many teams focus on scanning known vulnerabilities, but provenance answers the harder question of whether the thing being deployed is the thing that was approved. That includes package integrity, signed artefacts, and traceability across handoffs, all of which become essential when attackers target the software path instead of the application runtime. Practitioners should make provenance a board-level control objective, not just a build-step check.

Visibility gaps in software delivery create the same governance debt that NHI sprawl creates elsewhere. When teams cannot inventory artefacts, tools, and identities across the SDLC, they cannot prove policy enforcement or rapidly isolate a compromised component. That is the same structural weakness seen in unmanaged non-human identities: hidden trust paths persist until incident response exposes them. Practitioners should close the inventory gap before they attempt to optimise detection.

Automation is the difference between policy and theatre in software supply chain security. The article’s emphasis on automated security controls is well placed because manual review cannot reliably police high-frequency delivery. Yet automation must be paired with clear ownership, or teams simply move the bottleneck from the pipeline to the approver queue. Practitioners should align pipeline controls, identity governance, and audit evidence in one operating model.

SSCS regulation is converging with identity governance expectations. The EU Cyber Resilience Act and similar mandates push organisations toward demonstrable control over software provenance, traceability, and post-deployment response. That shifts accountability from the engineering team alone to the combined security and governance function. Practitioners should expect software delivery controls to be audited with the same seriousness as access controls.

What this signals

The next governance step is to stop treating software delivery as a separate DevSecOps track and start treating it as part of identity and privilege governance. Build systems, package managers, and release automation carry privileged access that can shape production outcomes, so they need the same lifecycle controls applied to high-risk human accounts. For practitioners, that means unifying access review, secret handling, and provenance evidence across the SDLC.

Provenance trust gap: this is the gap between using software and being able to prove the software was authorized, signed, and unchanged. As supply chain attacks increasingly target trusted paths, organisations need controls that prove origin as well as detect flaws. That is where MITRE ATT&CK Enterprise Matrix and OWASP Non-Human Identity Top 10 become useful reference points for pipeline threats and identity abuse.

If the article’s 60% to 85% adoption signal is accurate, SSCS is moving from a specialist control to a baseline expectation. The practical implication is that security leaders will be asked to demonstrate not only that they scan dependencies, but that they can govern the identities and artefacts moving through delivery. Teams that cannot show that chain of control will struggle in both audit and incident response.

For practitioners

• Inventory CI/CD non-human identities Map service accounts, tokens, signing keys, package registry credentials, and automation identities used across build and release systems. Classify which ones can modify artefacts, approve deployments, or reach production so you can assign owners and review intervals.
• Enforce provenance before release Require signed artefacts, verified package sources, and SBOM-backed traceability before code can move from build to production. Treat unsigned or unverified components as policy failures, not review exceptions.
• Automate policy gates in the pipeline Use automated controls to block unapproved dependencies, detect misconfigurations, and prevent unauthorized access to SDLC tooling. Keep the policy decision in the pipeline, not in a manual exception process.
• Connect software delivery to identity governance Bring CI/CD access into the same governance lifecycle as privileged human access. Review ownership, rotation, and offboarding for toolchain accounts with the same rigour used for elevated administrative access.

Key takeaways

• Software supply chain attacks are increasingly a trust and identity problem, not only a dependency problem.
• The biggest operational weakness is the gap between visible vulnerability scanning and invisible artefact provenance.
• Practitioners should govern CI/CD identities, enforce signing and verification, and treat pipeline policy as a production control.

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.
• 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 Non-Human Identity: CI/CD non-human identity is the account, token, key, or certificate used by automation in build and release pipelines. These identities often have broad access and can influence production outcomes, which makes ownership, rotation, and least privilege critical controls rather than administrative details.
• 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.

What's in the full article

Veracode's full article covers the operational detail this post intentionally leaves for the source:

• How Veracode SCA handles reachability analysis, SBOM generation, and binary scanning in real application pipelines.
• How Package Firewall enforces package approval and blocks unapproved artefacts before they enter CI/CD.
• How the vendor maps its capabilities to software delivery, post-deployment traceability, and compliance workflows.
• How the Gartner Market Guide is being used to frame SSCS tool selection and control priorities.

👉 Veracode's full article covers the SSCS capabilities, pipeline controls, and compliance context in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, workload identity, and the operational controls that underpin modern identity programmes. It is designed for practitioners who need to connect identity governance to broader security delivery and assurance.