Notes on Secure Software Development Methodologies (MS SDL, OWASP CLASP, NIST SSDF, OWASP SAMM)

MS SDL (Microsoft Secure Development Lifecycle)

  • Overview

    • Comprehensive process published by Microsoft; focus on producing secure software.
    • More than 20 years old; a business process that guides security activities across the SDLC.
    • Key idea: map activities to the organization and ensure security considerations are integrated from the start.

  • Phases and core activities

    • Train
    • Core Security Training: foundational concepts for building better software.
    • Topics include secure design, threat modeling, secure coding, security testing, and privacy best practices.
    • Aims to raise baseline security literacy across the team.
    • Require (Requirements)
    • Establish Security and Privacy Requirements early to identify milestones and deliverables.
    • Create Quality Gates / Bug Bars: define minimum security/privacy quality levels at project start.
    • Perform Security and Privacy Risk Assessments to identify which parts require threat modeling and security design reviews.
    • Design
    • Design Requirements: consider security/privacy early to minimize schedule disruptions and costs.
    • Attack Surface Analysis/Reduction: analyze and reduce the overall attack surface; apply least privilege; employ layered defenses.
    • Threat Modeling: structured approach to identify vulnerabilities, risks, and mitigations during design.
    • Use Approved Tools: publish and enforce a list of approved tools and checks (compilers/linkers, warnings).
    • Deprecate Unsafe Functions: ban unsafe APIs to reduce security bugs.
    • Static Analysis: code review via source analysis prior to compile.
    • Develop
    • Dynamic Analysis: run-time checks of software behavior to catch issues like memory corruption and privilege problems.
    • Fuzz Testing: feed malformed or random data to reveal security issues before release.
    • Attack Surface Review: review attack surface after code changes to ensure new vectors are considered and mitigated.
    • Verify
    • Incident Response Plan: plan for security incidents and contacts; ensure readiness for inherited codebases.
    • Final Security Review: assess threat models, tool outputs, and performance against quality gates.
    • Certify Release and Archive: certify software for release and archive relevant data and artifacts.
    • Release
    • Execute Incident Response Plan: implement the IR plan to protect customers from vulnerabilities at release time.
    • Respond
    • Ongoing Incident Response: implement IR plan to address new threats post-release and sustain protection for users.

  • Linkages and significance

    • Emphasizes early security requirements and continuous verification.
    • Encourages threat modeling, risk assessments, and use of approved tools to standardize secure practices.
    • Aligns security activities with organizational processes and governance.

OWASP CLASP (Comprehensive, Lightweight Application Security Process)

  • Overview

    • A collection of security activities for secure software development.
    • Role-based, activity-driven process designed to map activities to organizational roles.
    • Focus on practical, scalable security integration into development lifecycles.

  • Key roles and activities (selected highlights)

    • Project Manager
    • Institute security awareness for project members through training and accountability.
    • Ensure exposure to security to deal with it effectively.
    • Monitor security metrics and enforce accountability for inadequate security.
    • Manage security issue disclosure with external researchers and communicate with customers on identified issues.
    • Requirements Specifier
    • Specify operational environment and security-relevant requirements.
    • Document misuse cases; communicate risks and rationale to stakeholders.
    • Architect
    • Identify resources and trust boundaries; define system roles and the access each role has.
    • Integrate security analysis into source management (e.g., automating security analysis and metrics collection).
    • Perform code signing to validate origin and integrity of software.
    • Designer
    • Harden design by applying security design principles; determine secure implementation strategies for protocols and APIs.
    • Assess third-party solutions and annotate class designs with security properties.
    • Specify database security configurations and default secure configurations.
    • Implementer
    • Implement interface contracts; ensure unit-level input validation and security policies.
    • Build operational security guides and document security usage within the product.
    • Test Analyst
    • Find security problems not detected by implementation review; validate security against requirements and threat models.
    • Verify conformance to security policies and assess risks introduced by the environment.
    • Security Auditor
    • Conduct security-focused reviews to ensure compliance with the defined security requirements.
    • Verify third-party components comply with requirements.

  • Threat modeling and attack surface concepts

    • The CLASP process emphasizes threat modeling and attack surface analysis as core activities during design and requirements phases.
    • Activities map to roles to ensure accountability and traceability.

  • How activities map to organization

    • Roles are assigned specific security responsibilities, promoting ownership and accountability throughout the SDLC.

