Security through the SDLC — threat modeling and secure code review basics
Every specific vulnerability covered earlier in this domain is easier and cheaper to prevent BEFORE code is written than to find and fix after it ships — threat modeling and secure code review are the two real, practiced disciplines for doing exactly that, systematically rather than by luck.
4 min read
Why finding a vulnerability before shipping is categorically cheaper than after
Recall this platform's Testing & QA domain's opening argument: a bug's
fix cost scales with how far it travels before being caught. Security
vulnerabilities follow the EXACT same curve, with an extra, real
dimension — a bug caught in review costs review time; the SAME bug
found by an attacker in production can mean a genuine data breach,
regulatory exposure, and real user harm, not just an engineering fix
This domain's earlier lessons each covered a specific vulnerability's mechanism and fix — but finding which of those vulnerabilities might exist in a specific feature, before it ships, is a distinct, real skill of its own. The same cost curve this platform's Testing & QA domain established for ordinary bugs applies here with real, added stakes: a security bug caught in design or code review costs review time; the same bug found by an actual attacker in production can mean a genuine security incident.
Threat modeling: systematically asking "how could this be attacked," before building it
For a new feature — "let users share a document with a specific email
address" — a real threat-modeling pass asks concrete questions:
- Who can access this feature? (Authentication — covered in the Auth domain)
- Once authenticated, what should they be ALLOWED to do here specifically?
(Authorization — recall this domain's broken-access-control lesson)
- What untrusted input does this feature accept? (The email address,
the document ID — recall the trust-boundary lesson)
- What happens if someone provides input this feature DIDN'T expect?
Threat modeling is the practice of systematically walking through a feature's design — before or during implementation, not after — asking what could go wrong at each trust boundary it touches, using the same categories this domain already established (who's authenticated, what are they authorized to do, what untrusted input crosses in). This isn't a vague, unstructured "think about security" exercise — it's a genuinely systematic pass over a design, using the specific vocabulary this domain has built up (trust boundaries, authentication vs. authorization, IDOR-shaped gaps) as the concrete checklist.
A structured way to think through threats: STRIDE, as a concrete lens
S — Spoofing: can someone impersonate a legitimate user or system?
T — Tampering: can data be modified in a way it shouldn't be?
R — Repudiation: can an action happen with no way to prove who did it?
I — Information disclosure: can someone see data they shouldn't?
D — Denial of service: can someone make the system unavailable?
E — Elevation of privilege: can someone gain MORE access than intended?
STRIDE is a real, widely-used mnemonic for structuring a threat-modeling pass — walking through each category against a specific feature turns a vague "think about security" instruction into six concrete, specific questions, each mapping directly onto vulnerability classes this domain already covered (Tampering maps onto injection/deserialization concerns; Elevation of Privilege maps onto broken access control; Information Disclosure maps onto IDOR and SSRF). This isn't the only threat-modeling framework that exists, but it's a genuinely practical, concrete starting point rather than an abstract exhortation to "be more careful."
Secure code review: the same trust-boundary lens, applied to an actual diff
Reviewing a pull request that adds a new database query, a new file
operation, or a new endpoint accepting user input — the reviewer's
specific, concrete questions:
- Does this query use parameterization, or does it concatenate
untrusted input into SQL? (recall the SQL-injection lesson)
- Does this endpoint check the CURRENT user actually owns/can access
the specific resource being requested? (recall broken access control)
- Is untrusted output being escaped before being rendered? (recall XSS)
Secure code review isn't a separate, additional review pass bolted onto ordinary code review — it's the same trust-boundary questions this domain has built up applied directly to a specific diff, at the exact point new code crosses a trust boundary (a new query, a new file path built from user input, a new place output gets rendered). A reviewer who's internalized this domain's specific mechanisms (not just "security is important" in the abstract) can look at a diff and recognize, concretely, "this concatenates a user-supplied value into a query" or "this doesn't check resource ownership" — the same pattern-recognition this domain's earlier field-reference-style lessons in other domains have built toward.
Further reading
Check your understanding
A quick comprehension check — not tracked, not graded, just for you.
1. Why does threat modeling before implementation follow the same economic logic as this platform's Testing & QA domain's core argument?
2. What does STRIDE actually provide as a threat-modeling tool?
3. How does secure code review differ from a separate, additional review pass on top of ordinary code review?