Transitive Dependency

A transitive dependency is a component that your product depends on indirectly. If your product directly uses Library A, and Library A internally uses Library B, then Library B is a transitive dependency of your product. In modern software development, the ratio of transitive to direct dependencies is typically very high - an application with 50 direct dependencies may have 500 or more transitive dependencies when the full dependency graph is resolved. Transitive dependencies are the source of a significant proportion of exploited vulnerabilities in real-world attacks: the Log4Shell vulnerability (CVE-2021-44228) was a transitive dependency for many organisations - they had no direct dependency on Log4j but relied on libraries that did. Many security teams have no visibility into transitive dependencies without dedicated tooling.

The CRA's essential requirements apply to the product as a whole - including vulnerabilities in transitive dependencies. Annex I requires manufacturers to identify and address security risks in their products, which necessarily includes risk from transitive components. The Annex VII SBOM must capture the full component inventory for the SBOM to be useful for vulnerability management. A 'direct dependencies only' SBOM misses the large majority of the software attack surface. Market surveillance authorities reviewing the technical file would likely consider an SBOM that omits transitive dependencies as failing to accurately represent the product's software composition. SBOM generation tools (Syft, CycloneDX plugins, SPDX generators) are configured by default to capture the full dependency graph including transitive dependencies.

Transitive dependency vulnerabilities present unique management challenges:

• Indirect control: The manufacturer cannot directly update a transitive dependency - they must update a direct dependency to a version that uses an updated transitive version.
• Dependency lock conflicts: Updating a direct dependency to pull in a fixed transitive version may break other direct dependencies that require an incompatible version.
• Vendor-managed components: When a transitive dependency is embedded in a commercial SDK or firmware component from a third-party vendor, the manufacturer must wait for the vendor to release an updated version.

Effective management requires: a complete SBOM including all transitive dependencies; automated CVE correlation against the full SBOM; a process for assessing whether a vulnerable transitive dependency is reachable in the product's specific execution paths; and vendor notification procedures for transitive vulnerabilities embedded in third-party components.

A powerful tool for managing transitive dependency vulnerability noise is reachability analysis combined with VEX documentation. For many transitive dependency CVEs, the vulnerable code path is not invoked in the product's actual execution - the product uses a component that depends on Library B, but the product's use case does not call the specific function in Library B that contains the vulnerability. Static analysis tools (including some SCA platforms) can assess reachability by analysing the call graph. When analysis confirms a transitive vulnerability is not reachable, the manufacturer should document this as a VEX 'not-affected' assertion. This: reduces internal triage burden; informs users that they do not need to treat the vulnerability as urgent; and demonstrates to MSAs that vulnerability monitoring is active and findings are genuinely assessed, not ignored.