A product team is about to begin building a new customer-facing payments service and asks a security architect when, in the application lifecycle, design-level security flaws such as missing authorisation boundaries and unsafe trust assumptions should be identified. The architect wants the practice that surfaces these flaws before code is written, by reasoning about the system's data flows and trust boundaries. Which practice best meets this requirement?
- APerform threat modeling during the design phase, enumerating data flows and trust boundaries to identify and rank design weaknesses before any code exists. Correct
- BRun dynamic application security testing against a deployed staging build so that exploitable runtime weaknesses are discovered before the service reaches production traffic.
- CAdd static application security testing to the build pipeline so that insecure coding patterns are flagged automatically every time a developer commits source.
- DSchedule an external penetration test ahead of launch so that an independent team validates the service's defences against realistic attacker techniques first.
Why A is correct: Threat modeling is the design-phase activity that maps data flows and trust boundaries to expose architectural weaknesses such as missing authorisation, so it identifies and ranks design flaws exactly when the requirement demands, before implementation begins.
Why B is wrong: Dynamic testing is valuable and tempting because it finds real exploitable issues, but it runs against built, deployed code and so cannot surface the design-level trust-boundary flaws the requirement targets before code is written.
Why C is wrong: Static analysis catches insecure code patterns and feels like the earliest control, but it operates on committed source rather than the architecture, so it misses design flaws that exist before code and that no scanner reads from a diagram.
Why D is wrong: A penetration test gives independent assurance and is appealing as a gate, but it happens against a near-complete system late in the lifecycle, so it finds design flaws only after they are expensively built rather than before code is written.