Software supply chain security has shifted to dependency governance

At a glance

What this is: Pixee says software supply chain security has moved from securing code developers write to governing the dependencies they assemble, because transitive packages, malicious maintainers, and install-time execution paths now dominate the risk surface.

Why it matters: This matters because AppSec and IAM teams must treat dependency approval, package trust, and remediation workflows as governance problems, not just scanning problems, especially where build tools execute credentials-bearing automation.

By the numbers:

• Open source now appears in 98% of codebases, according to Pixee.
• 64% of the components in those codebases are transitive, according to Pixee.
• The average codebase now carries 1,180 open source components, according to Pixee.

Context

Application security has historically focused on code authorship, but modern software is increasingly assembled from libraries, packages, and transitive dependencies that teams do not directly author or fully review. That shifts the governance problem from only preventing insecure code changes to deciding which external components are safe to admit, trust, and keep in production.

The identity and access angle is real because dependency ecosystems rely on maintainer accounts, CI hooks, package publishing rights, and build-time execution paths that can be abused once trust is granted. In that sense, software supply chain security increasingly overlaps with non-human identity governance, especially around who or what is allowed to publish, install, and execute code inside the build path.

The article frames a typical enterprise problem rather than an outlier case: most codebases now inherit large transitive trees, so the attack surface is structural, not exceptional.

Key questions

Q: What breaks when dependency governance is still treated as a scanner problem?

A: Teams end up with accurate inventories but no practical closure. They can identify vulnerable packages, yet still fail to determine which ones are reachable, which ones can be remediated safely, and which ones need to be fixed at the manifest rather than in source. That leaves the backlog growing while exploitable exposure stays live.

Q: Why do transitive dependencies create more software supply chain risk than direct packages alone?

A: Transitive dependencies hide exposure inside nested libraries that are often missed by top-level package reviews. If defenders only track direct components, they can miss the code attackers are most likely to exploit. A dependency-aware inventory reduces that blind spot and gives teams a realistic view of what is actually present in production.

Q: How should AppSec teams prove whether a vulnerable dependency is actually exploitable in production?

A: AppSec teams should prioritise runtime evidence over static presence checks. If a vulnerable function is actually invoked, a call stack shows the execution path, the service involved, and the context that led to risk. That lets teams separate theoretical exposure from active exploitability, reduce triage noise, and focus remediation on issues that are truly running in production.

Q: Should organisations prioritise dependency approval controls over more package scanning?

A: Yes, when the problem is already visibility rather than discovery. Scanning tells you what exists, but approval controls, install-policy restrictions, and manifest-level remediation determine whether untrusted or vulnerable code can actually enter and persist in the build path.

Technical breakdown

Why transitive dependencies create a governance problem

Transitive dependencies are the packages pulled in by other packages, often several layers away from the code a team explicitly chose. That matters because the risk is no longer limited to first-party code or direct libraries with obvious ownership. A vulnerable function can sit deep in a dependency tree, while a malicious package can enter through a trusted upstream dependency and inherit the trust of the whole chain. In practice, software composition analysis reports inventory, but governance has to answer reachability, provenance, and approval. The attack surface is therefore not just the package list, but the trusted relationship graph behind it.

Practical implication: Practitioners should govern dependency trees as trust chains, not as flat inventories.

How install-time execution turns package trust into code execution

Modern package ecosystems often allow scripts to run during install, which means a dependency can execute code before the application itself ever starts. That makes preinstall, install, and postinstall hooks especially sensitive because they collapse package admission and code execution into the same event. If a maintainer account is compromised, or a package is swapped after approval, that execution path becomes a supply chain entry point. The important distinction is between downloading a package and granting it runtime behaviour in the build process. Once install-time execution is allowed by default, the package manager becomes part of the security boundary.

Practical implication: Restrict install-time execution and review any allowlist as a privileged execution control.

Why reachability analysis is the missing remediation layer

A scanner can identify a vulnerable package, but it cannot tell you whether your application can actually hit the vulnerable code path. Reachability analysis follows call paths through the dependency tree to separate theoretical exposure from executable exposure. That distinction matters because transitive trees create overwhelming noise, and security queues collapse when every finding is treated equally. In dependency governance, the useful question is not how many CVEs exist, but which ones are reachable in the way your code is built and deployed. Without that filter, teams keep tickets open long after the exploitable ones should have been fixed.

Practical implication: Use reachability to prioritise only the dependency findings that your application can actually execute.

Threat narrative

