11.1 Frameworks for Understanding Supply Chain Risk¶

Parts I and II of this book examined the threats, attacks, and vulnerabilities affecting software supply chains. Understanding these risks is necessary but not sufficient—organizations need structured approaches to assess, prioritize, and manage supply chain risk in their specific context. Risk frameworks provide this structure, offering systematic methods for identifying, analyzing, and responding to supply chain threats.

No single framework perfectly addresses software supply chain risk. Some emphasize process controls, others quantitative analysis, still others compliance requirements. Selecting and applying the right framework—or combination of frameworks—depends on organizational maturity, regulatory context, and specific risk management objectives.

The Trust Inversion Problem¶

Before examining specific frameworks, it's worth naming the fundamental architectural flaw these frameworks address: modern software exhibits what we call trust inversion—the degree of trust granted to code is inversely proportional to the degree of verification applied to it.

Your own application code is reviewed, tested, and monitored extensively. Yet it typically runs with the same privileges as a transitive dependency from an anonymous maintainer—code that your organization has never reviewed, tested, or even directly chosen. That dependency has full access to the filesystem, network, environment variables, and credentials. The least-verified code in your stack has the same blast radius as your most-verified code.

This inversion means that supply chain attacks exploit a structural gap, not just individual vulnerabilities. Risk assessment must therefore consider not only "how likely is compromise?" but "how much damage can unverified code do?" The frameworks examined below provide structured approaches to this problem, but the most resilient architectures also incorporate containment—limiting what code can do regardless of whether it has been verified (see Chapter 18 for runtime containment approaches).

NIST Cyber Supply Chain Risk Management (C-SCRM)¶

The National Institute of Standards and Technology (NIST) has developed comprehensive guidance for managing cyber supply chain risk, primarily through SP 800-161 Revision 1:¹ Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations (Update 1, November 2024).

Core Concepts:

NIST C-SCRM integrates supply chain risk management into enterprise risk management, treating supply chain risk as one category of organizational risk requiring systematic attention.

Key elements include:

• Multi-level approach: Addresses risk at enterprise, mission/business process, and operational levels
• Integration with existing frameworks: Aligns with NIST Cybersecurity Framework and Risk Management Framework (SP 800-37)
• Lifecycle coverage: Addresses risk throughout the system development lifecycle
• Foundational practices: Establishes baseline practices applicable across organizations

Key Control Families:

SP 800-161 Rev. 1 organizes controls into families aligned with SP 800-53:

• SR (Supply Chain Risk Management): Dedicated supply chain controls including supplier assessments, acquisition strategies, and component authenticity
• SA (System and Services Acquisition): Secure development requirements, supply chain protection
• CM (Configuration Management): Component inventory, baseline configurations
• SI (System and Information Integrity): Integrity verification, vulnerability monitoring

Selected Critical Controls:

Practical Application:

Organizations applying NIST C-SCRM typically:

1. Establish governance: Create supply chain risk management policy and assign responsibilities
2. Identify critical suppliers: Inventory suppliers and assess their criticality
3. Assess supplier risk: Evaluate supplier security practices and potential vulnerabilities
4. Implement controls: Apply appropriate controls based on risk level
5. Monitor continuously: Track supplier performance and emerging risks

Strengths:

• Comprehensive and well-documented
• Integrates with broader NIST framework ecosystem
• Influential for federal agencies and contractors through federal acquisition and agency risk-management requirements
• Free and publicly available

Limitations:

• Primarily process-focused; limited quantitative guidance
• Can be overwhelming for smaller organizations
• Requires significant interpretation for software-specific context
• Compliance-oriented language may not resonate with engineering teams

ISO 28000 Series: Supply Chain Security Management¶

The ISO 28000 series² provides international standards for supply chain security management systems.

ISO 28000:2022 Overview:

ISO 28000 specifies requirements for a security management system for the supply chain. While originally focused on physical supply chains (shipping, logistics), it increasingly applies to cyber and software supply chains.

Core requirements include:

• Context establishment: Understanding organizational context and supply chain relationships
• Leadership commitment: Management support and resource allocation
• Risk assessment: Identifying and evaluating supply chain security risks
• Operational controls: Implementing security measures
• Performance evaluation: Monitoring and measuring effectiveness
• Continuous improvement: Correcting deficiencies and improving over time

Related Standards:

• ISO 28001: Best practices for implementing supply chain security
• ISO 28002: Developing resilience in the supply chain
• ISO 28003: Requirements for certification bodies
• ISO 28004: Guidelines for implementing ISO 28000

Certification Considerations:

ISO 28000 certification involves:

• Third-party audit by accredited certification body
• Demonstration of conformance with all standard requirements
• Ongoing surveillance audits (typically annual)
• Recertification every three years

Certification may be valuable for:

• Organizations with international supply chain relationships
• Companies where customers require third-party assurance
• Industries with certification expectations (defense, critical infrastructure)

Applicability to Software:

ISO 28000 wasn't designed specifically for software but applies to software supply chains:

