Notifications
Clear all
Topic starter
02/08/2026 12:00 pm
TL;DR: Open-source supply chain security has become an SDLC governance issue as attackers target dependency confusion, typosquatting, repo-jacking, and malicious packages, while Veracode cites research showing 70% of critical security debt originates from third-party code. The practical shift is from reactive scanning to visibility, policy enforcement, and continuous control across the software build chain.
NHIMG editorial — based on content published by Veracode: Open Source Supply Chain Security: Best Practices
By the numbers:
- 70% of critical security debt originates from third-party code.
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
Q: How should security teams govern open source dependencies in CI/CD pipelines?
A: Security teams should treat dependency governance as a release-control problem, not just a scanning problem.
Q: Why do malicious packages keep bypassing software supply chain controls?
A: They bypass controls because build systems often trust registry names, default resolution paths, and automation permissions more than they trust human review.
Q: What do teams get wrong about SBOMs and supply chain visibility?
A: The common mistake is treating SBOMs as a reporting output instead of an enforcement mechanism.
Practitioner guidance
- Implement dependency inventory across the full release chain Use software composition analysis to map direct and transitive dependencies, then assign ownership for each critical package, plugin, and build artefact.
- Enforce package provenance before build execution Require registry allowlists, signature or provenance validation, and package firewall rules before dependencies are pulled into CI/CD.
- Treat SBOM generation as a release gate Generate SBOMs automatically and use them to block releases that contain unapproved components, unsupported licences, or known high-risk dependencies.
What's in the full article
Veracode's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance on SCA, SAST, DAST, package firewall, and container security integration.
- Practical advice on automating SBOMs and policy enforcement across the SDLC.
- Examples of how to reduce workflow friction while keeping developer tooling integrated into CI/CD.
- Discussion of how dynamic risk scoring and automated triage can be used to prioritise remediation.
👉 Read Veracode's analysis of open source supply chain security best practices →
Open source supply chain security: what should engineering teams change now?
Explore further
02/08/2026 1:07 pm
Third-party code risk is really trust-boundary risk. Open source supply chain security fails when organisations treat dependency review as a software issue instead of a trust and access issue. The build pipeline, package registry, signing service, and deploy automation all carry non-human identities that can widen blast radius if they are over-privileged or poorly segmented. Practitioners should govern these identities as part of the release chain, not as an afterthought.
A question worth separating out:
Q: How should organisations reduce the blast radius of build and deploy identities?
A: Limit the permissions of package managers, signing services, and deployment automation to the smallest set needed for their task. Separate fetch, sign, and promote functions, rotate required secrets, and prefer workload identity where feasible. That prevents one compromised automation account from controlling the entire release chain.
👉 Read our full editorial: Open source supply chain risk is now an SDLC governance problem