NIST SSDF (Secure Software Development Framework)

  • Overview

    • A practical framework published by NIST to help produce more secure software.
    • Built on established good practices for secure development.
    • Organized around four main functions with supporting practices.

  • Four functions and practices

    • Prepare the Organization (PO)
    • PO.1 Define Security Requirements for Software Development: identify applicable security requirements for the organization’s software development and maintain over time.
    • PO.2 Implement Roles and Responsibilities: create/alter roles to encompass secure development; provide role-specific training; obtain management commitment.
    • PO.3 Implement a Supporting Toolchain: specify mandatory tools, integrate toolchain components, deploy and maintain tools securely.
    • PO.4 Define Criteria for Software Security Checks: define criteria and mechanisms to gather necessary information to support criteria.
    • Protect the Software (PS)
    • PS.1 Protect All Forms of Code from Unauthorized Access and Tampering: least-privilege access to code forms.
    • PS.2 Provide a Mechanism for Verifying Software Release Integrity: make verification information available to software consumers.
    • PS.3 Archive and Protect Each Software Release: securely archive releases and components and release integrity information.
    • Produce Well-Secured Software (PW)
    • PW.1 Design Software to Meet Security Requirements and Mitigate Risks: use risk modeling (threat modeling, attack modeling, attack surface mapping).
    • PW.2 Review Software Design for Security Compliance: independent review to confirm security requirements are met and risks addressed.
    • PW.3 Verify Third-Party Software: communicate requirements to third parties and verify compliance.
    • PW.4 Reuse Existing, Well-Secured Software When Feasible: acquire well-secured components; build in-house where needed; promote standardized security features.
    • PW.5 Create Source Code Adhering to Secure Coding Practices: follow secure coding practices; developers review their own code as a supplement to peer reviews.
    • PW.6 Configure Compilation and Build Processes: use compiler/build features to improve executable security; apply approved configurations.
    • PW.7 Code Review and/or Code Analysis: determine appropriate approach; document and triage issues.
    • PW.8 Test Executable Code: determine types of testing; design and perform tests; document results.
    • PW.9 Secure Settings by Default: set secure default configurations; document settings for admins.
    • Respond to Vulnerabilities (RV)
    • RV.1 Identify and Confirm Vulnerabilities: gather reports from consumers/public sources; review code to confirm vulnerabilities; have a process to handle vulnerability reports.
    • RV.2 Assess, Prioritize, and Remediate Vulnerabilities: analyze each vulnerability; develop and implement remediation plans.
    • RV.3 Analyze Vulnerabilities to Identify Root Causes: identify root causes; look for patterns; proactively fix related issues; update SDLC to prevent recurrence.

  • Practical implications

    • SSDF provides a structured, evidence-based approach to integrating security into all phases of software development.
    • Emphasizes governance, tooling, secure design, supplier security, and ongoing vulnerability management.

OWASP SAMM (Software Assurance Maturity Model)

  • Overview

    • Open-source maturity model for secure software development from OWASP (current version 2).
    • Defines a measurable way to assess the security posture of software in any organization.
    • Maps business activities to maturity levels to guide improvement.

  • Key concept: streams and maturity

    • SAMM organizes activities into streams (often described as domains) that span governance, design, implementation, verification, and operations.
    • Each activity maps to maturity levels, allowing organizations to measure progress and target improvements.
    • The model emphasizes an integrated, continuous improvement approach across the entire SDLC.

  • Core areas (high-level, representative list)

    • Governance and Strategy
    • Strategy & Metrics, Policy & Compliance, Compliance Management, Organization & Culture, Education & Security Awareness.
    • Design
    • Threat Assessment, Security Requirements, Software Requirements, Architecture; Security Architecture; Architecture Validation.
    • Implementation
    • Build Process, Software Dependencies, Secure Coding Guidance, Defect Management, Security Testing Guidance.
    • Verification
    • Security Testing, Configuration and Patch Management, Environment Management, Verification Guidance.
    • Operations
    • Incident Management, Incident Detection, Incident Response, Deployment and Operational Management.
    • Additional concepts
    • Supplier Security, Secret Management, Change Management, Metrics & Feedback, Guidance, Training & Awareness.
    • The model uses two streams (Stream A and Stream B) to reflect different paths or focus areas within each domain.

  • Software Requirements Measurement (levels)

    • Level 1: High-level security objectives are mapped to functional requirements; security requirements are specific, measurable, and aligned with the organizational baseline.
    • Level 2: Structured security requirements are used by developer teams; domain experts are involved; there is a structured notation for security requirements; a security champion is dedicated to reviewing outcomes.
    • Level 3: Use a standard requirements framework to elicit security requirements; framework is adaptable to business needs; guidance exists on quality and description of requirements.

  • Practical takeaway

    • SAMM provides a practical, business-facing way to plan and measure security maturity across an organization.
    • It emphasizes governance, design, implementation, verification, and operations as interconnected streams that drive secure software delivery.

Ethical and legal reminder for students

  • Context
    • The course on Secure Software Development covers mechanisms that can be used to disrupt information security and to attack web applications and software systems.
  • Legal and ethical guidance (Serbia)
    • Unauthorized testing or intrusion into systems without explicit permission is punishable under the Criminal Code of the Republic of Serbia (Articles 298 to 304a).
  • Lab-only rules
    • Students may only apply these methods within a closed lab environment provided for instructional purposes.
    • Students should not use these techniques on systems outside the lab or without explicit authorization.
  • Responsibility
    • Any activity outside the designated lab environment is the student’s responsibility to forgo and avoid.

Connections and overarching themes

  • Common goals across all methodologies
    • Build security into the software development lifecycle from the earliest stages.
    • Threat modeling, risk assessment, and secure design are foundational across frameworks.
    • Continuous verification, testing, and vulnerability management are essential for maintaining secure software post-release.
  • Differences in emphasis
    • MS SDL emphasizes a concrete phase-by-phase lifecycle with explicit activities and mapping to roles.
    • OWASP CLASP focuses on role-driven activities and practical mappings to organizational roles.
    • NIST SSDF provides a formal, framework-based set of practices with clearly defined functions and practices.
    • OWASP SAMM offers a maturity-model perspective focused on measurable improvements across governance, design, implementation, verification, and operations.
  • Practical takeaways for exam prep
    • Be able to list the main phases/activities of MS SDL and what each phase targets (training, requirements, design, development, verification, release, response).
    • Understand the role-driven flow of OWASP CLASP and the responsibilities of each role (PM, Requirements Specifier, Architect, Designer, Implementer, Test Analyst, Security Auditor).
    • Recall the four functions and key practices of NIST SSDF (PO, PS, PW, RV) and representative practices under each.
    • Recognize the five SAMM domains and the purpose of measuring maturity in security activities.
    • Remember the ethical/legal caveat highlighted for student conduct and the importance of lab-based learning for offensive security techniques.