NIST SSDF: Secure Software for the AI Era

Module 1: Applying the NIST SSDF

  The Secure Software Challenge

• Software as an organizational and operational dependency
• Security weaknesses throughout the software lifecycle
• Moving from finding vulnerabilities to preventing them
• Secure software development as an organizational capability

  Introducing the NIST SSDF

• Purpose and scope
• Guidance not a prescribed methodology
• Integrating with existing development approaches such as SecDevOps

  Navigating the SSDF

• Practices, tasks, implementation examples, and references
• Identifiers and terminology – a common security vocabulary
• Finding applicable SSDF guidance

  Activity 1.1 Individual

• SSDF Scavenger Hunt - find and report to the class

Module 2: the Four SSDF Practice Groups

  Prepare Organization (PO)

• Defining security requirements
• Roles and responsibilities and the NICE Framework
• Preparing people, processes, and technology
• Establishing and maintaining secure development environments

  Protect Software (PS)

• Protecting software from unauthorized access
• Protecting source code and development assets
• Protecting software releases
• Preserving software integrity

  Produce Well-Secured Software (PW)

• Designing software to meet security requirements
• Reviewing designs and assessing risk
• Securing reusable and third-party components
• Reviewing, analyzing, and testing software
• Configuring software securely

  Respond to Vulnerabilities (RV)

• Identifying and confirming vulnerabilities
• Assessing and prioritizing vulnerabilities
• Remediating vulnerabilities
• Analyzing root causes and preventing recurrence

   Activity 2.1 Group Discussion

• Where Does It Belong?
• Teams classify security activities as primarily PO, PS, PW, or RV and defend ambiguous decisions

Module 3: Applying SSDF to Legacy Software

  Introducing the Northstar case study

• Safety-critical software environment
• Problem domain concepts and vocabulary

  The VECTOR Legacy System

• Long-lived software and technical debt
• Incomplete documentation and organizational knowledge
• Limited automation and legacy development practices
• Security practices that predate the SSDF

   Assessing Existing Practices

• Identifying implicit secure development activities
• Mapping existing activities to SSDF tasks
• Recognizing partial implementation
• Distinguishing gaps from acceptable risk decisions

   Activity 3.1 Group Discussion

• Should Northstar Rewrite the VECTOR system?
• SSDF Archaeology – identify practices that already align with SSDF
• Risk, operational impact, technical debt, and the danger of compromising safety

Module 4: Applying SSDF to Current-Time Software

   Northstar's Modern Development Environment

• Modern languages, APIs, and distributed systems
• Open-source and third-party components
• Multiple development and supplier teams
• Automated build, test, and release capabilities

   Mapping Organizational Practices to SSDF

• Identifying applicable SSDF tasks
• Mapping one activity to multiple practices
• Recognizing overlapping security activities
• Identifying unmapped activities and missing capabilities

   Activity 4.1 Independent – Assess Northstar

• Students map current Northstar development activities to specific SSDF practices and tasks.

   Evaluating SSDF Implementation

• Documented practice versus actual practice
• Claims versus evidence
• Implemented, partially implemented, and not implemented
• Assessing effectiveness rather than presence

   Activity 4.2 Group Discussion – Sounds Secure to Me?

• Teams identify statements that sound reassuring, but are they?
  • “We perform annual security training” or
  • “SAST is used before release”

Module 5: Learning from Vulnerabilities

   Northstar's Component Vulnerability

• Discovery of a vulnerable software component
• Identifying affected products and versions
• Supplier and dependency complications
• Remediation creates operational consequences

   Responding to Vulnerabilities

• Vulnerability identification and confirmation
• Prioritization and response
• Remediation and verification
• Communicating vulnerability information

   Beyond the Vulnerability

• Root cause analysis
• Identifying failures in PO, PS, and PW
• Feeding lessons back into development
• Preventing recurrence

   Activity 5.1 Progressive Group Activity – The Northstar Vulnerability

• Information is revealed in stages. Teams initially respond to vulnerability
• Then discover that Northstar cannot reliably identify affected products, component versions, or supplier exposure.
• Course theme: RV often exposes yesterday's failure in PO, PS, or PW.

Module 6: Building an SSDF Improvement Program

   Performing an SSDF Gap Assessment

• Establishing the current state by gathering evidence
• Documenting capability gaps

   Prioritizing SSDF Improvements

• Risk and operational impact
• Effort and organizational readiness
• Dependencies between SSDF practices
• Quick wins and strategic improvements
• Creating an SSDF Improvement Roadmap

   Activity 6.1 Independent Activity – Northstar 90-Day Roadmap

• Students select priority SSDF improvements and create a sequenced 90-day improvement plan

Module 7: Applying SSDF to Future Software

   Northstar TAACT project vision – Going to School

• From Algorithmic Automation to AI
• Deterministic software and rule-based automation
• AI-assisted decision support
• Learned behavior and non-deterministic outcomes
• Increasing software autonomy

  Applying the SSDF to AI

• AI systems as software
• Models, data, and AI dependencies
• Limits of traditional secure development practices

  Activity 7.1 Group Discussion – Why Not Monday Morning?

• Students consider existing AI capability and identify why a seemingly successful AI system cannot simply be deployed into operational production

Module 8. Extending the SSDF for AI Systems

  The SSDF AI Community Profile

• Purpose of SP 800-218A to augment not replace SSDF
• AI-specific practices and considerations
• Applying SSDF guidance across the AI lifecycle

  Protecting AI Development Assets

• Training and evaluation data
• Models and model versions
• AI development environments
• Provenance, integrity, and traceability

  Measuring Secure Software Development

• Activity metrics versus outcome metrics
• Leading and lagging indicators
• Vanity Metrics
• Measuring effectiveness and assurance evidence

  Activity 8.1 Group Activity – What evidence demonstrates that an AI system is ready?

• Northstar claims TAATC has successfully completed ten million simulated scenarios and is ready for operational trials.
• Teams address training, examination and evaluation, continuing qualification, security and protection.

Module 9: Course Summary and Capstone:

    Activity 9.1 Northstar 2035

• Is TAATC ready for operational trials?
• Teams present one of three recommendations: proceed, proceed with conditions, do not proceed
• Every recommendation must be defended using specific SSDF and AI Community Profile guidance and supporting evidence.