The secure software development lifecycle
You learn which security work belongs to each step of software’s journey from idea to production and set up a practical secure development process for a small team.
Level 101 · 16 lessons · 15 practice labs
Lessons
Getting to know the lifecycle
- The stages of the software lifecycle: from idea to maintenance
- The cost of a flaw found late
- Who owns what: developers, testers, operations and security
- Secure development frameworks: NIST SSDF and OWASP SAMM
- Short task: place security activities on a sample project’s stages
Requirements and design
- Writing security requirements with OWASP ASVS
- Abuse cases: the dark side of a user story
- Secure design principles: least privilege, defence in depth, secure defaults
- Design review: which questions to ask
- Short task: write five abuse cases for a login feature
Build, test and release
- Reviewing code with a security eye
- Automated checks: SAST, SCA and secret scanning
- Release criteria: which findings stop a release
- After release: vulnerability disclosure and security.txt
- Short task: draft a pre-release security checklist for your team
Capstone
- Capstone: build security into a small team’s development process
Practice labs
- Place security activities on the lifecycle stages: Distribute ten security activities across requirements, design, build, test, release and maintenance.
- Work out the cost of a late-found flaw from sample data: Compare the hours spent when the same flaw is found in design, in test and in production, and explain the difference in one sentence.
- Draw up a project’s responsibility matrix: Fill in a table for Göktaşı Yazılım’s team showing who does, approves and is informed for twelve security tasks, and find the task nobody owns.
- Pick the ASVS items for a feature: Find five ASVS requirements that apply to a password reset feature and list them with their numbers.
- Write five abuse cases for a login feature: Write an abuse case against each user story and the requirement that would prevent it.
- Turn vague requirements into testable security requirements: Rewrite six statements of the must-be-secure kind with measurable acceptance criteria and say how each will be tested.
- Find the insecure default in a design: Mark two settings left open by default in a one-page design note and write the safe value.
- Apply the design review questions to a feature: Answer ten questions on identity, authorisation, data and errors for a file sharing feature and note the three left open.
- Add a second layer to a design that relies on one defence: Identify the missing layers in a payment flow that trusts front-end checks only and draw a corrected design applying least privilege and defence in depth.
- Match SSDF practices to sample activities: Place eight team activities under the four practice groups of NIST SSDF.
- Score a team on two SAMM practices: Determine from interview notes the maturity level for threat assessment and security testing and write the evidence.
- Derive a three-month improvement plan from the assessment: Write a plan with measurable goal, owner and end date for the three lowest-scored areas and state what you deliberately defer.
- Fill in the pre-release security checklist: Tick the scan results, open findings and approvals items for a sample release by checking the evidence.
- Write the intake process for a vulnerability report: Prepare a short process and a security.txt file showing who receives an outside report, the response time and the fix steps.
- Write a project’s secure development plan from start to finish: Prepare a two-page plan for Lavinya Klinikleri’s appointment app with the security activity, its output and the exit criterion at every stage.
About this course
You learn which security work belongs to each step of software’s journey from idea to production and set up a practical secure development process for a small team.
What you will learn
- Getting to know the lifecycle
- Requirements and design
- Build, test and release
- Capstone
Prerequisites
No prior knowledge is needed; the course starts from zero.
Lab environment
Lessons run in your own Kali Linux terminal that opens in the browser. Nothing to install; the lab starts clean in every lesson.
Frequently asked questions
- Is this course right for my level?
- The course is at beginner level; every term is explained where it first appears.
- Is there anything to install?
- No. Every lesson runs in your own lab environment that opens in the browser.
- How do lessons work?
- Each lesson has 8 to 10 steps and a short quiz. Early steps show the command to type, later steps give less help; if two attempts fail, the solution opens.
- Can I try it for free?
- Yes. The first three lessons of every course are free.