How to Map Software Supply Chain Tiers Under NIST 800-161 and SP 1326

Supply chain risk management used to be something only defense primes worried about. That changed. NIST SP 800-161r1 (Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations) and the newer SP 1326 (Cybersecurity Supply Chain Risk Management for Software) now give every software-producing organization a clear framework for understanding where their dependencies come from - and a clear obligation to prove it.

The hard part is not reading the documents. The hard part is the mapping: turning a real-world codebase with hundreds of transitive dependencies into a structured, tier-by-tier view that satisfies auditors, customers, and your own security team.

This article walks through how that mapping works in practice.

What "Tiers" Mean in This Framework

NIST 800-161r1 organizes C-SCRM (Cybersecurity Supply Chain Risk Management) across three organizational tiers:

SP 1326 narrows the lens to software specifically and adds rigor around SBOM (Software Bill of Materials) as the artifact that makes Tier 3 legible to Tiers 1 and 2.

The critical insight: risk flows up the tiers, but visibility flows down. If you cannot see what is in your software at Tier 3, your Tier 1 governance is guessing.

Step 1 - Establish What You Own at Tier 3

Before you can map dependencies, you need an accurate inventory of your own code and what it pulls in. This means:

Static analysis (SAST) handles the first-party code. SCA (Software Composition Analysis) handles the dependency graph. SBOM generation captures the output in a machine-readable format (CycloneDX or SPDX) that the framework expects.

A tool like Labrador combines all three - SAST, SCA, and SBOM generation - so you get one artifact set rather than three separate tool outputs to reconcile. That matters because reconciliation gaps are exactly where auditors find problems.

Step 2 - Classify Dependencies by Risk Tier

Not every dependency carries the same risk. SP 1326 and 800-161r1 together push you toward a risk-tiered view of your software supply chain, not a flat list.

A practical classification approach:

| Risk Level | Criteria | |---|---| | Critical | Direct dependency in a security-sensitive code path; known active CVEs; or a component that touches authentication, crypto, or data handling | | High | Widely-used transitive dependency with recent vulnerability history; unclear maintainer identity | | Medium | Direct dependency with no recent CVEs; maintained project with clear provenance | | Low | Well-maintained, widely-audited library with clean history |

Your SBOM is the input to this classification. Without it, you are doing this manually - which does not scale past a handful of components.

Step 3 - Map Tier 3 Risk to Tier 2 Owners

Each product line (Tier 2) should be able to answer: "What is the risk posture of the software we ship?" That requires connecting the SBOM and vulnerability data from Tier 3 to the people accountable at Tier 2.

In practice this means:

The licensing issues surface here too. A transitive dependency under an incompatible license is a legal risk that the product owner needs to see, not just the security team. SAST and SCA tools that surface license findings alongside vulnerability findings - like Labrador does - reduce the back-and-forth between security and legal.

Step 4 - Give Tier 1 Governance Something to Look At

Tier 1 needs aggregate signal, not raw SBOM data. The artifacts you produce at Tier 3 and the decisions made at Tier 2 should roll up into:

SP 1326 specifically calls out the SBOM as a contractual and procurement artifact. If your customers or government counterparts are asking for SBOMs as a condition of purchase, Tier 1 needs to know the answer before the question arrives in a sales call.

Where Teams Usually Get Stuck

The mapping exercise surfaces three common problems:

  1. Transitive visibility gaps. Direct dependencies are easy. The fourth-level transitive dependency that pulled in a vulnerable logging library is not. Manual audits miss these reliably.
  1. Toolchain fragmentation. SAST from one vendor, SCA from another, SBOM from a third - each with its own severity scoring, format, and export cadence. The reconciliation work is real.
  1. Compliance without continuity. Teams produce an SBOM at release and consider the box checked. NIST 800-161r1 expects ongoing monitoring, not a point-in-time snapshot.

Labrador is designed around the first two problems: unified SAST + SCA + SBOM in a single analysis run, with a tunable rule set so teams can prioritize findings rather than triage noise. The ongoing-monitoring problem is solved by integrating the tool into CI/CD so every build produces a fresh artifact.

The Practical Output

When this mapping is done well, you end up with:

That is what NIST 800-161r1 and SP 1326 are asking for. The mapping is not a one-time project - it is the operational state you are trying to reach.

If you are working through this mapping and want to understand how Labrador fits into the SAST + SCA + SBOM layer, the product details are at apona.ai/labrador.

This post is about Labrador.

More on this