Notifications
Clear all
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.
NHIMG editorial — based on content published by Veracode: Beyond Your Code: A Guide to Software Supply Chain Risk Management
By the numbers:
- 70% of critical security debt originates from third-party code
- A malicious npm package named @acitons/artifact was discovered in November 2025
Questions worth separating out
Q: What breaks when software supply chain controls rely only on post-build scanning?
A: Post-build scanning often finds problems after risky code, secrets, or malicious dependencies have already entered repositories, images, or deployment pipelines.
Q: Why do CI/CD tokens and maintainer credentials matter so much in supply chain security?
A: They are the identities that can publish packages, access build systems, and sign artifacts.
Q: How do security teams know if software supply chain governance is working?
A: It is working when teams can identify which software and dependencies are deployed, match them to critical environments, and prove they can act quickly on vulnerability disclosures.
Practitioner guidance
- Lock down package ingestion policies Block packages that arrive with risky install hooks, suspicious naming patterns, or unknown provenance.
- Treat CI/CD tokens as privileged non-human identities Inventory build and publishing tokens, remove standing privilege, and scope each token to the minimum registry or repository action it needs.
- Operationalise SBOMs for release gating Generate SBOMs automatically in the pipeline, then use them to block releases with unreviewed transitive dependencies, unapproved licenses, or known malicious packages.
What's in the full article
Veracode's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step package firewall policy design for blocking typosquats, suspicious install hooks, and unapproved registries.
- Operational SBOM workflows for release gating, dependency review, and incident response triage.
- Risk-based remediation prioritisation that separates exploitability from raw CVSS score and developer convenience.
- Developer workflow guidance for handling transitive dependencies, license exposure, and CI/CD hygiene.
👉 Read Veracode's guide to software supply chain risk management →
Software supply chain risk management: what IAM teams should factor in?
Explore further
02/08/2026 1:19 pm
Software supply chain governance is now an identity problem as much as a code problem. The article correctly frames scanning as insufficient because the real control surface is the trust granted to packages, maintainers, and pipeline identities. When CI/CD tokens and registry credentials are effectively non-human identities, governance must cover issuance, scope, and revocation, not just vulnerability findings. Practitioners should treat build trust as a privileged access domain.
A question worth separating out:
Q: Who is accountable when a malicious dependency enters a build pipeline?
A: Accountability is shared across engineering, security, and platform teams, but the control owner should be clear. Dependency intake, script execution, and publishing credentials are all governance points. In practice, the teams responsible for CI/CD, package policy, and non-human credential lifecycle must define who can approve, who can execute, and who can revoke.
👉 Read our full editorial: Software supply chain risk management needs governance, not just scanning
