Software supply chain risk management needs governance, not just scanning

At a glance

What this is: Veracode argues that software supply chain risk management is a governance problem, not just a scanning problem, because third-party packages, transitive dependencies, and compromised maintainer credentials can all become attacker entry points.

Why it matters: This matters to IAM and NHI practitioners because build systems, CI/CD tokens, package maintainer access, and third-party integrations behave like identities and privileges that need lifecycle control, not just detection.

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.

Context

Software supply chain risk management is the discipline of controlling what enters the development pipeline, not just checking what ships at the end. In practice, that means governing package selection, dependency trust, build-time execution, SBOM accuracy, and remediation workflows across the whole lifecycle.

The identity angle is real because build systems, CI/CD tokens, and package maintainer credentials act as trusted access paths inside software delivery. When those paths are abused, the problem is not only code risk but also delegated access, third-party trust, and non-human identity governance in the software factory.

Key questions

Q: What breaks when software supply chain security relies only on SCA scanning?

A: SCA-only programmes generate visibility without decision quality. They identify vulnerable packages, but they do not tell teams whether a dependency is reachable, whether a finding is exploitable in context, or which issues matter most to the business. The result is alert fatigue, slow remediation, and a backlog that hides the exposures attackers are most likely to use.

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. Once malicious code executes, it can steal non-human credentials at the moment they are most accessible, then reuse them exactly as legitimate automation would.

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. Those signals usually mean trust decisions are being made by package name alone, which is too weak for modern software supply chains.

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.

Technical breakdown

Why scanning misses supply chain risk

Scanning is a detection control, but software supply chain risk often enters earlier, at package selection, dependency resolution, or build-time execution. A vulnerable component is only one failure mode. Typosquatting, dependency confusion, package hijacking, malicious postinstall scripts, and compromised maintainer accounts all bypass a scanner if the control model assumes the codebase is already trusted. The real issue is that modern delivery pipelines ingest code, metadata, and automation from external sources at machine speed. That makes governance over provenance, policy, and trust boundaries the primary control plane.

Practical implication: Treat scanning as one signal in a broader control model, not the boundary that decides whether software is safe.

How third-party packages become trusted execution paths

Third-party packages do more than add code. They can trigger install hooks, inherit build permissions, and execute inside CI/CD environments with access to secrets, tokens, and deployment credentials. That is why a malicious package is not just an application security issue but a delegated-access issue. If the pipeline auto-installs dependencies, trusts package names too readily, or allows broad token scope, the attacker can convert a harmless-looking dependency into a foothold. This is where software supply chain risk overlaps with NHI governance: ephemeral build identities still need least privilege, inventory, and offboarding logic.

Practical implication: Constrain what packages can execute in build environments and narrow the permissions of CI/CD identities that handle them.

Why SBOMs change the control model

An SBOM is more than a compliance artifact. It is the machine-readable inventory that lets teams trace what software is actually present, including transitive dependencies that manual review usually misses. Without that inventory, teams cannot reliably answer which applications contain a vulnerable component, which packages came from which source, or how a compromised dependency might propagate. SBOMs only create value, however, when they are generated automatically, kept current, and connected to remediation workflows. Otherwise they become static documentation that lags behind the state of the build.

Practical implication: Generate and maintain SBOMs as living inventory, then link them to triage and remediation decisions.

Threat narrative

Attacker objective: The attacker wants to turn trusted software delivery infrastructure into a repeatable channel for code injection, secret theft, and downstream compromise.