• Supplier assessment requirements map to vendor security reviews
• Asset identification includes software components and dependencies
• Incident management covers security vulnerabilities and breaches
• Business continuity addresses dependency on critical suppliers

Strengths:

• International recognition and certification pathway
• Risk-based approach adaptable to context
• Integration with other ISO management systems (27001, 9001)
• Customer and regulatory credibility

Limitations:

• Less specific than NIST for cyber/software context
• Certification costs can be significant
• Generic requirements require interpretation
• Physical supply chain origins limit software-specific guidance

Factor Analysis of Information Risk (FAIR)¶

FAIR³ (Factor Analysis of Information Risk) provides a quantitative framework for information risk analysis, enabling organizations to express supply chain risk in financial terms.

Core Concepts:

FAIR decomposes risk into measurable components:

Risk = Loss Event Frequency × Loss Magnitude

Loss Event Frequency = Threat Event Frequency × Vulnerability
Loss Magnitude = Primary Loss + Secondary Loss

FAIR Taxonomy:

• Threat Event Frequency: How often do threat actors attempt attacks?
• Vulnerability: What percentage of attempts succeed?
• Primary Loss: Direct costs (response, replacement, lost productivity)
• Secondary Loss: Indirect costs (reputation, legal liability, regulatory)

Applying FAIR to Supply Chain:

For a supply chain scenario like dependency compromise:

1. Define the scenario: Attacker compromises a critical npm dependency
2. Estimate threat event frequency: Based on historical incidents, industry data, threat intelligence
3. Estimate vulnerability: Probability that an attack would succeed given current controls
4. Estimate loss magnitude: Response costs, business disruption, regulatory penalties
5. Calculate risk: Express as expected annual loss or risk distribution

Example Analysis (Hypothetical):

The following illustrates how a FAIR analysis might be structured for a supply chain compromise scenario. These figures are hypothetical and intended to demonstrate the methodology—organizations should calibrate estimates using their own incident data and industry benchmarks such as the Verizon DBIR⁸ or Sonatype's annual State of the Software Supply Chain report.⁹

Note: The annualized range is derived from Monte Carlo simulation across the input distributions, not simply by multiplying bounds. The theoretical maximum (5 × 0.3 × $2.5M = $3.75M) and minimum (2 × 0.1 × $150K = $30K) represent boundary cases; simulation captures the probability-weighted distribution between them. Organizations should use dedicated FAIR tools (e.g., RiskLens, FAIR-U) for rigorous quantification.

Strengths:

• Quantitative output enables comparison and prioritization
• Financial terms communicate with executives
• Forces explicit assumptions (which can be challenged)
• Supports cost-benefit analysis for controls

Limitations:

• Requires data that may not be available
• Estimation uncertainty can be significant
• More complex than qualitative approaches
• May create false precision if not properly communicated

FAIR in Practice:

Organizations using FAIR typically:

• Start with top 5-10 supply chain risk scenarios
• Use ranges (not point estimates) to express uncertainty
• Calibrate estimates with historical data and industry benchmarks
• Update analyses as new information becomes available
• Use Monte Carlo simulation for probability distributions

The Software Supply Chain Risk Framework¶

Several frameworks specifically address software supply chain risk, building on lessons from recent incidents.

SLSA (Supply-chain Levels for Software Artifacts):

SLSA⁴ (pronounced "salsa") provides a security framework specifically for software supply chains. SLSA 1.1 is current as of this writing and continues to focus on the Build track with four levels. Because SLSA continues to evolve, readers should consult slsa.dev for the latest specification version and any updates to level definitions:

• Level 0 (L0): No guarantees; baseline with no SLSA requirements
• Level 1 (L1): Provenance exists showing how the package was built
• Level 2 (L2): Signed provenance from a hosted build service
• Level 3 (L3): Hardened build platform with verified, non-forgeable provenance

SLSA focuses on build integrity rather than comprehensive risk management, but integrates into broader frameworks.

OpenSSF Scorecards:

OpenSSF Scorecards⁵ automatically assess open source project security practices:

• Branch protection policies
• Code review requirements
• Dependency update practices
• Security policy presence
• CI/CD security configurations

Scorecards provide objective measures for evaluating dependency risk.

S2C2F (Secure Supply Chain Consumption Framework):

Microsoft's S2C2F,⁶ now maintained by the OpenSSF, focuses on consuming open source securely. The framework continues to evolve—readers should consult the current specification at the OpenSSF repository for updated practice definitions and maturity levels.⁷ As of the version referenced here, S2C2F defines eight practices:

• Ingest: How open source enters your organization
• Scan: Analyzing ingested packages for known vulnerabilities
• Inventory: Tracking what you use
• Update: Managing updates and patches
• Audit: Evaluating security of dependencies
• Enforce: Controlling what's allowed
• Rebuild: Verification through reproducibility
• Fix/Upstream: Addressing vulnerabilities and contributing fixes back

S2C2F defines four maturity levels for organizations:

