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.
