Topic starter
02/08/2026 11:37 am
TL;DR: Most organisations still carry at least one high, critical, or apocalyptic supply chain issue, OXSecurity reports, because trust now stretches across third-party code, pipeline identities, and reusable secrets. Modern SDLCs need governance over provenance and release authority, not just more findings.
Editorial analysis by NHI Mgmt Group, based on content published by OXSecurity: “Your Guide to Software Supply Chain Security: Everything you need to know”.
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.
Key questions
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.
Q: How do organisations prove their software supply chain controls are actually working?
A: Use evidence, not assumptions.
A: Teams detect many issues but still miss the pathways that let compromised components move through the SDLC.
Practitioner guidance
- 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.
Bottom line: Software supply chain security is widening because modern SDLCs spread trust across third-party code, pipeline identities, and secrets that attackers can reuse.
Glossary terms: Software Supply Chain Security, SBOM, CI/CD Pipeline, Dependency Confusion
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
02/08/2026 12:50 pm
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.
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.
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Software supply chain security gaps are widening across modern SDLCs