NIST SP 1326 Supply Chain Tiers: How Deep Does Your Dependency Map Need to Go?

NIST SP 1326 (finalized July 8, 2026) is reshaping how organizations think about software supply chain risk. One of its more demanding expectations is that a supplier does not simply know its own immediate vendors - it must understand and manage risk across its own upstream suppliers, meaning the third parties its products and services depend on. For software-producing organizations, that obligation cascades quickly into open-source and third-party components, and the real exposure lives several layers below what most teams have ever bothered to map.

This article is part of Apona's ongoing NIST SP 1326 series. If you are preparing for a supplier assessment or responding to a customer questionnaire, this is where the dependency tier question usually trips people up.

What SP 1326 Actually Asks About Upstream Suppliers

SP 1326 frames supply chain risk management as a multi-tier problem. A first-tier supplier (you, the software vendor) is expected to demonstrate that you understand what your suppliers bring into the picture, and whether those suppliers themselves manage their upstream risk adequately. For physical goods, that is a sourcing problem. For software, it is a component problem.

The practical question an assessor will pose: do you know what is in your software, where it came from, and what known risks exist - not just for the packages you directly declared, but for everything those packages pull in?

Direct, Transitive, and Deep-Tier Dependencies: What Each Level Means

Direct dependencies (tier 1) are the libraries and packages your team explicitly declared - the entries in your package.json, pom.xml, requirements.txt, or equivalent manifest. These are the components most teams have some visibility into.

Transitive dependencies (tier 2) are what your direct dependencies depend on. You did not choose them deliberately, but they ship in your software. A direct dependency on a popular HTTP client might pull in a cryptography library, an XML parser, and several utility packages you have never reviewed.

Deep-tier dependencies (tier 3 and beyond) are the transitive dependencies of transitive dependencies. By the time you reach tier 3 or tier 4, you may be looking at hundreds or thousands of components. These are exactly where several high-profile supply chain incidents have originated - a vulnerability or a malicious modification buried far enough down that standard first-party scanning never surfaces it.

SP 1326 does not cap the mapping obligation at tier 1 or tier 2. The expectation is proportional to the risk posture of the product and the sensitivity of the customer environment. For any software going into critical infrastructure, regulated industries, or government procurement, assessors will expect evidence that transitive and deep-tier dependencies have been examined.

How Deep Is Deep Enough?

There is no single numeric answer in SP 1326, but the assessment question is functional: can you demonstrate awareness of material risks in your dependency graph, not just your manifest? "Material" means known vulnerabilities (CVEs), license conflicts, components with no active maintenance, and components sourced from suppliers with their own unmanaged supply chain exposure.

A reasonable baseline for most software suppliers:

What Evidence Satisfies an Assessor

Assessors are looking for artifacts, not assertions. "We monitor our dependencies" is a posture claim. What they want to see:

  1. An SBOM with transitive depth. A shallow SBOM listing only direct dependencies will raise immediate questions. The SBOM should enumerate components to a depth that reflects actual risk, with each component's origin, version, and known vulnerability status.
  1. Tier-level vulnerability attribution. When a CVE is reported against a component, can you show which tier it entered your software at, and which of your direct dependencies introduced it? This demonstrates you understand the dependency graph, not just the output of a scanner.
  1. Process evidence. When was the last scan run? Is it integrated into your CI/CD pipeline or performed ad-hoc? Assessors weight continuous evidence higher than point-in-time reports.
  1. Remediation workflow. What happens when a tier-2 or tier-3 vulnerability is flagged? Can you show that findings below the direct layer are triaged and addressed, not filtered out?

Mapping Tiers From Source: How Labrador Approaches This

For teams with access to source code, Labrador's SCA and SBOM capability maps transitive dependency tiers starting from the project's own manifests and lock files. It surfaces findings at the tier where they originate, so when a vulnerability exists in a tier-3 component, the output shows the path - which direct dependency introduced it, through which intermediary, to the affected package. That tier-attributed output is the kind of artifact that translates directly into the assessor evidence described above.

Labrador also produces SBOMs that can be shared downstream with customers or used to respond to supplier questionnaires, which is increasingly what procurement teams require.

The Binary Component Problem: When Source Is Unavailable

Source-based SCA has a gap: closed-source components, pre-compiled binaries, firmware libraries, and vendor SDKs where the original source is simply not available. Those components still ship in your product. They still have dependency graphs. And if an assessor asks what is in them, "we don't have the source" is not a satisfying answer.

For these scenarios, Apona brings KhaiCode to the channel - a binary-first supply chain product that surfaces embedded components and their tiers through binary composition analysis, without requiring access to source. When your software stack includes third-party compiled libraries or vendor-supplied binaries, KhaiCode fills the gap that source-based tools leave open.

Putting It Together

The tier-mapping expectation in SP 1326 is one of the harder practical requirements to satisfy because it demands that you have done the work, not just that you have a policy about doing the work. The evidence trail - a deep SBOM, tier-attributed findings, a documented triage process - is what separates a credible supplier from one that passes on paper.

If you are currently mapping only your direct dependencies, you have a gap worth closing before your next assessment conversation.

Apona helps software-producing teams build the supply chain visibility that assessors and procurement teams are increasingly requiring. Learn more about Labrador's SCA and SBOM capabilities at apona.ai/labrador.

This post is about Labrador.

More on this