Secure SDLC — threat modelling at design time — DevSecOps & Security Automation

A Secure Software Development Lifecycle weaves security controls into each phase of building software, from requirements through design, implementation, testing, and maintenance. The most valuable of these controls is threat modelling performed at design time, before a single line of vulnerable code exists. This lesson explains how structured threat modelling helps teams anticipate how an attacker might abuse a system, so defences are designed in deliberately rather than patched in reactively after an incident.

Analogy🏏Cricket

✈️ Think of it like travel: a seasoned trip planner does not wait until the airport to check passports, visas, and vaccinations — they resolve every requirement while still at the kitchen table, when changing plans costs nothing. Sorting problems at the destination is chaos. A Secure SDLC works the same way, building controls into requirements, design, and implementation instead of the final test. Threat modelling at design time anticipates how an attacker might abuse a system before any vulnerable code exists. This reveals that the cheapest place to prevent a security disaster is the planning table, long before departure.

Threat modelling answers four grounding questions: what are we building, what can go wrong, what will we do about it, and did we do a good enough job. Teams typically start by drawing a data-flow diagram showing components, data stores, and the trust boundaries data crosses. Each boundary is a place where assumptions change and attackers probe, so mapping them early reveals exactly where authentication, validation, and encryption controls genuinely need to live.

Analogy🏏Cricket

📷 Think of it like photography: before pressing the shutter, a careful photographer frames the scene, asking what is in shot, what could ruin it, how to fix the light, and whether the composition is good enough. That deliberate survey exposes exactly where a stray shadow or reflection will spoil the image. Threat modelling asks the same four grounding questions and draws a data-flow diagram, marking the trust boundaries data crosses. Each boundary is where assumptions change and attackers probe. This reveals that mapping the frame first shows precisely where your controls truly need to stand.

A widely used lens is STRIDE, which prompts teams to consider six categories of threat: Spoofing identity, Tampering with data, Repudiation of actions, Information disclosure, Denial of service, and Elevation of privilege. Walking each component of the diagram against these six categories turns a vague fear of "getting hacked" into a concrete, prioritised list of specific risks, each paired with a defensive control the team can design, schedule, and later verify against.

Analogy🏏Cricket

♟️ Think of it like chess: rather than a vague dread of 'getting checkmated', a disciplined player studies known tactical motifs — forks, pins, skewers, discovered attacks — checking the board against each so danger becomes concrete and answerable. STRIDE gives security the same six-lens checklist: spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. Walking each component against these categories converts a fuzzy fear of being hacked into a prioritised list of specific, defensible risks. This reveals that naming threats precisely is what makes them possible to defend.

text

# Simplified STRIDE walkthrough for a login component
Component: Authentication service (crosses user -> app trust boundary)

Spoofing        -> enforce MFA; validate session tokens server-side
Tampering       -> sign and verify JWTs; reject unsigned claims
Repudiation     -> write immutable audit logs for auth events
Info disclosure -> return generic errors; never leak "user not found"
Denial of svc   -> rate-limit login attempts; add exponential backoff
Elevation       -> deny by default; check authz on every request

Analogy🏏Cricket

🏏 Think of it like cricket: a shrewd captain studies the pitch and the opposition before the toss, reading which deliveries will swing and where the rough will turn, then sets the field deliberately in advance rather than after losing three quick wickets. Every fielder stands where the danger is greatest. Modelling threats at design time works identically, placing your controls exactly where an attacker's likely moves will land before the innings even begins. This reveals that anticipation, not reaction, is what keeps a well-set defence one step ahead of the batsman.

Best practice keeps threat modelling lightweight and continuous rather than a heavyweight one-off document. Short sessions triggered by any significant design change, a shared diagram everyone can edit, and a living backlog of mitigations tied to real tickets keep the exercise honest. Crucially, each identified threat should map to a testable control, so later automated scans and code reviews can confirm the defence was actually implemented and not merely written down and quietly forgotten.

Analogy🏏Cricket

💪 Think of it like fitness: real progress comes not from one punishing marathon session but from short, regular workouts logged and adjusted as your body changes, each exercise chosen to strengthen a specific muscle you can later measure. Threat modelling stays healthy the same way — lightweight sessions triggered by design changes, a shared living diagram, and a backlog of mitigations tied to real tickets. Crucially, each identified threat maps to a testable control, so scans and reviews can confirm the defence was actually built. This reveals that a habit you can verify beats a heroic document nobody revisits.

In the real world, a fintech designing a new transfer feature might model it before development begins and discover that a missing server-side amount check would let a client tamper with transaction values. Catching that at the whiteboard costs one conversation; catching it after launch could mean fraudulent transfers, refunds, and regulatory scrutiny. The diagram and STRIDE pass turn an expensive future breach into a cheap present design decision.

Analogy🏏Cricket

💰 Think of it like finance: spotting a flaw in a loan contract during the drafting meeting costs a single revised clause, but discovering it after millions have been disbursed means clawbacks, penalties, and regulators at the door. The earlier the error is found, the smaller the bill. A fintech modelling a transfer feature before coding might notice a missing server-side amount check that would let a client tamper with values. Catching it at the whiteboard costs one conversation; catching it after launch means fraud and scrutiny. This reveals that a design-time review is the highest-yield investment on the ledger.

A Secure SDLC builds controls into every phase, not just testing.
Threat modelling at design time anticipates abuse before vulnerable code exists.
Data-flow diagrams expose trust boundaries where controls truly belong.
STRIDE gives six threat categories that convert vague fear into a prioritised list.
Every identified threat should map to a testable, verifiable control.