Module 5 of 5
Building it secure
The earlier modules found vulnerabilities one class at a time. This module is about the engineering habits that stop them recurring: secure defaults, adversarial tests, a controlled dependency supply, and security-focused code review.
Every lesson so far has ended the same way: a specific mistake, a specific fix. Fixes one at a time do not scale. A team that ships every week will reintroduce injection, missing authorization checks and unsafe file handling unless the way it builds software makes those mistakes hard to write, quick to detect, and visible in review. This module is about that machinery.
The four lessons cover frameworks and platforms whose defaults catch the mistake before it ships, tests written by someone trying to break the code, the third-party code that makes up most of what you deploy, and code review that follows data from where it enters to where it can do harm. By the end you should be able to look at a team’s toolchain and say which classes of bug it prevents by construction, which it detects, and which still depend on someone remembering.
Lessons
- 5.aSecure defaultsHow do I make the secure way the easy way, so a forgotten step does not become a vulnerability?19 min
- 5.bAdversarial testingHow do I test for what the code must never do, including inputs I did not think of?18 min
- 5.cDependencies and supply chainHow do I control the third-party code my application installs and runs?20 min
- 5.dSecurity code reviewWhat should I look for when reviewing code for security, and how do I write findings that get fixed?19 min