TL;DR: Software supply chain security is under pressure from widespread dependency risk, secrets exposure, and pipeline abuse, with OXSecurity citing 95% of organisations as having at least one high, critical, or apocalyptic issue in their supply chain. The control problem is no longer visibility alone, but whether teams can prioritise, verify, and contain risk before compromised components move through the SDLC.
At a glance
What this is: OXSecurity argues that software supply chain security risk is rising across modern SDLCs because dependency sprawl, secrets leakage, and pipeline abuse create multiple paths to compromise.
Why it matters: AppSec, DevSecOps, and identity teams need to treat supply chain exposure as a governance problem as much as a scanning problem, because compromised components and credentials can turn one weakness into broad downstream impact.
By the numbers:
- 95% of organisations have at least one high, critical, or apocalyptic risk within their software supply chain.
- Supply chain and third-party risks accounted for 15% of breaches in 2023-2024.
- That share represented a 68% year-over-year increase.
Context
Software supply chain security is the discipline of controlling risk across the tools, dependencies, libraries, and build processes that produce software. In modern SDLCs, those components are tightly interconnected, so one compromised package, repository, or pipeline can propagate weakness far beyond the original entry point.
The governance gap is that many organisations still treat this as a visibility problem alone. In practice, the harder issue is trust across third-party code, CI/CD pipelines, and secrets handling, where identity and access decisions determine whether an attacker can move from a single weak component to wider application compromise.
Key questions
A: Teams detect many issues but still miss the pathways that let compromised components move through the SDLC. The result is weaker prioritisation, slower containment, and a false sense of coverage because the control is watching artefacts without governing the identities and pipelines that publish them.
Q: Why do exposed secrets in CI/CD pipelines create such a large blast radius?
A: CI/CD systems often hold cloud credentials, deployment tokens, and repository access in the same execution context. When malicious code runs there, it can collect secrets from environment variables, files, and process memory, then reuse them across cloud and source control. The more privileged the runner, the larger the downstream impact.
Q: How do organisations prove their software supply chain controls are actually working?
A: Use evidence, not assumptions. Track reduction in security debt, remediation time, false positive rates, blocked package events, and audit-ready reports over time. If the tool cannot show measurable change in dependency risk and developer behaviour, it is only producing activity, not assurance.
Q: Should AppSec teams prioritise SBOMs or posture management first?
A: Both matter, but the sequencing depends on the problem. SBOMs improve component visibility, while posture management helps teams decide which issues threaten release integrity or downstream environments. If the environment is already complex, posture management usually adds faster decision value because it connects findings to blast radius.
Technical breakdown
Dependency trust and transitive exposure in the SDLC
Modern software supply chains are not just direct code dependencies. They also include transitive libraries, build tools, registries, container layers, and metadata that all influence what ultimately ships. A single compromised package can reach many downstream environments because modern release processes repeatedly reuse components and trust the provenance of upstream inputs. That means the real security problem is not only vulnerable code, but inherited trust across multiple layers of the build path. When organisations cannot trace which dependency introduced risk, remediation becomes slow and incomplete.
Practical implication: map transitive dependencies and enforce provenance checks before release rather than relying on late-stage vulnerability scanning.
Secrets exposure and pipeline abuse
Secrets in repositories, build scripts, and CI/CD environments turn ordinary development workflows into credential distribution channels. API keys, tokens, and passwords often give attackers direct access to infrastructure, package registries, or deployment systems, especially when contributor permissions are broader than necessary. In parallel, an unsecured pipeline can become a delivery mechanism for malicious code, malicious installation scripts, or poisoned updates. This is where software supply chain security intersects directly with identity governance: the identity attached to the pipeline, the package maintainer, and the deployed service all determine how far abuse can spread.
Practical implication: govern pipeline identities and secret handling together, because access scope and credential leakage usually determine blast radius.
Why application security posture management needs supply chain context
Application security posture management helps by correlating code, dependencies, and vulnerabilities across the lifecycle rather than treating each alert as an isolated event. That matters because supply chain risk is often contextual, not binary. A medium-severity issue in a widely deployed component can matter more than a high-severity issue in a rarely used service. The operational challenge is triage: teams need enough context to separate hygiene debt from issues that create a realistic attack path. Without that context, alert fatigue obscures the paths most likely to be exploited.
Practical implication: prioritise findings by reach, trust relationships, and deployment scope, not by severity score alone.
Threat narrative
Attacker objective: The attacker wants to turn one trusted software component or pipeline foothold into broad downstream compromise across multiple organisations.
- Entry typically begins when an attacker targets a third-party dependency, poisoned package, or exposed CI/CD secret inside the software development path.
- Credential access or code execution follows when the attacker abuses maintainer access, pipeline tokens, or malicious installation logic to alter trusted software artefacts.
- Escalation occurs as the tainted package, backdoor, or pipeline artifact propagates into multiple downstream builds and environments.
- Impact is achieved when compromised software or stolen secrets provide access to production systems, sensitive data, or widely used customer environments.
Breaches seen in the wild
- GitHub code signing certificate theft 2022: A machine account's compromised token cloned GitHub's Desktop and Atom repos, exposing encrypted signing certificates later revoked.
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next 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 and trust governance problem, not just a code-quality problem. The article shows that attacks move through maintainers, tokens, build systems, and third-party dependencies, which means the security boundary is defined by who and what is trusted to publish software. That puts identity control, provenance, and lifecycle oversight at the centre of the risk model. Practitioners should treat software trust as a governed access pathway, not a static inventory task.
Secrets leakage is the most practical bridge between application security and NHI governance. API keys, passwords, and pipeline tokens are non-human credentials, and their exposure turns development systems into direct attack infrastructure. Once those credentials are reused across repositories or environments, a single leak can create an NHI reuse problem that conventional AppSec tooling may not fully contain. The governing issue is who can mint, store, and reuse machine credentials, not only whether the code contains a flaw.
Context is the real control gap in modern AppSec. The article’s point about thousands of alerts and nine high-severity risks per organisation shows that raw detection volume does not produce security. Teams need a named concept here: dependency blast radius, meaning the number of systems that inherit trust from a single library, package, or pipeline artefact. Practitioners should prioritise controls that reduce downstream spread, because blast radius drives business impact more than vulnerability count.
Supply chain risk exposes the weakness of treating third-party assurance as a one-time checkbox. The article’s examples show that vendors, open-source maintainers, and internal builders all sit on the same trust chain. That means governance has to extend across onboarding, monitoring, and offboarding of software suppliers and machine identities. Security leaders should assume that assurance decays unless it is continuously revalidated against actual build and deployment behaviour.
AppSec and DevSecOps teams now need a shared model for policy enforcement across the SDLC. The article’s emphasis on SBOMs, pipeline visibility, and posture management points to a future where static vulnerability management is insufficient on its own. The stronger operating model is contextual governance of software lineage, secrets, and release authority. Practitioners should use that model to decide which risks stop a release and which risks move to monitored remediation.
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: CI/CD Pipeline Identity Security Guide
What this signals
Dependency blast radius: supply chain security fails when teams measure vulnerability volume but not the number of downstream systems that inherit trust from a single package or pipeline artefact. The practical shift is toward governance that ranks components by reuse, privilege, and release reach, not by alert count alone.
Software development now behaves like an identity ecosystem as much as an engineering process. Pipeline tokens, maintainer access, and third-party dependencies all need continuous oversight, because once a machine credential or trusted package is reused across environments, compromise scales faster than conventional AppSec response cycles can absorb.
For practitioners
- Inventory software lineage end to end Map direct and transitive dependencies, build tools, registries, and release artefacts so teams can see where trust enters the SDLC and where it propagates.
- Tighten control of pipeline identities and tokens Restrict who and what can publish, approve, or deploy code, and rotate tokens that can modify repositories, package feeds, or CI/CD jobs.
- Remove exposed secrets from repositories and logs Search code, build output, and installation scripts for API keys, passwords, and tokens, then revoke anything that has been exposed.
- Use SBOMs as operational evidence Request or generate SBOMs for in-house and third-party software so vulnerability analysis can be tied to the exact components that are shipped.
- Prioritise release-blocking risk by blast radius Score findings by how widely a component is reused, how much privilege it carries, and how far a compromise would spread across environments.
Key takeaways
- Software supply chain security is widening because modern SDLCs spread trust across third-party code, pipeline identities, and secrets that attackers can reuse.
- The evidence points to a persistent governance problem, with most organisations carrying multiple high-severity risks and supply chain incidents continuing to grow.
- Practitioners need to move from visibility-first scanning to context-driven control of provenance, credential scope, and release authority.
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, OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article repeatedly cites exposed secrets as a common supply chain failure mode. |
| NHI-03 — Vulnerable Third-Party NHI | Third-party dependencies and vendor trust are central to the supply chain risk described here. | |
| NHI-07 — Long-Lived Secrets | The article links pipeline compromise to reusable credentials that persist across SDLC stages. | |
| Recommendation — Scan repositories, logs, and build artefacts for leaked secrets and revoke exposed credentials immediately. Assess third-party dependency trust continuously and remove unapproved or high-risk software inputs. Reduce credential lifetime in build and deployment pipelines to limit reuse after exposure. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Leaked API keys and tokens undermine the authentication layer of software delivery systems. |
| Recommendation — Harden API and token authentication paths so exposed credentials cannot be reused for publishing or deployment. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attack patterns described rely on credential access followed by propagation through trusted paths. |
| Recommendation — Map supply chain threats to credential access and lateral movement to improve detection and response coverage. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article highlights excessive contributor privilege and pipeline access as root causes of abuse. |
| Recommendation — Review permissions and entitlements for build, release, and package publishing systems against least-privilege needs. | ||
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.
- SBOM: A software bill of materials is an inventory of components, dependencies, and often transitive packages used in an application or build. It gives defenders visibility into what entered the software supply chain and helps spot risky or newly introduced dependencies.
- CI/CD Pipeline: The automated systems that build, test, and deploy software, often holding privileged credentials for source control, cloud access, and release automation. When these pipelines leak secrets, they can turn a software delivery function into a high-trust compromise path.
- Dependency Confusion: A supply chain attack in which a build system resolves a malicious public package instead of an intended internal one because of naming, versioning, or registry precedence. The risk is not only code substitution but automatic execution inside trusted pipelines that already contain valuable credentials.
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 helps security and platform teams connect identity controls to the software and cloud workflows they already operate.
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