1. Entry occurs when an attacker publishes a typosquatted, hijacked, or otherwise malicious package that developers or build systems pull in as if it were trusted.
2. Credential access follows when the package executes inside the build environment and steals CI/CD tokens, maintainer credentials, or other secrets available to the pipeline.
3. Impact comes when those stolen credentials are used to publish more malicious artifacts, pivot into downstream systems, or widen the compromise across the software delivery chain.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
• Vercel Context.ai OAuth Supply Chain Breach: Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Transitive dependency risk creates control blindness: teams often see the direct dependency layer and assume they understand exposure, but the article correctly points out that the dangerous component may sit several layers deep. That means the real failure mode is not just vulnerability presence. It is incomplete inventory and incomplete trust mapping. Practitioners should read this as a sign that dependency governance must extend through the full graph, not the top level only.

Package execution in CI/CD is a delegated-privilege decision, not a convenience feature: postinstall scripts, build hooks, and pipeline tokens can turn a download into runtime execution with access to secrets. That elevates software supply chain controls into the same governance class as privileged access management. The named concept here is pipeline trust leakage, where unreviewed package behaviour inherits more privilege than the organisation intended. The practical conclusion is to shrink executable trust inside the build path.

Verifiable inventory is the control that ties governance together: SBOMs, policy-as-code, package allowlisting, and remediation workflows only work when the organisation can prove what is present and where it entered. That makes visibility the prerequisite for both security and compliance, especially under frameworks that expect traceability across the software lifecycle. The practical conclusion is to make inventory, provenance, and remediation one governance loop.

Open-source risk management is becoming board-level resilience work: the article's emphasis on regulatory pressure is a reminder that supply chain integrity is no longer a narrow engineering concern. When third-party code dominates the product, resilience depends on deciding which external dependencies can be trusted, under what conditions, and with what revocation path. The practical conclusion is to align software supply chain controls with enterprise risk governance, not just AppSec tooling.

From our research library:

• 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.
• Read next: NHI Lifecycle Management Guide

What this signals

Pipeline trust leakage: software supply chain exposure is not only about vulnerable code, but about how build systems inherit permission to execute, publish, and exfiltrate. When package install steps can reach secrets or deployment tokens, the control problem shifts from detection to privilege containment.

For IAM and PAM teams, the lesson is that CI/CD tokens, maintainer credentials, and automation accounts deserve the same lifecycle discipline as privileged human access. Scope them narrowly, segment publish rights from build rights, and assume that dependency execution can become a credential exposure path if left unchecked.

For practitioners

• 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.
• Make SBOM generation part of release governance Generate SBOMs automatically at build time and tie them to approval, incident response, and vulnerability remediation workflows.
• Prioritise remediation by exploit path, not just severity Rank vulnerable dependencies by whether they are actually reachable, whether they execute in trusted pipelines, and whether they expose secrets or publish paths.

Key takeaways

• Software supply chain risk management fails when organisations stop at scanning and do not govern package trust, build execution, and dependency provenance.
• Third-party and transitive code create measurable exposure, with 70% of critical security debt coming from third-party code in the report cited by Veracode.
• The most effective controls combine inventory, package execution policy, SBOM generation, and tightly scoped CI/CD identities.

Key terms

• Software Supply Chain Risk: Software supply chain risk is the chance that code, build, deployment, or dependency paths are altered in ways that affect downstream systems. For AI code assistants, this risk rises when the tool can change source, trigger pipelines, or influence infrastructure definitions.
• Transitive Dependency: A transitive dependency is a package that your software uses indirectly through another library rather than calling it directly. These dependencies often hide in Java estates, which makes visibility and runtime validation necessary to understand what code is actually present and active.
• SBOM: A software bill of materials is an inventory of components, dependencies, and often transitive packages used in an application or build. It gives defenders visibility into what entered the software supply chain and helps spot risky or newly introduced dependencies.
• Package Typosquatting: Package typosquatting uses names that look like legitimate dependencies to trick developers or automation into installing malicious code. It exploits human familiarity and weak controls around package namespaces, especially when installation workflows prioritise convenience over verification.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, helps practitioners connect machine identity, secrets management, and access governance to real-world delivery pipelines. It is useful for teams that need to apply identity controls to CI/CD, third-party integrations, and automation accounts.