Every developer knows about their direct dependencies. The packages they explicitly added to package.json, requirements.txt, or pom.xml are visible, intentional choices. What most developers don’t know well is the transitive dependency graph—the packages those packages depend on, and the packages those packages depend on, cascading several levels deep.
This graph is where most modern software vulnerability exposure actually lives. The direct dependency is typically well-known and actively maintained. Its transitive dependencies may be obscure, unmaintained, and carrying CVEs that nobody on the development team has ever looked at.
The Transitive Dependency Problem
A Python web application that depends on FastAPI depends on Starlette, which depends on AnyIO, which depends on idna. The development team chose FastAPI. They did not choose idna. They may not know idna is in their dependency graph at all.
When a CVE is disclosed against idna (as happened with CVE-2024-3651), teams without full transitive dependency visibility need to audit their entire dependency graph to determine if they’re affected. Teams with SBOM-complete transitive dependency inventory can answer the question immediately.
The transitive dependency problem compounds at the container layer: the container image adds OS-level packages and their transitive dependencies on top of the application dependency graph. A container running a Python application may have transitive dependencies from the OS layer that have nothing to do with the application’s package choices.
Most CVEs disclosed against widely-used packages affect software through transitive dependencies that developers didn’t explicitly choose and may not know they have.
What Complete SBOM Coverage Requires?
Transitive dependency enumeration
Software supply chain security programs require SBOMs that capture the full dependency graph, not just declared dependencies. SBOM generation tools that only scan package manifests (package.json, requirements.txt) rather than analyzing the installed package tree will miss transitive dependencies.
Tools like Syft and SPDX toolkits that scan installed packages—rather than declared ones—produce more complete transitive inventories. The distinction matters: a declared-dependency SBOM might list 50 packages while an installed-package SBOM lists 400 for the same application.
License compliance alongside CVE tracking
Container CVE exposure isn’t the only risk that transitive dependencies carry. License compatibility is a separate but related issue: a transitive dependency that carries a copyleft license (GPL, AGPL) may impose licensing obligations on the software that depends on it, even if the original author wasn’t aware of the dependency.
SBOM-based license auditing reveals license conflicts in the dependency graph. Organizations that have run license audits against their complete SBOMs regularly discover licenses they weren’t aware of—particularly in transitive dependencies several levels deep.
Runtime profiling to identify which transitive dependencies execute
The transitive dependency graph is often much larger than what’s actually loaded at runtime. A transitive dependency that’s installed but never imported by any code path that executes is present in the SBOM but absent from the runtime execution profile.
Knowing which transitive dependencies actually load has the same prioritization value for transitive dependencies as for direct ones: CVEs in loaded transitive dependencies require active remediation, CVEs in unloaded transitive dependencies are candidates for removal or lower-priority treatment.
Practical Steps for Auditing Your Dependency Graph
Generate complete SBOMs from installed packages, not from declared manifests. For each application and container image, generate the SBOM from the full installed package tree. Compare the count against what you’d expect from your direct dependencies. The gap reveals the transitive dependency scale.
Filter your SBOM by direct vs. transitive dependencies. Most SBOM formats support marking dependencies as direct or transitive. Generate a report that separates direct dependencies (which the team explicitly manages) from transitive ones (which are inherited). Track CVEs in both categories separately.
Run license compliance analysis against the complete transitive inventory. Use the SBOM to generate a license report covering all packages. Flag licenses that require legal review (GPL, AGPL, LGPL, MPL) and route them to the appropriate review process. This review is most valuable before discovery under litigation, not after.
Use runtime profiling to identify transitive dependencies that don’t load at runtime. After generating the complete transitive SBOM, run runtime profiling to determine which transitive packages are actually loaded. The difference between SBOM entries and RBOM entries in the transitive dependency set reveals removal candidates.
Track transitive dependency health separately from direct dependency health. Maintainer activity, CVE history, and update frequency metrics for direct dependencies are available from package registries. Track the same metrics for your transitive dependencies. Unmaintained packages in the transitive graph represent supply chain risk independent of their current CVE count.
Frequently Asked Questions
What do SBOMs reveal about open source components that developers typically miss?
SBOMs expose the full transitive dependency graph—the packages that your declared dependencies depend on, cascading multiple levels deep. Most CVEs disclosed against widely-used packages affect software through transitive dependencies that developers never explicitly chose and may not know they have. A Python application that uses FastAPI, for example, also inherits transitive dependencies like idna several levels down the chain.
How do transitive dependencies create hidden open source security risk?
Direct dependencies are typically actively maintained and monitored by development teams. Transitive dependencies—especially those several levels deep—may be obscure, unmaintained packages that no one on the team has reviewed. When a CVE is disclosed against a transitive dependency, teams without full SBOM coverage need to manually audit their entire dependency graph to determine exposure, while teams with complete SBOMs can answer immediately.
Why is complete SBOM coverage important for open source license compliance?
Complete transitive SBOM coverage reveals license obligations that propagate through dependency chains. A transitive dependency carrying a copyleft license (GPL, AGPL) may impose licensing obligations on your software even if the development team never knowingly chose that dependency. Full SBOM-based license audits regularly uncover GPL or AGPL licenses in transitive dependencies several levels deep—licenses that would be expensive to discover through litigation rather than proactive audit.
How does runtime profiling improve open source component risk management?
Runtime profiling identifies which transitive dependencies actually load during application execution versus which are installed but never imported. This prioritization has the same value for open source components as for any other package: CVEs in loaded transitive dependencies require active remediation, while CVEs in unloaded ones are candidates for removal. Removing unused transitive dependencies eliminates the supply chain risk entirely rather than relying on patching cycles.
The License Risk That SBOM Reveals
Security teams focused on CVE exposure sometimes underestimate the license risk that comprehensive SBOM analysis reveals. GPL-licensed transitive dependencies that appear through dependency chains can impose obligations on the software that uses them, regardless of how many intermediaries exist in the chain.
Organizations that have conducted full license audits based on their complete transitive SBOMs describe a consistent finding: several packages with GPL or AGPL licenses that weren’t known to the development team, discovered through transitive dependency tracing. The discovery is uncomfortable but valuable—discovering it through a legal complaint would be more expensive.
The SBOM is the tool that makes this discovery possible without litigation. The transitive dependency graph, once visible, can be audited for both CVE exposure and license risk. Both are consequential. Neither is visible without the complete inventory.
Complete transitive SBOM coverage is the prerequisite for both risk assessments.