Topic starter
02/08/2026 12:18 pm
TL;DR: Software supply chain risk management is shifting from vulnerability scanning to governance, visibility, and control across third-party packages, transitive dependencies, SBOMs, and remediation workflows, according to Veracode. The identity angle is clear where build systems, CI/CD tokens, and maintainer credentials become trusted access paths that attackers can exploit.
Editorial analysis by NHI Mgmt Group, based on content published by Veracode: “Beyond Your Code: A Guide to Software Supply Chain Risk Management”.
By the numbers:
- The State of Software Security 2025 report shows that 70% of critical security debt originates from third-party code, making open-source risk management a critical function for modern development teams.
Key questions
Q: What breaks when software supply chain security relies only on SCA scanning?
A: SCA-only programmes generate visibility without decision quality.
Q: Why do compromised packages create such a large identity risk?
A: Because they often run inside environments that already contain reusable secrets, tokens, and service accounts.
Q: What are the signs that dependency governance is failing?
A: Look for first-seen packages reaching builds without provenance checks, repeated typosquats, rapid version churn, and helper packages that mimic internal or AI tooling names.
Practitioner guidance
- Implement package execution controls Block or sandbox dependency install scripts, especially in CI/CD environments that can reach secrets or deployment pathways.
- Inventory transitive dependencies continuously Maintain an automated dependency graph that includes direct and transitive packages, then reconcile it against build and release pipelines.
- Constrain build identity privileges Scope CI/CD tokens and maintainer-style automation credentials to the minimum required permissions, and separate publish rights from build rights.
Bottom line: Software supply chain risk management fails when organisations stop at scanning and do not govern package trust, build execution, and dependency provenance.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:19 pm
Software supply chain governance is now an identity problem as much as a code problem: once build systems, registries, and maintainer accounts are trusted to act on behalf of the organisation, they become non-human access paths that need lifecycle control. Scanners can identify known flaws, but they do not govern who or what is authorised to execute in the pipeline. The practical conclusion is that software delivery must be treated as a governed access environment, not a passive code intake process.
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.
- Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: How should teams balance package velocity with supply chain assurance?
A: Treat package intake as a risk decision rather than a developer convenience problem. The right balance is fast approval for well understood dependencies and tighter controls for new, unverified, or executable packages. That usually means policy-based allowlisting, current inventory, and segregated privileges for build and release actions.
👉 Read our full editorial: Software supply chain risk management needs governance, not just scanning