TL;DR: Software supply chain security now depends on continuous visibility, contextual prioritisation, and automated remediation because trusted packages, build systems, and maintainer accounts can turn one compromise into thousands of downstream exposures, according to ArmorCode. The identity angle is now central: CI/CD access, signing keys, and maintainer credentials are part of the attack surface, not just the code.
At a glance
What this is: Software supply chain security is no longer just about vulnerable packages; the article argues that identity, build integrity and remediation speed now determine how far one compromise spreads.
Why it matters: For IAM, PAM and NHI practitioners, the key issue is that maintainer accounts, CI/CD identities and signing keys have become part of the security perimeter, so access governance directly shapes blast radius.
By the numbers:
- Axios has over 100 million weekly downloads, showing how account compromise can create very broad downstream exposure.
- Attackers compromised over 700 packages in a November 2025 wave, one of the largest supply chain attacks on record.
Context
Software supply chain security is the discipline of protecting the components, identities and delivery systems that software depends on. The article argues that modern delivery chains now include source control, package registries, CI/CD workflows, signing processes and the accounts that can change them, which means compromise can enter through trusted operational paths rather than the application itself.
That matters for identity governance because the attack surface includes maintainer credentials, build permissions, artifact trust and release authority. In practice, software supply chain risk is not just a vulnerability-management problem; it is a control problem spanning access, provenance and response speed.
The article’s starting position is typical of the current market: most organisations have visibility into some part of the chain, but few can connect dependency data, build integrity and accountable remediation into one operating model.
Key questions
Q: What breaks when non-human identities are not governed in software supply chains?
A: When non-human identities are not governed, attackers can use tokens, service accounts, and secrets to reach build, release, and data systems that were never meant to be exposed together. The result is hidden persistent access, broad blast radius, and compromise that can spread through trusted automation before anyone notices.
Q: Why do SBOMs and VEX need reachability data before teams prioritise remediation?
A: Because a component can be present without being exploitable. SBOMs show what exists, VEX explains whether a known vulnerability affects the product, and reachability shows whether the risky code path is actually used. Together they prevent teams from wasting effort on theoretical exposure while the truly reachable, business-critical issue stays open.
Q: What are the signs that software supply chain controls are failing in practice?
A: Common warning signs include overreliance on vulnerability lists, weak visibility into third party dependencies, limited scrutiny of developer tooling, and no practical way to audit the full software estate. If teams can only identify known CVEs but cannot assess package provenance, build trust, or dependency risk at scale, their controls are missing the real attack surface.
Q: How should teams respond when a package or maintainer account is compromised?
A: Assume any reachable credentials may be exposed, then rotate broadly across vaults, cloud secret managers, and developer tooling. The response should prioritise the credentials that could unlock other secrets, not just the first token named in the incident report.
Technical breakdown
Why software supply chain risk is really an identity problem
A software supply chain is a trust graph. Every package, build tool, signing key, repository and CI/CD workflow carries implicit trust, and attackers look for the account or secret that can alter one of those trusted nodes. Once a maintainer account, pipeline credential or signing key is compromised, malicious code can be inserted into a release that downstream systems accept as legitimate. That is why supply chain attacks often spread faster than conventional exploits: they abuse authorised change paths rather than breaking into runtime systems first. The security issue is not only code integrity, but who can make a trusted change and under what control.
Practical implication: Treat release authority, pipeline access and signing credentials as privileged identities, not ordinary development access.
SBOMs, VEX and reachability: the visibility problem behind prioritisation
An SBOM lists components, but it does not tell you whether a vulnerable function is reachable, whether the package is in production, or whether the business impact is material. VEX adds exploitability context, helping teams separate present-but-benign exposure from a component that can actually be used. Reachability analysis closes another gap by showing whether the affected code path exists in the deployed application. Together, these controls turn an inventory into a decision-making system. Without them, teams drown in repeated findings and learn to ignore the tickets that matter most.
Practical implication: Combine SBOM, VEX and reachability data before routing remediation work.
Protected build systems are the control point that determines downstream trust
Build systems, artifact repositories and CI/CD workflows are where software is turned into something that other systems trust. If those systems lack least privilege, strong authentication, branch protection, isolated builds or secrets management, an attacker can swap a dependency, alter a package or inject malicious code during packaging. The article also makes clear that provenance and signed artifacts are part of the same trust chain, because downstream consumers need evidence that a release came from an approved process. In other words, build security is identity security applied to software production.
Practical implication: Harden build and release identities before focusing only on component vulnerability counts.
Threat narrative
Attacker objective: The attacker wants to convert trusted software delivery paths into a high-scale distribution channel for malware, credential theft or persistence.
- Entry begins when attackers compromise a trusted maintainer account, a package registry identity or a CI/CD workflow that can publish or modify software releases.
- Credential access or abuse then lets them push malicious package versions, tamper with build outputs or replace signed artifacts with trojanized releases.
- Impact follows when downstream developers, pipelines or customer environments install the poisoned component at scale, turning one account compromise into many affected systems.
Breaches seen in the wild
- Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.
- 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.
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 is now an identity governance problem as much as a code integrity problem. The decisive control point is no longer only the vulnerability in the package, but the identity that can publish, sign or promote it. That shifts the security conversation from scanning artifacts to governing change authority, especially for maintainers, release engineers and CI/CD service accounts. Practitioners should treat these identities as production-grade assets with explicit ownership and lifecycle controls.
Continuous visibility only works when it is tied to decision context. An SBOM without freshness, ownership and deployment mapping becomes a static record rather than an operational control. The article’s emphasis on reachability, business criticality and compensating controls reflects the real problem: not every vulnerable component is equally actionable. Security programmes should therefore move from inventory completeness to exposure relevance.
Blast-radius control is the central concept this article sharpens. A single compromised package or maintainer account can propagate through many downstream products because modern delivery chains reuse trust at every stage. That means the best defence is not just faster patching, but narrower privilege, stronger provenance and tighter release gating. The practitioner conclusion is simple: reduce the number of identities and systems that can create trusted software.
Automated remediation is part of governance, not just workflow efficiency. The article shows that security value only appears when findings are routed, verified and closed with evidence. That makes remediation ownership, service-level targets and closure validation core controls for software supply chain programmes. Teams should measure whether their process can move from exposure discovery to confirmed removal without manual churn.
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.
- Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
- Read next: AI Supply Chain Security and AI-BOM Guide
What this signals
Blast-radius control is becoming the practical centre of software supply chain security. Security teams can no longer rely on component lists alone, because the same dependency can be harmless in one environment and urgent in another. The programme question is whether exposure context, ownership and release authority are joined tightly enough to stop a trusted change from becoming a widely distributed compromise.
Identity controls now determine whether supply chain security is enforceable. Maintainer accounts, signing keys, CI/CD service accounts and repository permissions shape who can create trusted software, which means IAM and PAM decisions directly affect software resilience. The next maturity step is not more scanning; it is tighter governance over the identities that can alter production-bound artifacts.
Software supply chain security now depends on the ability to move from detection to verified closure. A finding that sits unowned across fragmented tools is still live risk, even if it is well understood technically. The organisations that improve fastest will be the ones that connect evidence, ownership and remediation in one workflow rather than treating them as separate programmes.
For practitioners
- Map build and release identities Inventory every maintainer, CI/CD service account, signing key and repository role that can change a release path, then assign explicit ownership and review cadence.
- Tie SBOMs to live application context Link each SBOM to the application, version, repository, image and environment so teams can see where a vulnerable component is actually deployed.
- Prioritise by reachability and business exposure Use exploit intelligence, code reachability, production status, internet exposure and data sensitivity to rank remediation instead of relying on severity alone.
- Protect the build and release pipeline Enforce least privilege, strong authentication, protected branches, isolated builds, signed artifacts and secrets management across the software delivery chain.
- Close the remediation loop with verified closure Require ticket routing to the correct owner, track service-level timelines, then rescan and confirm the vulnerable version is removed before closing the issue.
Key takeaways
- Software supply chain compromise is now a trust and identity problem, not just a vulnerability problem, because attackers target the accounts and systems that can publish trusted releases.
- Visibility must go beyond inventories. SBOMs, VEX and reachability data are what separate theoretical exposure from the issues that can actually affect production.
- The control that matters most is the one that limits who can change software and how quickly compromised releases can be contained, remediated and verified as closed.
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-05 — Overprivileged NHI | Build and release identities with broad access create the abuse path described in the article. |
| NHI-07 — Long-Lived Secrets | Signing keys and pipeline secrets become durable compromise points when they are not rotated or scoped tightly. | |
| Recommendation — Reduce privileged release access and scope CI/CD identities to the minimum required change set. Rotate pipeline secrets and signing credentials on a defined lifecycle, not only after incidents. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article’s attack patterns hinge on account compromise that spreads through trusted delivery paths. |
| Recommendation — Map supply chain detections to credential access and lateral movement tactics in your threat hunting process. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article repeatedly points to access control on build, release and maintainer systems. |
| Recommendation — Review entitlements on CI/CD, package and signing systems under PR.AA-05 and remove unnecessary access. | ||
| CIS Controls v8 | CIS-5 — Account Management | Maintainer, build and release accounts are central to the attack surface discussed. |
| Recommendation — Apply account management controls to inventory, approve and revoke software delivery identities promptly. | ||
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.
- 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.
- Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.
- Vulnerability Exploitability Echange: A machine-readable way of saying whether a known vulnerability is actually exploitable in a specific product or environment. It helps security teams reduce noise by prioritising issues that affect deployed code paths, rather than assuming every published CVE needs the same response.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management in the context of real-world control design. It is suitable for practitioners who need to connect identity governance to software delivery, access control and operational risk.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org