ISC2 Certified Secure Software Lifecycle Professional

Security cannot be bolted on at the end of any methodology. You place security activities into waterfall, agile and DevOps delivery, assign roles, set gates, and use maturity models and metrics to see whether the practice is improving.

• Security activities in waterfall, iterative and agile delivery
• DevSecOps and where gates belong
• Roles and responsibilities for security champions
• Policy and standards that developers can follow
• Maturity models such as OWASP SAMM and BSIMM
• Security metrics that show real progress
• Change control and configuration management

You build A secure delivery process for one team, with gates, owners and metrics.

A missing requirement is a vulnerability waiting to be coded. You turn business needs, regulation and data sensitivity into testable security requirements, and use abuse and misuse cases to find the needs nobody wrote down.

• Functional and non-functional security requirements
• Regulatory, contractual and privacy requirements
• Data classification driving requirements
• Misuse and abuse cases
• Writing requirements that can be tested
• Traceability from requirement to test

You build A security requirements specification for a payments feature, with abuse cases and a traceability matrix.

Threat modeling finds design flaws while they are cheap to fix. You model data flows and trust boundaries, enumerate threats with STRIDE and attack trees, rate them, and decide which mitigations earn a place in the design.

• Data flow diagrams and trust boundaries
• STRIDE by element
• Attack trees and attack patterns
• Rating and prioritizing threats
• Attack surface measurement and reduction
• Recording mitigations as design decisions

You build A threat model for a web service, with data flows, threats, ratings and chosen mitigations.

Good design turns requirements and threats into structure. You design authentication and session handling, authorization, data protection, error handling and logging, and review architectures for the common weaknesses of distributed systems.

• Secure design patterns and anti-patterns
• Authentication, session and token design
• Authorization models in application design
• Cryptography in design: what to use and what to avoid
• Error handling, logging and auditing design
• Securing APIs, microservices and cloud-native designs
• Architecture risk review

You build A secure architecture document for a multi-tier application, with the design reasoning for each control.

Most exploited weaknesses are old and well known. You write code that validates input, encodes output, manages memory and state safely, and handles errors without leaking, then review code the way an attacker reads it.

• Input validation and output encoding
• Injection, cross-site scripting and request forgery
• Memory safety and language-specific hazards
• Concurrency, race conditions and state
• Secure use of cryptographic libraries
• Error handling and information leakage
• Peer review and static analysis in practice

You build A secure coding guide with reviewed examples of fixes for the common weakness classes.

Testing proves that the controls you designed hold up under pressure. You plan a security test strategy, use static, dynamic, interactive and composition analysis, fuzz inputs, run penetration tests, and handle defects by their real risk.

• Security test planning and coverage
• Static and dynamic analysis compared
• Interactive testing and software composition analysis
• Fuzzing and negative testing
• Penetration testing of applications
• Scoring defects with CVSS and context
• Regression testing for security fixes

You build A security test plan and a triaged results report for one application build.

A secure build can be undone by an unsafe release. You harden configuration, protect the build pipeline and signing keys, manage secrets and infrastructure as code, and gate releases on security evidence.

• Secure configuration and hardening at release
• Build pipeline security and artifact signing
• Secrets management in deployment
• Infrastructure as code review
• Release criteria and go or no-go decisions
• Rollback and deployment safety

You build A release checklist and pipeline design with signing, secrets handling and release gates.

Security work continues long after release. You monitor software in production, receive and handle vulnerability reports, patch with discipline, respond to incidents in your own code, and retire products without orphaned data or access.

• Runtime monitoring and application logging
• Vulnerability disclosure and coordinated response
• Patch management and emergency fixes
• Incident response for software defects
• Bug bounty and external reporting
• End of life and secure decommissioning

You build A vulnerability handling and patch process, with a disclosure policy and a decommissioning checklist.

Most of the code you ship was written by someone else. You inventory dependencies, evaluate components and vendors, require assurance in contracts, track licenses, and protect the build chain from tampering.

• Open source and third-party component risk
• Software bills of materials
• Vendor and outsourced development assurance
• Contract language for software security
• License compliance and legal risk
• Supply chain frameworks and build provenance

You build A software bill of materials and a component risk register for one product.

Follow one product through every stage. You write the requirements, model threats, design controls, test, release, and plan operations and supply chain oversight, and justify the choices as a security lead would.

• Framing the product and its risk
• Requirements and threat model
• Design and implementation decisions
• Test strategy and release criteria
• Operations and vulnerability handling
• Supply chain and end-of-life plan

You build A secure lifecycle plan for a real product, with artifacts from each stage.