The Software Security Testing Lifecycle: The framework testers need

The speaker argues that security testing is usually bolted on late, so findings arrive as a list of alerts that developers push back on. To address this, the talk introduces the Software Security Testing Lifecycle, a framework meant to supplement an existing secure development lifecycle rather than replace it. It is aimed at testers and at anyone else who influences how a product is built.

The walk-through moves phase by phase. It starts with security requirements drawn from laws, business expectations and internal policy. Threat modeling follows, with testers in the room, and STRIDE pairs each threat with the control meant to stop it. The testing strategy then maps every threat and control to a unit test, an automated scan or a manual check. Security unit tests take an attacker's view instead of only confirming the happy path. Scanners need customizing for the application or they generate noise, and fuzz targets keep fuzzing limited to interfaces named in the threat model.

The final stage is hands-on validation of scanner findings and of the controls identified in threat modeling. Testers define pass and fail criteria in advance, confirm each issue, and find the root cause, so the fix is a code change, a corrected control or a new control. Retesting checks that the fix did not introduce a new weakness. The main takeaway is that the first three steps, covering requirements, threat modeling and strategy, give a team a usable plan even with limited resources, and the rest can be scaled to the project.