The Transitive Iceberg: Why Your SBOM Doesn't Look Deep Enough

A modern application often consists of 80% to 90% open-source components. What you as a developer add explicitly to your project (the direct dependencies) is just the tip of the iceberg.

As soon as you add one seemingly simple library, it often drags in its own set of requirements. Those libraries, in turn, have dependencies of their own. We call this chain-reaction phenomenon transitive dependencies. A simple project with 5 direct libraries quickly explodes into a web of 500+ nested components.

The danger below the surface

An SBOM that shows only the "direct" ingredients gives a false sense of security. The true complexity lies deep below the waterline:

• Patching is a logistical nightmare: If a serious vulnerability (CVE) is found in layer 4 of your iceberg, you can't simply update it yourself at the push of a button. You depend on the maintainers of the libraries in layers 3, 2 and 1.
• Dependency Confusion: The larger and more opaque the dependency tree becomes, the easier it is for attackers to hide a malicious package with a similar name somewhere deep in the structure.
• The Blind Spot (APIs and SaaS): An application rarely consists of code alone. What about dependencies on cloud services or SaaS payment providers? If a crucial external API is compromised, your application is just as much at risk.