How Deep Should Your SBOM Go for Transitive Dependencies in a Vendor Assessment?

When you're evaluating a software vendor, you will almost certainly receive a software bill of materials at some point in the process. The question is whether that SBOM is actually telling you anything useful - or whether it's a one-page list of direct dependencies that leaves the real risk invisible.

The short answer to "how deep should an SBOM go?" is: deep enough to surface what your vendor's vendor shipped. For most modern software stacks, that means transitive dependencies, and getting this right is one of the harder parts of a serious vendor assessment.

What Transitive Dependencies Actually Are (and Why They Dominate Risk)

A direct dependency is a library your vendor explicitly pulled in. A transitive dependency is everything those libraries pulled in - and everything those pulled in. Real applications can have dozens of direct dependencies and hundreds of transitive ones.

The problem is that most known vulnerabilities in open-source components live several layers down, not at the surface. A vendor can ship clean code with squeaky-clean direct dependencies and still bundle a vulnerable version of a compression library or an XML parser because a dependency of a dependency needed it. If the SBOM they hand you stops at layer one, you have no visibility into that exposure.

This is not hypothetical. The pattern shows up consistently: a widely-used transitive dependency carries a critical CVE, downstream products are silently affected, and the organizations that only looked at direct dependencies have no idea they are in scope.

What a Useful SBOM Depth Looks Like in Practice

For a vendor assessment, a credible SBOM should include:

Full transitive coverage. Every component that ends up in the built artifact, not just what the developer typed into a manifest. This means the SBOM generation has to happen at build time or from the compiled output, not just from a package manifest read.

Component identity that is machine-readable. Package name and version are the minimum; CPE identifiers and PURL notation let you actually correlate components against vulnerability databases without manual lookup. An SBOM that lists "openssl" without a version is essentially decorative.

License metadata at every level. License risk compounds the same way security risk does. A transitive dependency under a copyleft license can create obligations for the vendor's product that the vendor may not have noticed - and that you inherit risk from.

Provenance and integrity data where available. The supply-chain attacks that have made headlines are not about vulnerable code; they are about tampered code that looks legitimate. SBOMs that include hashes and provenance metadata give you something to validate against.

A clear scope boundary. The SBOM should state what it covers: which build artifact, which environment, which date. An SBOM without scope metadata is hard to reason about over time.

Where Vendor-Provided SBOMs Often Fall Short

Vendors generating their own SBOMs under time pressure frequently hit a few predictable failure modes:

How to Evaluate What You Receive

When a vendor hands you an SBOM during diligence, a few quick checks tell you a lot:

  1. Count the components. For any non-trivial application, if the total component count is under 50, the SBOM is probably not capturing transitive dependencies.
  2. Look for version specificity. Every component should have an exact version number. Ranges or blanks indicate the SBOM was generated from a manifest, not a resolved build.
  3. Check the format. SPDX and CycloneDX are the standard interchange formats. A PDF table or a spreadsheet is not machine-consumable and cannot be easily compared against a CVE database.
  4. Ask when it was generated. Request the generation timestamp and ask whether it matches the version of the software you are evaluating.
  5. Ask about the tooling. Vendors who can name the tool they use to generate SBOMs and describe their process are further along in supply-chain hygiene than those who cannot.

Running This Internally Before You Ask Your Vendors

One of the sharper ways to build assessment credibility is to apply the same standard to your own software before you ask a vendor to meet it. That means running SBOM analysis against your own build artifacts and understanding the transitive graph before you send a questionnaire.

Labrador's SCA and supply-chain analysis does exactly this - it analyzes the full dependency graph including transitive dependencies, maps components to known vulnerabilities, and flags licensing issues at every layer. The result is a picture of what is actually shipping, not what the manifest suggests. For teams running vendor assessments, having run this process internally means you know what a complete SBOM looks like and can evaluate what a vendor hands you with a calibrated eye.

The Baseline to Hold Vendors To

For a vendor assessment, a reasonable minimum bar is: full transitive dependency coverage, machine-readable format (SPDX or CycloneDX), version-specific component identities, and a generation date that matches the version under review. Anything short of that is a starting point for a conversation, not a closed checkbox.

Deeper expectations - provenance metadata, VEX mappings, signed SBOMs - are appropriate for higher-risk vendors or regulated environments. The depth should match the exposure.

If you want to see what a full transitive SBOM analysis looks like in practice before your next vendor assessment cycle, apona.ai/labrador is a reasonable place to start.

This post is about Labrador.

More on this