Software supply chain risk management needs governance, not just scanning

At a glance

What this is: This is a Veracode guide arguing that software supply chain risk management must cover third-party code, build pipelines, dependency visibility, and SBOM-driven control.

Why it matters: It matters because software delivery now depends on identity-bearing access such as maintainer accounts, CI/CD tokens, and pipeline credentials, which can turn dependency risk into a governance problem.

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

👉 Read Veracode's guide to software supply chain risk management

Context

Software supply chain risk management is the discipline of controlling what enters a build, how it is verified, and what trust is granted to it once it is inside the pipeline. The core failure is not only code defects but the governance gap created when teams treat third-party software as interchangeable with internal code without equally strong review and access control.

The identity intersection is practical rather than theoretical. Package maintainers, CI/CD service accounts, registry tokens, and signing or publishing credentials all function as non-human identities, so weaknesses in secret handling, privilege scoping, and pipeline trust can convert dependency risk into direct compromise. That is why the article’s starting position is typical for modern software teams, but still too reactive for current threat conditions.

Key questions

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. By then, the issue may have propagated across multiple environments. Continuous upstream enforcement is needed because late detection does not stop distribution.

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. If those credentials are long-lived or broadly scoped, attackers can turn one compromise into downstream package poisoning or secret theft. Treat them as privileged access paths with rotation, least privilege, and immediate revocation on suspicion.

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. Evidence should include current inventories, SBOM use, defined response workflows, and contractual obligations that make vendors disclose incidents and security changes.

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.

Technical breakdown

How typosquatting and dependency confusion reach the build pipeline

Typosquatting works by exploiting human error in package selection, while dependency confusion abuses build systems that trust package precedence rules. Both attacks aim to move malicious code into the software delivery pipeline before security review can intervene. Once the package is installed, lifecycle hooks such as postinstall scripts can execute automatically, which turns a normal dependency fetch into code execution. The architectural problem is that build-time trust is often broader than runtime trust, and registries are treated as authoritative without enough provenance checking.

Practical implication: enforce package allowlisting and provenance checks before build execution, not after detection.

Why transitive dependencies create hidden exposure

Direct dependencies are only the visible layer. Transitive dependencies, the dependencies of dependencies, are where many organisations lose practical oversight because the tree becomes too deep to inspect manually. This creates a blind spot where a vulnerable or malicious component can enter without being named in the application manifest. Software composition analysis and SBOM generation exist to reduce that blind spot, but they only help if teams use them as governance inputs rather than compliance artefacts.

Practical implication: map and review transitive dependencies as part of release governance, not as a periodic audit exercise.

How maintainer credentials and CI/CD tokens become high-value access

Open-source ecosystems rely on trust in maintainers, publishers, and automation accounts. Attackers often target maintainer credentials through phishing or exploit exposed pipeline tokens because those identities can publish trojanized packages or access sensitive build artefacts. In identity terms, these are privileged non-human identities with broad delegated access. If secrets are long-lived, over-scoped, or reused across environments, a compromise in one place can cascade into supply chain abuse across many downstream consumers.

Practical implication: rotate and scope publishing tokens tightly, and treat maintainer and pipeline identities as privileged access paths.

Threat narrative

Attacker objective: The attacker aims to reach trusted build credentials and use them to publish malware or move laterally through downstream software supply chains.

1. Entry occurs when a developer installs a typosquatted or confused dependency that is trusted by the build system.
2. Escalation happens when the malicious package executes a postinstall script inside CI/CD and captures environment tokens or build context.
3. Impact follows when stolen tokens or malicious publication access are used to poison downstream artifacts, exfiltrate data, or expand compromise into other projects.

NHI Mgmt Group analysis

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.

Transitive dependency opacity is the named concept that best explains this risk. Teams often know what they declared, but not what their declared components silently pull in. That gap defeats manual review and makes SBOMs valuable only when they are operationalised into change control and exception handling. Practitioners should assume hidden depth, not visible manifests, defines the true attack surface.

Package trust needs provenance, not just reputation. Typosquatting, dependency confusion, and maintainer compromise all exploit the assumption that a package name is proof of legitimacy. It is not. Stronger governance comes from verifying source, build origin, and signing status before execution. Practitioners should require provenance checks wherever code is pulled into automated delivery.

Secrets in build systems remain a weak link because the delivery pipeline is often over-privileged. The article’s attack example shows that a single compromised package can harvest tokens with enough authority to publish or tamper with artifacts. That is a classic blast-radius problem. Practitioners should narrow token scope and remove standing privilege from pipeline identities.

Software Bill of Materials data only becomes useful when it drives remediation priority. Inventory without action simply documents exposure after the fact. The useful governance model links dependency visibility to risk-based triage, legal review, and release gating. Practitioners should connect SBOM output to control decisions, not compliance reporting alone.

What this signals

Software supply chain programmes are increasingly converging with identity governance because the most dangerous dependencies are often introduced through privileged non-human identities. Build tokens, package maintainer accounts, and signing keys need the same lifecycle discipline that teams already apply to other sensitive access paths. Transitive dependency opacity: hidden dependency depth is now a governance risk, not just a software quality issue.

If teams want a more durable control model, they need to treat package provenance and secret exposure as linked problems. NIST Cybersecurity Framework 2.0 is useful for structuring governance across identify, protect, detect, respond, and recover, but the operational signal comes from whether packages are blocked before execution and whether compromised credentials can be revoked fast enough to matter.

The reader-level question is whether delivery pipelines still assume trust by default. That assumption fails when typosquatting, dependency confusion, and maintainer compromise are all viable entry paths. Teams should prepare for tighter provenance enforcement, more SBOM-driven release decisions, and stronger coordination between application security and identity governance.

For practitioners

• Lock down package ingestion policies Block packages that arrive with risky install hooks, suspicious naming patterns, or unknown provenance. Apply policy-as-code in the repository and build stages so unapproved dependencies never reach execution.
• 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. Rotate credentials on a fixed cadence and immediately after maintainer changes.
• 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.
• Separate maintainer trust from runtime trust Verify package origin, signing status, and maintainer ownership before build execution. Do not let package reputation alone determine whether code is accepted into the delivery chain.

Key takeaways

• Software supply chain risk management is ultimately a governance problem because third-party code, pipeline tokens, and maintainer credentials all expand the trust boundary.
• The article’s example of a typosquatted npm package shows how a build-time compromise can turn a small dependency error into token theft and downstream package abuse.
• Practitioners should combine provenance checks, SBOM-driven release control, and privileged identity management for CI/CD to reduce the blast radius of dependency compromise.

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.
• Typosquatting: A supply chain attack that uses package names that are small misspellings of popular libraries. The goal is to exploit developer error or automation shortcuts so malicious code is downloaded and executed as if it were legitimate.
• Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.
• Transitive Dependency: A dependency pulled in indirectly by another package rather than declared by the application itself. Transitive dependencies matter because they extend the trust chain, often creating hidden exposure that teams cannot see without automated inventory and review.

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.

👉 Veracode's full guide covers the package firewall, SBOM workflow, and remediation framework in more operational detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle controls. It is designed for practitioners who need to connect access governance to the wider security programme.