Software supply chain security has shifted to dependency governance

At a glance

What this is: This analysis argues that modern AppSec has moved from securing code developers write to governing the dependencies, packages, and build-time paths that assemble most software.

Why it matters: For IAM and security practitioners, the same governance shift that drives NHI sprawl applies here: inventory alone is not control, and reachability plus remediation determine real risk reduction.

By the numbers:

• Open source now appears in 98% of codebases, and 64% of the components in those codebases are transitive.
• The average codebase now carries 1,180 open source components, most of them inherited through dependency chains rather than chosen directly.
• 252 days

👉 Read Pixee's analysis of dependency governance in modern AppSec

Context

Application security is increasingly about dependency governance, not just code review. In modern software, the critical risk often sits in transitive packages, build hooks, and maintainer trust rather than in the first-party code developers wrote themselves. That matters for identity and access governance because the same control gap shows up in NHI estates: inventory, approval, and ownership are useful only when they are paired with continuous reachability and lifecycle enforcement.

The article frames a familiar security problem in a new place. Attackers target the assembly layer because that is where software is now accumulated, updated, and executed, and the same logic applies to non-human identities that are created, delegated, inherited, and left standing long after their original use case has changed. For teams that run IAM, PAM, or secrets programmes, this is a reminder that governance has to follow runtime reality, not just documented intent.

Key questions

Q: What breaks when dependency governance is not tied to reachability?

A: Security teams end up triaging thousands of findings that cannot actually execute, while the real issues remain buried in the backlog. That creates false confidence, delays remediation, and wastes engineering time. Reachability is the control that separates theoretical exposure from exploitable exposure, so without it the programme measures inventory, not risk.

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 do security teams know if dependency controls are actually working?

A: Look for whether build systems prevent unauthorised version drift, whether package provenance is checked before install, and whether secret-handling code is isolated from broad application reach. If packages can change quietly and still access sensitive material, the control model is failing even if scans are passing.

Q: What should teams do when a package maintainer or dependency changes?

A: Re-review the package as if it were newly introduced, because prior approval no longer proves current trust. Changes in ownership, provenance, or install behaviour can turn a safe dependency into a live execution path. The right control is lifecycle revalidation, not one-time approval.

Technical breakdown

Why transitive dependencies are now the real attack surface

A transitive dependency is a package that arrives indirectly through another package you chose. That means most of the code in a modern application is inherited, not authored, and the risk profile is shaped by layers of trust the development team never reviewed directly. When 64% of components are transitive, the attack surface expands faster than manual review can follow. This is why SCA inventory alone is insufficient: it can tell you what exists, but not whether the vulnerable path is actually callable in your code path.

Practical implication: prioritise reachability analysis so security teams review only the dependency paths that can actually execute.

How malicious packages exploit build and install time

Package ecosystems increasingly abuse install-time execution, maintainer account compromise, and dependency confusion to turn trusted update paths into execution paths. Build hooks such as preinstall and postinstall are especially attractive because they run automatically in many pipelines, which gives attackers code execution before the application even starts. The shift to allowing or denying these behaviours at the manifest level is useful, but only if approvals are tied to review, ownership, and re-evaluation when a maintainer or dependency changes state.

Practical implication: restrict install-time execution and require re-review when package ownership, provenance, or behaviour changes.

Reachability plus transitive fix generation is the control gap

The key technical problem is not just detecting a vulnerable package, but proving whether the vulnerable function is reachable and then fixing the issue in the direct dependency you control. That requires graph reasoning across nested dependencies, not a simple version bump. In practice, the effective control is a loop that combines exploitability analysis, dependency graph tracing, and automated pull-request generation that preserves build integrity. Without that loop, the backlog becomes a permanent holding area for known risk.

Practical implication: automate manifest-level remediation for reachable issues so fixes arrive as mergeable pull requests, not tickets.

Threat narrative

Attacker objective: The attacker wants to convert trusted package distribution into repeated code execution, credential theft, and downstream supply chain spread.

1. Entry occurs through malicious or compromised packages that are pulled into trusted software build pipelines.
2. Escalation happens when install scripts or startup hooks execute automatically and steal developer or cloud credentials.
3. Impact follows when stolen credentials are used to publish poisoned packages or expand compromise across the dependency ecosystem.

NHI Mgmt Group analysis

Dependency governance is the new AppSec centre of gravity. The article correctly shows that modern software risk is no longer dominated by the code developers intentionally write. It is dominated by inherited packages, transitive reach, and package behaviour that changes after approval. That means application security and identity governance now share the same structural problem: the control plane cannot stop at inventory. The practitioner conclusion is clear, control must follow runtime trust, not static approval.

