Learn the vocabulary of systematically enumerating a system's assets, entry points, and attackers before writing code.
0 / 5 completed
1 / 5
A teammate describes a structured process run early in a design phase that systematically enumerates a system's assets, entry points, and potential attackers, then ranks the resulting risks before any code is written. What practice is being described?
Threat modeling is exactly this: a structured process, often run during design, that systematically enumerates a system's assets, entry points, trust boundaries, and potential attackers, then ranks the resulting risks so mitigations can be designed in before any code is written. A hash collision is an unrelated hash-table concept about two keys sharing a bucket. This enumerate-and-rank-risks-before-coding approach is exactly why threat modeling is a standard step in secure design review rather than something done only after an incident.
2 / 5
During a design review, the team runs a threat-modeling session for a new payments API, specifically to identify entry points an attacker could exploit and rank them by impact before any implementation begins. Which capability does this provide?
Threat modeling here provides early, structured identification of the system's highest-risk attack surface, since the process ranks concrete entry points and attacker capabilities before code exists that would be expensive to change later. Waiting for a penetration test after the API ships finds vulnerabilities only after implementation choices are already baked in, making fixes costlier. This identify-risks-before-implementation behavior is exactly why threat modeling is favored during design rather than after release.
3 / 5
In a code review, a dev notices a new payments API shipped without any documented entry-point or trust-boundary analysis, and the only security review happens via an external penetration test scheduled months after launch. What does this represent?
This is a missed threat-modeling opportunity, since enumerating entry points and trust boundaries during design would surface high-risk issues before implementation instead of relying solely on a delayed penetration test. A cache eviction policy is an unrelated concept about discarded cache entries. This ship-without-analysis pattern is exactly the kind of gap a reviewer flags once a sensitive system like a payments API is involved.
4 / 5
An incident report shows a payments API's most severe vulnerability, an unauthenticated internal admin endpoint, was only discovered by a penetration test three months after launch, because no structured entry-point analysis happened during design. What practice would prevent this?
Running a threat-modeling session during design lets entry points like the internal admin endpoint be enumerated and their exposure risk ranked before implementation ships. Continuing to rely solely on a delayed penetration test regardless of how severe an undiscovered entry point might be is exactly what let the vulnerability go unnoticed for months in this incident. This design-time-enumeration approach is the standard fix once relying only on post-release testing is confirmed to be too slow to catch severe issues.
5 / 5
During a PR review, a teammate asks why the team runs formal threat modeling instead of just relying on a penetration test after each release, given that penetration tests are already budgeted and scheduled. What is the reasoning?
Threat modeling trades some upfront design-time effort for catching high-risk issues before implementation is locked in, while a penetration test is valuable but only runs after release, when fixes to architectural issues are far more expensive. This is exactly why threat modeling is favored during design for sensitive systems, while a post-release penetration test remains a useful, complementary check rather than a substitute for design-time analysis.