Practice and strategy · Module 1
Secure SDLC
Security becomes real when it is built into how work ships.
Previously
Start with Cybersecurity Practice and Strategy
Join up governance, secure design, DevSecOps, CVEs, incident response and business-focused risk thinking.
This module
Secure SDLC
Security becomes real when it is built into how work ships.
Next
Exposure reduction and zero trust
Zero trust is simple.
Progress
Mark this module complete when you can explain it without rereading every paragraph.
Why this matters
A secure SDLC is not a list of gates that slow teams down.
What you will be able to do
- 1 Explain what a secure SDLC is and what it is not
- 2 Choose a small set of gates that catch the right failures early
- 3 Write controls that are verifiable through evidence
Before you begin
- You understand what a deployment is and what a CI pipeline does
Common ways people get this wrong
- Bypass culture. When gates feel unfair, bypass becomes normal. Then the system has no control surface.
- False confidence. A pass result can hide gaps. Review what you do not test.
Security becomes real when it is built into how work ships. A secure SDLC is not a list of gates that slow teams down. It is a set of small controls that make failure harder to hide and easier to recover from.
The practical question is where you place controls so they catch the right problems at the right time. The early stages should catch design mistakes. The later stages should catch configuration and drift. The goal is not perfect prevention. The goal is verified safety and fast containment.
Use the tool below to write a minimal release posture for one product. Keep it small enough that teams can follow it on a bad day.
Mental model
Secure SDLC gates
Security becomes real when it lives in the delivery pipeline, not only in review meetings.
-
1
Design review
-
2
Build
-
3
Test
-
4
Release gate
-
5
Production
Assumptions to keep in mind
- The gate is usable. If the gate is too slow or unclear, teams route around it. Usability is a security property.
- Checks match risk. Pick a small number of checks that catch real failures. More checks is not always safer.
Failure modes to notice
- Bypass culture. When gates feel unfair, bypass becomes normal. Then the system has no control surface.
- False confidence. A pass result can hide gaps. Review what you do not test.
Check yourself
Quick check. Secure SDLC
0 of 5 opened
What is the point of a secure SDLC
To build safety and verification into delivery so failures are caught early and contained fast, without relying on heroics.
Scenario. A team says 'security review done' but cannot show what was checked. What is missing
Verifiable evidence. A gate must specify what was checked, by whom, with what artefact, and what pass looks like.
What is a useful quality for a gate
Measurable, repeatable, owned, and hard to bypass accidentally.
Scenario. A gate is so painful that teams routinely bypass it. What did you build
A theatre control. The process now hides risk instead of reducing it. You need smaller, earlier, automated checks with clear exceptions.
What should every gate have
An owner, a trigger, a pass and fail definition, and an audit trail that is easy to retrieve.
Artefact and reflection
Artefact
A gate plan you could use in a design review
Reflection
Where in your work would explain what a secure sdlc is and what it is not change a decision, and what evidence would make you trust that change?
Optional practice
Pick a small set of controls per stage and define how you will verify they work.