Reachability analysis is the difference between noise and action. Traditional scanners are necessary, but they do not answer the question that matters most for remediation prioritisation: can the vulnerable path actually fire in this application? That is why dependency governance is converging with policy-based access decisions in other security domains. The same logic underpins how teams should think about NHI approval and revocation. If a secret, package, or token is present but unreachable, it is different from one that can actually execute or authenticate. The practitioner conclusion is to prioritise exploitability, not volume.

Transitive remediation creates a new governance debt if it stops at detection. The article’s strongest operational point is that a fix must often happen in the direct dependency layer, not in the vulnerable package itself. That is a governance problem as much as a technical one because teams need ownership, revalidation, and build-safe automation to keep the fix moving. In identity programmes, this mirrors the lifecycle problem of inherited access that nobody wants to own. The practitioner conclusion is that governance only counts when it resolves to a merged fix or a revoked entitlement.

Build-time execution paths are a privileged trust boundary. Install hooks, startup hooks, and remote dependency resolution are effectively high-trust execution channels inside software supply chains. Once attackers can execute there, they can move from code delivery to credential theft and package poisoning with very little resistance. That is why this class of issue belongs in the same mental model as privileged access and delegated identity. The practitioner conclusion is to treat build pipelines as sensitive control planes, not just developer convenience layers.

Reachability-driven remediation is the named control concept this market needs. The article points to the exact gap that many AppSec programmes still have, too much inventory, too little prioritisation, and no reliable path from finding to safe fix. That gap is now more visible because AI has made assembly faster than manual review. Practitioners should expect dependency governance to become a board-level resilience issue, not just a developer workflow issue. The conclusion is to measure how quickly the programme can move from detected risk to merged remediation.

What this signals

Dependency governance is becoming a lifecycle discipline, not a scanner output. Teams that still organise AppSec work around backlog volume will keep losing to faster exploitation and slower remediation. The programme signal is to shift ownership from finding issues to closing them, using reachability, automated PRs, and build-safe fixes as core control measures.

Package provenance now behaves like identity trust. Maintainer accounts, install hooks, and dependency ownership changes should be treated as trust events that demand revalidation. That is the same governance logic security teams already apply to privileged access and service-account lifecycle decisions, and it is now entering the software supply chain.

As the ecosystem scales, exposure will track the weakest review boundary. The broader lesson is that inventory cannot compensate for trust that is never rechecked. Teams should align dependency governance with NIST AI Risk Management Framework style accountability in the parts of the programme that make autonomous or semi-automated changes to software, because the control question is who can change what, when, and under which review conditions.

For practitioners

• Implement reachability-first triage Rank dependency findings by whether the vulnerable code path is actually callable in your application, not by CVE count alone. This reduces noise and lets security teams focus review effort on issues that can reach production behaviour. Link triage outputs to repository ownership so the right team receives the finding.
• Block automatic execution from dependency install hooks Disable or tightly control preinstall, install, and postinstall behaviour in build pipelines unless a package has been explicitly reviewed. Require exception records for any allowlisted hook and revalidate them when package ownership or provenance changes.
• Remediate at the manifest layer Fix reachable transitive vulnerabilities by updating the direct dependency you control, then verify the dependency tree still resolves cleanly and the build passes. Do not stop at identifying the vulnerable nested package; the control point is the manifest that shapes the tree.
• Treat package provenance as a lifecycle control Track maintainer account changes, package ownership changes, and suspicious version churn as security events. If a trusted package changes hands or behaviour, re-review it as though it were a new dependency rather than assuming prior approval still holds.
• Measure backlog collapse, not scan volume Track median time from reachable finding to merged fix, the percentage of findings reduced by exploitability analysis, and the share of fixes that arrive as accepted pull requests. Those metrics show whether the programme is actually reducing exposure.

Key takeaways

• Modern AppSec risk now concentrates in inherited dependencies, not just the code teams intentionally write.
• The strongest signal in the article is that detection alone is not enough when remediation takes months and attackers move in hours.
• Practitioners should move from inventory-led security to reachability-led remediation, with lifecycle controls around packages and build-time execution.

Key terms

• Transitive Dependency: A transitive dependency is a package that your application uses indirectly through another package. It expands the attack surface because the team inherits code, updates, and risk from layers it did not directly choose or review, which makes inventory and ownership harder to govern.
• 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.
• Transitive Remediation: Transitive remediation is the process of fixing a vulnerable package by updating the direct dependency that pulls it in. It requires graph-level reasoning because the right fix is often several layers away from the vulnerable component itself, and the final build must remain stable.

What's in the full article

Pixee's full article covers the operational detail this post intentionally leaves for the source:

• How its reachability analysis reduces false positives before human review
• How transitive dependency fixes are generated at the manifest layer without breaking the build
• How its pipeline ingests scanner findings and converts them into mergeable pull requests
• Why the article treats scanner output as input to remediation rather than the end state

👉 Pixee's full post covers reachability triage, transitive remediation, and build-safe dependency fixes.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, IAM, and workload identity. It helps practitioners connect lifecycle controls across identities, access, and automation.