Notifications
Clear all
Topic starter
02/08/2026 11:24 am
TL;DR: Enterprises face faster-moving software supply chain risk as 82% report security debt, 66% of critical long-lived vulnerabilities originate in third-party code, and remediation lags persist, according to Veracode and cited breach data. Security teams now need continuous visibility, enforced build integrity, and tighter control over the identities and secrets that move through CI/CD and AI-assisted development.
NHIMG editorial — based on content published by Veracode: Top Software Supply Chain Security Best Practices for Enterprises
By the numbers:
- Eighty-two percent of organizations are currently carrying security debt, up 11% year-over-year.
- Only 26% of critical vulnerabilities listed in CISA’s Known Exploited Vulnerabilities catalog were fully remediated, down from 38% the prior year.
- Nearly 45% of AI-generated code contains known security vulnerabilities when proper security guidance is not provided.
Questions worth separating out
Q: How should security teams govern software supply chain risk when CI/CD identities can publish code?
A: Security teams should treat CI/CD accounts, signing keys, and release tokens as high-risk identities with least privilege, scoped access, and rotation requirements.
Q: Why do third-party dependencies create more supply chain risk than first-party code?
A: Third-party dependencies expand trust beyond the team’s direct control.
Q: What do security teams get wrong about AI-generated code risk?
A: They often focus on catching insecure output after code is written, which is too late for AI-native workflows.
Practitioner guidance
- Implement SBOM-driven dependency visibility Inventory direct and transitive dependencies across every build line and tie each component to an owner, a risk rating, and a remediation path.
- Lock down CI/CD and release identities Reduce the privilege of build service accounts, rotate tokens, and separate signing, publishing, and deployment permissions so one compromise cannot move end to end.
- Enforce policy gates on AI-generated code Require AI-assisted commits to pass the same static analysis, dependency validation, and approval thresholds as manual code, with extra review for new package names and unexpected imports.
What's in the full article
Veracode's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step SBOM implementation guidance for enterprise software portfolios
- Operational examples of CI/CD policy gates for dependency and vulnerability control
- Detailed SLSA and SSDF mapping for build integrity and compliance evidence
- Vendor-specific Blueprint guidance for assessing and closing supply chain gaps
👉 Read Veracode's analysis of software supply chain security best practices →
Software supply chain security and identity controls: what teams need now?
Explore further
02/08/2026 12:41 pm
Software supply chain security is increasingly an identity governance problem. The article correctly shows that the most dangerous trust decisions now happen in build systems, registries, and automation accounts. Those are identity decisions because tokens, service accounts, and signing keys determine who can publish, modify, or deploy code. Practitioners should treat pipeline identities as part of the enterprise identity plane, not as a separate DevOps concern.
A question worth separating out:
Q: Which frameworks should guide software supply chain security programmes?
A: NIST SSDF and SLSA are the most useful starting points because they connect secure development practices to build integrity and provenance. Teams should map dependency governance, release attestation, and remediation SLAs to those frameworks, then use continuous monitoring to prove the controls are working in production.
👉 Read our full editorial: Software supply chain security best practices now hinge on identity controls
