26.3: NIST Frameworks and Guidance¶

Disclaimer: This chapter provides general educational information about NIST cybersecurity frameworks and guidelines. While NIST publications are voluntary guidance rather than mandatory regulations, they may be adopted by reference in regulatory requirements, contractual obligations, or organizational policies. This chapter does not constitute compliance advice. Organizations should consult with qualified cybersecurity and compliance professionals to determine which frameworks apply to their specific circumstances and how to implement them appropriately.

The National Institute of Standards and Technology (NIST) occupies a unique position in cybersecurity—its frameworks carry no direct regulatory force, yet they underpin virtually every significant cybersecurity regulation and standard in the United States and increasingly worldwide. When Executive Order 14028 mandated secure software development practices, it directed NIST to develop the criteria. When federal agencies assess software suppliers, they reference NIST publications. When organizations build security programs from scratch, NIST frameworks provide the foundation.

Understanding NIST's supply chain security guidance is therefore essential for any organization navigating the regulatory landscape. These frameworks translate abstract security principles into concrete, implementable practices—providing the "how" that regulations often leave unspecified. This section surveys the key NIST frameworks relevant to software supply chain security and provides practical guidance for their adoption.

Cybersecurity Framework 2.0 and Supply Chain Integration¶

The NIST Cybersecurity Framework (CSF) has become the de facto standard for organizing cybersecurity programs since its initial release in 2014. Version 2.0, published in February 2024,¹ significantly expands supply chain risk management from a subordinate consideration to a core governance function.

The CSF organizes cybersecurity activities into six Functions: Govern, Identify, Protect, Detect, Respond, and Recover. The addition of "Govern" in version 2.0—and particularly its supply chain category—reflects the maturation of supply chain security from a technical concern to an organizational imperative.

The GV.SC (Governance: Supply Chain) category establishes supply chain risk management as a governance responsibility requiring executive attention and organizational commitment. Its outcomes include:

• GV.SC-01: Establishing a cybersecurity supply chain risk management program with defined strategy, objectives, policies, and processes
• GV.SC-02: Defining and communicating cybersecurity roles and responsibilities for suppliers and third parties
• GV.SC-03: Integrating supply chain risk management into broader enterprise risk management
• GV.SC-04: Identifying and prioritizing suppliers based on criticality
• GV.SC-05: Establishing requirements for suppliers through contracts and agreements
• GV.SC-06: Planning for and conducting due diligence on prospective suppliers
• GV.SC-07: Managing risks posed by suppliers throughout the relationship lifecycle
• GV.SC-08: Including relevant suppliers in incident response planning and execution
• GV.SC-09: Integrating supply chain security into security awareness programs
• GV.SC-10: Addressing supply chain risks in continuity and recovery planning

Beyond GV.SC, supply chain considerations appear throughout CSF 2.0. The Identify function includes asset management that extends to software components. The Protect function addresses access control for third parties. The Detect function covers monitoring for supply chain compromise indicators.

CSF 2.0 introduces Organizational Profiles, which document an organization's current and target cybersecurity posture. Supply chain risk management should be explicitly addressed in these profiles, establishing clear objectives and identifying gaps requiring remediation.

For organizations beginning their supply chain security journey, we recommend using CSF 2.0's GV.SC outcomes as a maturity assessment framework. Rate your current capability against each outcome, identify gaps, and prioritize improvements based on risk and resource constraints.

SP 800-161: Cybersecurity Supply Chain Risk Management¶

NIST Special Publication 800-161 Revision 1, titled "Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations," provides comprehensive guidance for establishing and operating a Cybersecurity Supply Chain Risk Management (C-SCRM) program. Published in May 2022,² it represents NIST's most detailed treatment of supply chain security.

SP 800-161 defines C-SCRM as:

"A systematic process for managing exposure to cybersecurity risks throughout the supply chain and developing appropriate response strategies, policies, processes, and procedures."

The publication structures C-SCRM across three organizational levels:

Level 1 (Enterprise): Organization-wide governance establishing C-SCRM strategy, policy, and risk tolerance. Activities include defining supply chain risk appetite, allocating resources, and establishing accountability structures.

Level 2 (Mission/Business Process): Translating enterprise direction into mission-specific requirements. Activities include identifying critical suppliers, establishing supplier assessment criteria, and integrating C-SCRM into acquisition processes.

Level 3 (Operational): Implementing C-SCRM controls for specific systems and components. Activities include technical verification of components, ongoing monitoring, and incident response for supply chain events.

Key practices from SP 800-161 include:

Supplier assessment and selection: Establishing criteria for evaluating supplier security practices, conducting due diligence before engagement, and incorporating security requirements into contracts.

Provenance verification: Confirming the origin and custody of components throughout the supply chain, including verification that software comes from claimed sources and has not been tampered with.

Visibility and transparency: Obtaining information about supplier practices, component composition (including SBOMs), and vulnerability status to enable informed risk decisions.

Vulnerability management: Extending vulnerability identification and remediation processes to cover supply chain components, including open source dependencies.

Supplier monitoring: Continuously assessing supplier security posture through ongoing evaluation, threat intelligence, and incident monitoring.

SP 800-161 provides extensive control enhancements organized around the NIST SP 800-53 control catalog. Organizations using 800-53 for compliance (common in federal environments) can map supply chain requirements directly to existing control implementation.

SP 800-218: Secure Software Development Framework¶

NIST Special Publication 800-218, the Secure Software Development Framework (SSDF), forms the technical foundation for EO 14028's software security attestation requirements. Version 1.1, published in February 2022,³ defines a set of practices that software producers should adopt to mitigate vulnerabilities throughout the development lifecycle.

