Topic starter
02/08/2026 12:17 pm
TL;DR: OWASP’s Top 10:2025 moves Software Supply Chain Failures to third place, reflecting upstream compromise patterns such as dependency substitution, tampered build pipelines and unvalidated third-party packages, according to Anomali citing OWASP analysis of more than 220,000 CVEs. The control problem is no longer isolated code review but trust in the software ecosystem around the application.
Editorial analysis by NHI Mgmt Group, based on content published by Anomali: “Anomali Cyber Watch: OWASP Top Ten Updates, AI Voice Scams, DanaBot Malware, Lumma Stealer, and More”.
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.
Q: Why do misconfigured build pipelines create such a high risk for software supply chains?
A: Misconfigured build pipelines are risky because they can let attackers influence build steps, inject untrusted input, or execute code during the delivery process.
Q: How do security teams know if dependency controls are actually working?
A: Look for whether build systems prevent unauthorised version drift, whether package provenance is checked before install, and whether secret-handling code is isolated from broad application reach.
Practitioner guidance
- Implement provenance checks for all dependencies Require signed metadata, source attribution and repository allowlisting before third-party code can enter builds or deployment paths.
- Lock down build and release identities Treat pipeline service accounts, signing keys and automation tokens as privileged identities with narrow scope and rapid revocation paths.
- Add artifact attestation to release gates Block promotion unless the artifact matches the expected source commit, build process and signing policy.
Bottom line: Software supply chain failures are now a core application-risk issue because upstream compromise can enter through trusted dependencies, build systems and registries.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:18 pm
Software supply chain failures are now a governance problem, not a narrow developer problem. Once package trust, build integrity and artifact provenance become central risk drivers, the control question moves beyond code quality into assurance over the entire delivery chain. That puts procurement, engineering and security into the same governance conversation, because compromise can enter through any of them. Practitioners should treat software supply chain trust as a board-level assurance issue, not a tooling choice.
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.
A question worth separating out:
Q: Should organisations prioritise software supply chain controls over code scanning?
A: They should prioritise both, but supply chain controls come first when the main risk is untrusted code entering the pipeline. Code scanning only helps after code exists, while provenance checks, signing and release governance reduce the chance that malicious code is accepted in the first place. That is the stronger control boundary.
👉 Read our full editorial: OWASP Top 10 shifts put software supply chain failures in focus