Moving security review earlier changes what a penetration test finds — and what it costs to fix. A practical case for lightweight threat modeling in planning.
Most teams meet a threat model for the first time in a penetration test report — as a finding, not a planning input. By then, the architecture is shipped, the API contract is public, and 'fix' means retrofit.
A lightweight threat-modeling pass at design time doesn't need a formal STRIDE workshop with a dozen stakeholders. For most product teams, it's a 45-minute conversation with three questions: what are we trusting the client to enforce that the server should enforce instead, what identity and permission checks does this feature actually need, and what does an authenticated-but-malicious user do with this feature that a legitimate one wouldn't.
I've watched this single habit change what a later penetration test finds. Engagements on teams that threat-model early skew toward medium-severity edge cases. Teams that don't, skew toward the same authorization and trust-boundary failures, over and over, because the decision that created them was made in a design doc nobody security-reviewed.
The goal isn't to eliminate the penetration test — it's to make sure the penetration test is confirming your defenses instead of discovering your gaps for the first time.