Notifications
Clear all
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.
NHIMG editorial — 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, 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.
- The average industry mean time to remediation runs 252 days, which is far slower than attacker exploitation windows.
Questions worth separating out
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.
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 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.
Practitioner guidance
- Implement reachability-first triage Rank dependency findings by whether the vulnerable code path is actually callable in your application, not by CVE count alone.
- 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.
- 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.
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
👉 Read Pixee's analysis of dependency governance in modern AppSec →
Dependency governance in AppSec: what changes when AI makes assembly cheap?
Explore further
19/08/2026 4:19 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Software supply chain security has shifted to dependency governance
