A direct dependency is something you chose. A transitive dependency is something you inherited. The uncomfortable arithmetic of modern software is that most of your dependency graph falls into the second category, and most of the realised risk lives there too. The Safeguard Research team has spent the last two quarters building a transitive-specific risk index so we can talk about this problem with something more than anecdote.
This post is the 2026 edition of that ranking. It is organised around categories of dependency, not specific package names, for two reasons: name-level risk shifts from release to release, and category-level patterns are more useful guidance for platform teams trying to decide where to invest. We are ranking what kinds of transitive dependencies tend to concentrate risk, based on how they show up across real customer environments and our own historical data.
How did the team build the risk index?
We scored each transitive dependency on six signals: reach (how many distinct customer applications include it), blast radius (how many downstream consumers would be affected by a compromise), historical incident density (documented supply-chain incidents per hundred packages in the category), maintenance posture (active vs. abandoned using our multi-signal model), privilege profile (does the package touch secrets, network, or process execution), and upgrade friction (how easy is it to patch when a CVE lands).
We normalised each signal to a common scale and produced a composite index per package, then aggregated to categories. The ranking below is the aggregate view. It is intentionally coarse; a top-ten of specific packages would be obsolete before this post was a month old.
Which categories carry the most concentrated risk?
The categories that rise to the top combine high reach, high privilege, and meaningful historical incident density. In rough order, they are:
1. HTTP and networking clients. Any library that fetches URLs is privileged by nature. Recent years have shown that parsing quirks, URL handling edge cases, and TLS verification defaults in these libraries produce long-running vulnerability classes, and exploitation is often straightforward when the library is reachable from user-controlled input.
2. Serialisation and deserialisation libraries. The category that produced the original canonical supply-chain horror stories. Even after more than a decade of attention, unsafe-by-default deserialisation paths continue to appear in the mainstream libraries of every major language. The reach is universal.
3. Cryptography primitives and TLS wrappers. A small number of cryptographic libraries sit under a huge fraction of all production traffic. Vulnerabilities here are rare but catastrophic, and upgrade friction is high because changes can break protocol compatibility, TLS versions, or FIPS posture.
4. Logging frameworks. The Log4Shell family of incidents put this category on the map, and the underlying pattern, where a widely-used logger accepts complex input and exposes non-obvious code paths, continues to be a source of advisories across ecosystems.
5. Archive and compression libraries. Unzip and tar libraries have been the quiet source of a surprising number of serious issues, from zip-slip path traversal to decompression-bomb denial of service. They sit deep in build pipelines, package managers, and artifact handlers.
6. Template engines. Server-side rendering libraries and template engines show up in web stacks, email pipelines, and reporting systems. The risk concentration comes from their interaction with user-controlled input and their frequent use in rendering contexts that bypass typical content security policy.
7. XML, YAML, and structured-config parsers. The XXE, billion-laughs, and YAML-load-exec family of issues never quite goes away. These libraries are often buried deep in enterprise tooling where they touch untrusted configuration files and process inputs from the network.
8. Build-tool plugins and post-install scripts. Build plugins have the unusual property that they run during build, often with the highest level of access any part of your pipeline will ever have. A compromise here typically reaches CI secrets, signing keys, and artifact storage.
9. Authentication and identity helper libraries. OAuth helpers, JWT libraries, session stores, and password hashers. Bugs here rarely look dramatic in changelogs but produce some of the most severe real-world outcomes when exploited, because they sit at the trust boundary.
10. Developer telemetry and analytics SDKs. An underappreciated category. These SDKs often ship with broad network permissions, optional dynamic code loading, and automatic update channels. They are an attractive target because compromise gives the attacker a pre-installed beachhead in many production applications at once.
What do these categories have in common?
All ten combine high privilege with high reach, and most of them have non-trivial upgrade friction.
High privilege means the code has access to things an attacker wants: network, secrets, deserialised data, user input, or process execution. High reach means many applications include the code, often transitively, so a single compromise pays off across many targets. Upgrade friction means that even when a patch ships, a meaningful share of consumers will be slow to adopt it, which extends the window in which exploitation is practical.
The combination is what makes these categories worth the attention. A high-privilege, low-reach library is a sharp-edged tool that only a few teams have to worry about. A low-privilege, high-reach library is background noise. High privilege plus high reach plus upgrade friction is where attackers concentrate effort, and where defenders have to concentrate effort in response.
Which categories are moving up or down?
Logging frameworks and template engines are drifting down the list as long-running remediation programmes have reduced the share of applications still on vulnerable versions. They remain risky, but the marginal exposure is lower.
Developer telemetry SDKs and build-tool plugins are drifting up. The last two years have seen several serious incidents in these categories, and we expect more, because the attacker payoff is high and the defensive posture of many consumers is immature.
Cryptography sits in a stable position, but the emerging post-quantum migration will raise the risk temporarily as implementations churn, test matrices expand, and consumers struggle to keep libraries current across protocol versions.
What should this change in how teams think?
The useful consequence of a category view is that it tells platform teams where to invest in reducing blast radius rather than chasing individual CVEs.
First, build an inventory at the category level. For each of the top categories above, know which specific packages you use, which versions, and where in your application surface they sit. This is a cheap exercise that pays off every time a new CVE drops.
Second, concentrate isolation where it matters. Archive libraries, template engines, and serialisers are excellent candidates for running in sandboxed subprocesses or language runtimes that limit blast radius. A small investment in isolation around these specific categories is worth more than a large investment in a general sandbox.
Third, drive upgrade friction down on the categories that are worst. If upgrading your cryptographic library is a week-long exercise, fix that before the next advisory forces you to do it in a day.
Fourth, apply extra scrutiny at the intake boundary. A new transitive dependency in one of the top categories deserves a second look, even when it is pulled in indirectly. Many dependency intake policies treat all transitives the same. Category-aware policies outperform uniform ones.
What does the ranking not tell you?
It does not tell you which specific packages are currently compromised. It does not tell you which advisories are reachable in your code. It does not tell you which dependencies to rip out.
The ranking is a prior, not a verdict. It is useful because it focuses attention, and because it produces better investment decisions than treating every transitive dependency as equally important. The specific remediation still requires your own context: reachability, deployment surface, exploitation signals, and upgrade economics.
What this means
Transitive dependency risk is not evenly distributed. In our data, a small number of categories account for a disproportionate share of the security incidents, upgrade pain, and vendor-questionnaire friction that real platform teams encounter. Treating those categories as a named, tracked class of software, rather than part of a monolithic "our dependencies" blob, is the most effective organisational shift we can recommend this year.
The teams that get the most value from this view use it to set policy once and let it compound across releases.
How Safeguard.sh Helps
Safeguard.sh surfaces your transitive inventory against the category model in this post, highlights the high-privilege, high-reach, high-friction packages that concentrate your risk, and ties them to reachable advisories and patch paths in a single queue. Our customers use Safeguard.sh to set category-aware intake policy, to reduce blast radius around the categories that deserve it, and to keep an up-to-date view of how their own stack maps to the patterns we see across the industry. Instead of chasing one CVE at a time, security teams get a structural view of the dependency risk they have actually taken on.