Threat Modeling

Modeling Before Code

Attackers rarely start where you expect. They start where the architecture leaks trust.

Threat modeling is a structured decomposition of your application architecture. You look for entry points and attack vectors before a single line of code exists.

Done early in the SDLC, it moves a team away from patch-and-fix reaction toward secure-by-design intent.

Draw The Data Flow

The work starts with a picture, not a checklist.

Data flow diagrams show how data actually moves through the system. They expose the paths an adversary can follow.

On top of the DFD you mark trust boundaries: the points where data transitions between different levels of control. Those transitions are where scrutiny pays off most.

Notice that the risk concentrates exactly where the data flow arrow crosses the dashed boundary between two levels of control.

STRIDE As A Lens

Frameworks keep the analysis honest. STRIDE gives you six categories to anticipate adversary behaviour at each element of the diagram.

Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.

Walk each category against each data flow and trust boundary. Gaps that intuition skips become visible.

Applying STRIDE Systematically

STRIDE is systematic because you apply it the same way every time.

Take one element of the diagram. Ask all six questions. Record what the architecture does not defend against. Then move to the next element.

The discipline is in the repetition, not in cleverness.

Keeping Pace With CI/CD

A threat model that ages becomes fiction.

Advanced practitioners automate threat model updates so the model keeps pace with CI/CD pipelines.

The goal is simple: architectural changes must not introduce unforeseen vulnerabilities that nobody re-examined.

The Blueprint For Everything Else

The threat model is not the end of the work. It is the blueprint for what follows.

Security testing, code review, and incident response planning all draw their priorities from it.

When the model ranks the most critical risks, downstream effort lands where it matters.

Threat modeling should begin during architecture design, before implementation, so teams can identify threats early.

• True
• False

Answer: True

Threat modeling is most valuable early in the software development lifecycle, when architectural changes are still practical. This supports secure-by-design work instead of reacting with patches after deployment.

When analyzing an application, a _____ shows how data moves, while _____ mark transitions between control levels.

Answer: When analyzing an application, a data flow diagram shows how data moves, while trust boundaries mark transitions between control levels.

A data flow diagram maps movement through the system. Trust boundaries are marked on that diagram to identify changes in control that may require deeper security analysis.

Which action best follows a systematic STRIDE analysis of an application architecture?

• Ask all six STRIDE questions for each diagram element and record gaps
• Focus only on the attack category that seems most likely
• Wait until code review to search for threats in implementation details
• Review only the application's public login endpoint

Answer: Ask all six STRIDE questions for each diagram element and record gaps

Systematic STRIDE analysis examines one diagram element with all six threat categories, records missing defenses, and proceeds to the next element. This repetition reduces gaps that intuition might miss.