Topic starter
19/08/2026 3:40 pm
TL;DR: As AI makes code assembly cheap and transitive dependencies dominate modern codebases, application security is shifting from code authorship to dependency governance, with attackers exploiting package ecosystems, poisoned maintainer accounts, and vulnerable build-time paths, according to Pixee. The practical challenge is no longer finding issues but triaging reachable risk and remediating it without breaking production.
Editorial analysis by NHI Mgmt Group, based on content published by Pixee: “The Software You Ship Is Assembled, Not Written”.
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.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Software supply chain risk now sits mainly in dependency governance, not in first-party code alone.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:19 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Software supply chain security has shifted to dependency governance