Attacker objective: The attacker wants trusted package distribution to become a credential theft and propagation channel that scales across many downstream projects.

1. Entry occurs when attackers compromise maintainer accounts or publish malicious packages into trusted ecosystems such as npm, PyPI, or Crates.io.
2. Credential access and execution follow when install hooks or poisoned package versions run in build environments and steal developer or cloud credentials.
3. Impact occurs when stolen credentials are used to publish more malicious packages, extend the compromise, and spread the campaign through downstream dependency chains.

Breaches seen in the wild

• Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.

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

Dependency governance is now the centre of software supply chain security. The old model assumed the main problem was insecure code written by developers, so AppSec concentrated on finding flaws in first-party source. That assumption no longer holds when most software is assembled from external components, and a large share of risk sits in transitive dependency chains. The practitioner conclusion is straightforward: governance has to shift from authoring controls to admission, trust, and lifecycle controls for third-party code.

Package ecosystems have become identity systems for code. Maintainer accounts, publish rights, install hooks, and dependency approvals now decide which code is allowed to execute in build pipelines. That makes package trust an identity problem as much as a vulnerability problem, because the wrong account or the wrong approval can turn a previously safe library into an active attacker path. Teams should treat package publishing and install permissions as privileged non-human access, not as routine tooling.

Reachability is the right triage concept because inventory alone cannot drive action. SBOMs and scanners can show what exists, but they do not show what can actually fire in a given application. The named concept here is reachable dependency risk: the subset of package exposure that your runtime path can really execute. That is the governance gap attackers exploit, and the practitioner conclusion is to prioritise fixable exposure over abstract completeness.

Assembly speed changes the control objective from detection to closure. AI makes code composition faster, which means dependency backlogs will grow unless remediation is automated at the manifest level. The market signal is that AppSec programmes will be judged less by how many issues they discover and more by how quickly they can convert reachable findings into merged fixes. Practitioners should build for closure, not for endless alert accumulation.

Transitive remediation is becoming a core control, not an optimisation. Fixing the direct dependency often means reasoning about the full chain beneath it and choosing a version that removes the vulnerable subtree without breaking production. That is a governance task because it reconciles security, build stability, and developer trust in one workflow. The practical conclusion is to treat transitive resolution as a first-class control in software supply chain management.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Reachable dependency risk: teams now need a name for the subset of dependency exposure that can actually execute in their applications. That concept matters because scanners and SBOMs still overstate the real fix queue unless they are paired with path-based triage and manifest-level remediation. Practitioners should align backlog priorities to execution paths, not to raw vulnerability counts.

Dependency ecosystems also change the access-control model. A compromised maintainer account, package approval workflow, or install hook can operate like privileged non-human access inside the build system, so security teams should review package publishing rights with the same seriousness they apply to other high-trust operational roles.

For practitioners

• Triage dependency findings by reachability Prioritise only the packages whose vulnerable code paths are actually callable from your application, and suppress noise from theoretical exposure that cannot execute in your runtime path.
• Treat package publishing rights as privileged access Review who can publish, approve, or modify packages and build hooks, because compromised maintainer access can convert trusted dependencies into an execution channel.
• Move install-time scripts behind explicit allowlists Disable automatic execution of dependency preinstall, install, and postinstall hooks unless a package has been reviewed and intentionally allowed in the build policy.
• Remediate at the manifest, not the alert Resolve the direct dependency version that eliminates the vulnerable subtree, then verify the build and tests still pass before merging the fix.
• Automate transitive fix generation for recurring CVEs Use workflow automation to convert reachable transitive vulnerabilities into developer-acceptable pull requests instead of leaving them in long-lived backlogs.

Key takeaways

• Software supply chain risk now sits mainly in dependency governance, not in first-party code alone.
• The source article shows why inventory is insufficient: transitive trees and install-time execution create exposure that scans cannot close on their own.
• Practitioners should prioritise reachability, restrict package execution paths, and automate manifest-level remediation to shrink the gap between detection and fix.

Key terms

• 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.
• Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.
• Install-Time Execution: Install-time execution is code that runs while dependencies are being installed rather than when an application is launched. In supply chain attacks, this matters because the install phase often has access to the richest secrets in developer and CI environments, making it a high-value privilege boundary.
• Dependency Governance Noise: Dependency governance noise is the gap between the number of issues a scanner reports and the number of issues a team can actually act on. High noise weakens trust in the programme, slows remediation, and can cause developers to ignore findings that matter.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners build the access and lifecycle controls that modern software supply chains increasingly depend on.