• Level 1: Basic OSS governance (inventory, scan, update)
• Level 2: Improved mean time to remediate (MTTR) capabilities
• Level 3: Proactive security analysis and preventative controls
• Level 4: Sophisticated attack mitigation (aspirational)

Applicability:

These software-specific frameworks complement rather than replace broader risk frameworks:

• SLSA provides implementation guidance for build integrity
• Scorecards offer automated assessment for dependency evaluation
• S2C2F structures the consumption process

They're most useful as components within a comprehensive risk management approach.

Selecting the Right Framework¶

Framework selection depends on organizational context:

Decision Factors:

Selection by Context:

Federal contractors and government-adjacent organizations:

• Start with NIST C-SCRM for compliance alignment
• Add software-specific frameworks for implementation detail
• Consider FAIR for investment prioritization

International enterprises:

• Consider ISO 28000 for certification value
• Supplement with NIST technical guidance
• Use FAIR for executive communication

Technology companies:

• Start with software-specific frameworks (SLSA, Scorecards)
• Adopt NIST controls selectively based on relevance
• Use FAIR to prioritize security investments

Smaller organizations:

• Begin with software-specific frameworks (lower overhead)
• Adopt NIST controls progressively as maturity grows
• Use simplified FAIR analysis for key scenarios

Framework Limitations¶

All frameworks have limitations that practitioners should acknowledge:

Common Limitations:

1. Not exhaustive: No framework captures all possible risks. Novel attacks may not fit existing categories.

2. Require interpretation: Frameworks provide structure, not answers. Applying them to specific contexts requires judgment.

3. Point-in-time: Risk assessments reflect current understanding. Threats evolve faster than frameworks.

4. Process over outcome: Framework compliance doesn't guarantee security. Organizations can be compliant but insecure.

5. Resource requirements: Comprehensive framework implementation requires significant effort that may not be justified for all organizations.

Specific Limitations:

• NIST C-SCRM: Control language can be abstract; mapping to specific software practices requires interpretation
• ISO 28000: Physical supply chain origins limit software-specific guidance
• FAIR: Data availability and estimation uncertainty limit precision
• Software-specific frameworks: Narrow scope; don't address organizational/governance aspects

Mitigating Limitations:

• Combine frameworks to address gaps
• Supplement with threat intelligence and incident data
• Update assessments regularly
• Validate framework assumptions against real incidents
• Accept that frameworks guide but don't guarantee

Combining Frameworks¶

Most mature organizations use multiple frameworks in combination:

Typical Combination Pattern:

Enterprise Risk Management
    └── NIST C-SCRM / ISO 28000 (Governance structure)
            └── FAIR (Quantitative analysis for priorities)
                    └── SLSA / Scorecards (Implementation guidance)

Integration Approach:

1. Establish governance using NIST C-SCRM or ISO 28000 as the backbone
2. Quantify key risks using FAIR for investment prioritization
3. Implement controls using software-specific frameworks for technical guidance
4. Measure effectiveness using Scorecards and other automated tools

Avoiding Duplication:

When combining frameworks:

• Map overlapping requirements to avoid duplicate effort
• Designate one framework as primary for each purpose
• Use common terminology where possible
• Maintain single source of truth for assessments

Recommendations¶

For Security Leaders:

1. Select frameworks intentionally. We recommend choosing based on your regulatory context, organizational size, and maturity level. Don't adopt frameworks just because they exist.

2. Start with governance structure. We recommend establishing policy, roles, and responsibilities before implementing technical controls. NIST C-SCRM or ISO 28000 provide this foundation.

3. Add quantitative analysis. We recommend using FAIR or similar approaches to express risk in terms executives understand and to prioritize investments.

4. Incorporate software-specific guidance. SLSA, Scorecards, and S2C2F provide implementation detail that broader frameworks lack.

For Practitioners:

1. Don't let frameworks constrain thinking. Use frameworks as starting points, not boundaries. Novel threats may not fit existing categories.

2. Focus on outcomes. Framework compliance is not the goal—reduced risk is. Evaluate whether framework activities actually improve security.

3. Iterate and improve. Initial framework implementation won't be perfect. Plan for regular review and refinement.

4. Connect to incidents. Validate framework effectiveness against real incidents. If a framework would not have prevented or detected an actual attack, adjust.

For Organizations:

1. Invest in risk quantification capability. The ability to express risk in financial terms enables better prioritization and executive communication.

2. Balance rigor with practicality. Comprehensive framework implementation requires significant resources. Scale effort to actual risk.

3. Maintain framework currency. As threats evolve and new guidance emerges, update framework implementation accordingly.

4. Measure what matters. Define metrics that indicate actual risk reduction, not just framework compliance.

Frameworks provide essential structure for managing supply chain risk, but they are tools, not solutions. Organizations that apply frameworks thoughtfully—combining governance structure, quantitative analysis, and implementation guidance—will manage supply chain risk more effectively than those that treat framework compliance as an end in itself.