Chapter 4 Checkpoint
The secure-SDLC toolkit, all together. This mixed quiz pulls from every lesson. Passing means you can describe how security is built into each stage of making software — from a whiteboard threat model to a hardened, verified build pipeline.
The quiz samples from a larger bank each attempt. The chapter's through-line: the cheapest fix is the earliest one, so security shifts left into design, code, build, and supply — as a continuous, mostly-automated habit, with humans focused on the judgment work (threat modeling, review) that tools can't do. If a question stings, follow its revisit link.
What you should be able to do now
- Explain shift-left and DevSecOps — the cost curve, and security as continuous/automated/shared.
- Run a threat model — the four questions, a DFD with trust boundaries, STRIDE, and a lightweight per-feature ritual.
- Make secure design choices (fail closed, complete mediation, simplicity) and review code for vulnerabilities and missing controls.
- Place SAST, DAST, and SCA by what they examine, and wire them into CI for signal, not noise.
- Scan the artifact, not just the code — secrets, IaC misconfig, and container images.
- Secure the supply chain — SBOM, signing/provenance, SLSA, and dependency hygiene.
The checkpoint
Chapter 4: Secure SDLC & DevSecOps
Pass to unlock the Next button belowChapter 4 complete
You now see security not as a final gate but as a property of how software is made: threat-model the design, choose secure architectures, review for the missing control, scan code/dependencies/secrets/infra/images automatically in CI, and verify everything that enters your build. That's a secure SDLC — the engine that turns Chapter 3's one-time bug knowledge into permanent, scalable prevention.
→ On to Chapter 5: Penetration Testing & Red Teaming — we cross fully to the offensive side and put all this defending to the test, learning the methodology attackers (and the security engineers who emulate them) actually follow.