The SSDF organizes secure development into four practice groups:

Prepare the Organization (PO): Ensuring people, processes, and technology are prepared to perform secure software development. Practices include:

Protect the Software (PS): Protecting all components of software from tampering and unauthorized access. Practices include:

Produce Well-Secured Software (PW): Producing well-secured software with minimal security vulnerabilities. Practices include:

Respond to Vulnerabilities (RV): Identifying residual vulnerabilities and responding appropriately. Practices include:

Each practice includes multiple tasks providing specific implementation guidance. For example, PW.4 (reusing existing software) includes tasks for verifying third-party component security, maintaining component inventories, and monitoring for vulnerabilities—directly applicable to open source dependency management.

The SSDF is explicitly referenced in OMB M-22-18 and the CISA Secure Software Development Attestation Form. Organizations attesting to secure development practices are effectively certifying SSDF implementation. We recommend organizations map their existing development practices to SSDF practices and tasks, identifying gaps that require remediation before attestation.

NIST SBOM Guidance¶

NIST's role in SBOM standardization complements NTIA's minimum elements (discussed in Section 26.1). While NTIA defined what SBOMs should contain, NIST guidance addresses how SBOMs integrate into broader security practices.

NIST IR 8397, "Guidelines on Minimum Standards for Developer Verification of Software," addresses how organizations should verify software they develop or acquire—including verification of SBOM accuracy and completeness.

NIST SP 800-218 (SSDF) incorporates SBOM-related practices: - PS.3.2: Recording component provenance and integrity verification data - PW.4.1: Maintaining a list of all third-party components, including versions - PW.4.4: Monitoring third-party components for vulnerabilities

NIST guidance emphasizes that SBOMs are not standalone artifacts but components of a broader software supply chain transparency regime. Effective SBOM programs require:

1. Generation: Producing accurate SBOMs during build processes
2. Distribution: Sharing SBOMs with consumers and stakeholders
3. Consumption: Ingesting SBOMs from suppliers and integrating with vulnerability management
4. Maintenance: Updating SBOMs as software evolves

NIST's National Vulnerability Database (NVD) increasingly supports SBOM-based vulnerability management by providing vulnerability data in machine-readable formats that can be matched against SBOM component identifiers.

AI Risk Management Framework and Supply Chain¶

The NIST AI Risk Management Framework (AI RMF), published in January 2023, addresses risks specific to artificial intelligence systems. As AI components become increasingly prevalent in software products, their supply chain implications require attention.

The AI RMF identifies supply chain considerations across multiple risk categories:

Third-party AI components: Organizations frequently incorporate pre-trained models, AI services, and machine learning libraries from external sources. These components carry supply chain risks analogous to traditional software dependencies—compromised training data, backdoored models, or vulnerable inference code.

Training data provenance: AI systems depend on training data whose origin, quality, and potential biases affect system behavior. Supply chain transparency for AI must extend beyond code to include data lineage.

Model integrity: Pre-trained models can be poisoned or manipulated. Verifying model authenticity and integrity requires mechanisms beyond traditional code signing.

The AI RMF's Map function emphasizes the importance of documenting the origin and development of AI components, including training data sources, third-party models, and development tools, to enable organizations to understand their AI supply chain and manage associated risks.

The Govern function addresses AI supply chain governance, recommending that organizations establish policies and processes for acquiring, deploying, and monitoring third-party AI components, including criteria for supplier assessment and ongoing evaluation.

For organizations using AI components, we recommend extending existing C-SCRM programs to address AI-specific risks. This includes inventorying AI components (models, training data, ML frameworks), establishing provenance requirements for AI suppliers, and implementing monitoring for AI-specific vulnerabilities.

Using NIST Frameworks for Program Development¶

Organizations frequently struggle with framework selection and implementation prioritization. The NIST framework ecosystem can appear overwhelming—which publications apply, and where should you start?

Framework selection depends on organizational context:

Implementation prioritization should follow risk-based principles:

1. Identify critical assets: Determine which software components, suppliers, and processes present the greatest risk
2. Assess current state: Evaluate existing practices against framework requirements
3. Gap analysis: Document deficiencies between current and target states
4. Prioritize remediation: Address highest-risk gaps first, considering implementation complexity
5. Implement incrementally: Roll out controls in manageable phases
6. Measure and iterate: Monitor effectiveness and adjust approach based on results

Control Mapping Methodology¶

Organizations often face multiple compliance requirements simultaneously—EO 14028 attestation, EU CRA compliance, customer contractual obligations, and industry standards. Control mapping enables efficient compliance by identifying equivalent requirements across frameworks.

Step 1: Establish a canonical control set. Select one framework as your primary reference. For most organizations, this will be either CSF 2.0 (for overall security programs) or SSDF (for software development).

Step 2: Map external requirements to canonical controls. Document how each external requirement maps to your canonical framework. NIST provides mapping resources, including CSF 2.0 mappings to ISO 27001, CIS Controls, and other frameworks.

Step 3: Identify unmapped requirements. External frameworks may include requirements without canonical equivalents. Document these as additional controls requiring specific implementation.

Step 4: Implement unified controls. Build controls that satisfy all mapped requirements simultaneously, rather than implementing separate controls for each framework.

Step 5: Document mapping for audit purposes. Maintain documentation showing how each requirement is satisfied, enabling efficient compliance demonstration to multiple stakeholders.

For supply chain security specifically, the following mappings prove useful:

We recommend designating a single individual or team as the owner of control mapping, responsible for maintaining alignment as frameworks evolve and new requirements emerge. This investment in mapping infrastructure pays dividends through reduced compliance burden and consistent security implementation across the organization.