What security activities occur during the Verification phase of SDL?

Question

Accepted Answer

This is where you actively try to break the finished code — fuzzing, pen-testing, and code review on the "code-complete" build, plus a re-check that the design still holds against threats that have emerged since.
Verification is the adversarial phase: design and implementation were about preventing flaws, verification is about finding the ones that got through. The heavy testing happens once the build is "code complete," but planning starts early. What it achieves:

Fuzz testing — automatically bombarding the program with malformed or random input (files, installable ActiveX-style controls, network packets) to crash it; a crash on bad input usually marks an exploitable parsing bug. It's brilliant at finding flaws no human thought to test.
Penetration testing and code review — humans actively attacking the system and reading the security-critical code, to catch logic flaws that fuzzers and static tools miss.
Re-evaluate the attack surface — the real attack surface often grew during coding (a debug port left open, an extra API added), so you re-measure it against the design.
Re-review design against new threats — a model written months ago may have missed an attack technique that's since become known; you revisit it.
Start security response planning — prepare the process for handling externally reported vulnerabilities before you ship.

A "security push" — a dedicated all-hands burst of review and testing — can be run if needed, but it's increasingly rare and is not a substitute for doing security work continuously through development; a push can't rescue a product that ignored security until the end.