NIST SP 1326 Is Out: What ICT Suppliers Need to Do Now About Software Supply Chain Due Diligence
NIST finalized SP 1326 on July 8, 2026. The full title is the "Cybersecurity Supply Chain Risk Management Due Diligence Assessment Quick-Start Guide," and it does what the name says: it gives buyers of ICT products and services a structured starting point for assessing supplier risk, grounded in the deeper framework of SP 800-161r1.
If you sell software or embedded technology into organizations that follow NIST guidance - federal contractors, regulated industries, critical infrastructure operators - expect to be assessed against this guide. Understanding what it asks for is the first step to being ready to answer.
What SP 1326 Actually Is (and What It Is Not)
SP 1326 is a supplier due-diligence guide, not a certification program. There is no SP 1326 "compliance" badge. What it creates is a shared vocabulary and a scoped assessment structure that a buying organization can use to evaluate its ICT suppliers before or during procurement.
The guide scopes its due-diligence questions across five components:
- Foreign Ownership, Control, or Influence (FOCI) - Does the supplier have ownership or operational ties to foreign entities that could introduce geopolitical risk?
- Provenance - Can the supplier trace and verify the origin and integrity of the components in its software or hardware?
- Resilience - Does the supplier have continuity and recovery capabilities that protect the product supply chain from disruption?
- Foundational Cyber Practices - Does the supplier operate a baseline security program, including secure development practices?
- Supply Chain Tiers - Does the supplier understand and manage risk across its own upstream suppliers (the third parties it depends on)?
This five-component structure is the assessment lens. A buying organization uses it to ask questions, not to receive a pass/fail score.
Why Provenance and Supply Chain Tiers Are the Hard Ones for Software Suppliers
FOCI is primarily a corporate governance question. Resilience maps to business continuity planning. Both require documentation and policy, but they do not fundamentally require new tooling for most established software suppliers.
Provenance and Supply Chain Tiers are different. They require you to have technical visibility into your own software - what it is made of, where each piece came from, and how far the dependency graph extends. Most software organizations, even mature ones, do not have complete answers to these questions at the component level.
Provenance asks whether you can verify the origin and integrity of the software components your product contains. That means knowing which open-source libraries are included, which versions, and whether those versions are the ones you intentionally selected. It also means being able to produce a machine-readable artifact - an SBOM - that communicates this to a buyer.
Supply Chain Tiers asks whether you understand your upstream suppliers' risk, not just your own. In software, your upstream suppliers are largely your open-source dependencies and any third-party commercial components. A tier-2 or tier-3 dependency with a known vulnerability or a compromised release is your problem the moment a buyer's assessor finds it.
How Labrador Supports These Two Components
Labrador is Apona's SAST, SCA, and supply-chain security product. It is built specifically for the problems SP 1326's Provenance and Supply Chain Tiers components are designed to surface.
For Provenance:
Labrador's SCA capability inventories the open-source and third-party components in your codebase and generates SBOMs in both SPDX and CycloneDX formats - the two machine-readable formats most commonly requested by buyers and federal procurement teams. This gives you a documented, exportable answer to the Provenance question: here is what is in our software, versioned and formatted for your review.
Component inventory is not just a one-time export. Labrador tracks your dependency landscape as the codebase changes, so the SBOM you hand to a buyer reflects the current state of the product, not the state from last quarter's release.
For Supply Chain Tiers:
SCA naturally surfaces transitive dependencies - the libraries your libraries depend on. This is where Supply Chain Tiers risk actually lives. A direct dependency you trust can carry an indirect dependency with a known CVE or a license that creates obligation. Labrador maps these dependency tiers and flags issues at each level, giving you visibility into the full graph rather than just your direct includes.
When a buyer's assessor asks "what does your tier-2 dependency exposure look like?", having that mapped and documented is the difference between a confident answer and a delayed procurement cycle.
Foundational Cyber Practices: The Secure SDLC Connection
The Foundational Cyber Practices component is broader than the other four - it covers whether the supplier operates a baseline security program. One concrete, demonstrable element of that is whether security analysis is integrated into the software development lifecycle rather than bolted on at release time.
Labrador's SAST capability runs static analysis against your proprietary source code during development. The practical benefit is triage management: catching issues in the development workflow rather than accumulating a backlog that grows faster than the team can address it. For a supplier under due-diligence review, this is evidence of a functioning secure SDLC - not a claim, but a practice you can point to.
Rule sets in Labrador are tunable, which matters for organizations that want to align their analysis to specific standards or suppress noise that does not apply to their technology stack. The goal is actionable signal, not a report that sits unread.
Getting Ready for SP 1326 Assessments
Here is the practical sequence for software suppliers preparing to answer SP 1326 questions:
- Know your component inventory. If you cannot produce a current SBOM on short notice, that is the first gap to close.
- Map your transitive dependencies. Direct dependencies are table stakes. Buyers are increasingly asking about depth.
- Document your secure development practices. SAST integration in CI/CD is a demonstrable answer to Foundational Cyber Practices questions. Running it is more credible than describing it.
- Format matters. SPDX and CycloneDX are the formats assessors expect. A custom spreadsheet is not the same thing.
SP 1326 is a guide, not a mandate with teeth today. But the buying organizations using it are the ones writing procurement requirements. Getting ahead of these questions is easier than answering them under time pressure from a buyer's procurement team.
Labrador's SAST, SCA, and SBOM capabilities are available through Apona. Learn more at apona.ai/labrador or reach out to discuss how the tooling maps to your specific assessment context.
This post is about Labrador.