VAST is chosen to model 700 insurer applications in two quarters: what scales, and what depth is lost?

## The constraint VAST is aimed at A global insurer that has absorbed three acquisitions is carrying roughly 700 applications, and is told to hold a threat model for each of them inside two quarters. Work out the arithmetic of the classical approach first, because that is the answer's foundation. A facilitated threat-modeling workshop — an expert in the room, a data-flow diagram drawn together, STRIDE walked per element — takes most of a day plus write-up, and it consumes a scarce specialist. With, say, six specialists who also have other duties, the portfolio is a multi-year programme. The mandate is not achievable by adding discipline; it is arithmetically out of reach. VAST's premise is that the scarce resource must be removed from the critical path. It does that by choosing notation the delivery team can already produce: the application threat model is a **process-flow diagram** of features, use cases and the calls between components, which looks like the journeys and service maps teams already draw. The team authors; the specialist reviews. That converts a serial queue into parallel work across 700 teams, and it is the entire scalability argument. ## The second benefit: a portfolio you can query Because every model has the same shape, the set of them becomes an asset in its own right. Across a heterogeneous estate assembled by acquisition — different stacks, different eras, teams you have never met — you gain the ability to ask questions no individual model answers: which applications hold policyholder data, which accept traffic from the public internet without authentication, which of the acquired systems still talk directly to a legacy policy database. That aggregate view is often worth more to a security leader than any single deep model, and it is unavailable if you have twenty excellent models and 680 unknowns. ## What you are actually trading away Be specific here; "less depth" alone is a weak interview answer. - **Expert elicitation.** Many of the best threats in a facilitated session come from someone asking an unprompted question — what happens if this call is replayed, what does this component do when the downstream one lies to it. A self-service model captures structure, not that dialogue. - **Business-context reasoning.** Nothing in a per-application model set tells you which attacker would target this system and what they gain. Methods like PASTA build that in deliberately; VAST does not, and a shallow model of a high-value system can look identical to one of a low-value system. - **Cross-component subtlety.** Flaws that live in the interaction of two components, especially two owned by different teams, are exactly what a team modelling its own application does not see. - **Uneven quality.** Model quality now tracks team maturity. Two of the acquisitions will produce good models and one will produce diagrams that omit the authentication step entirely. - **Shared infrastructure.** If the operational model half of VAST is not funded, threats to shared services belong to nobody and get written down nowhere. ## How a senior engineer designs around the trade Accept breadth as the floor, not the ceiling. Two things follow. First, tier the portfolio: identify the systems that move money or hold the largest concentration of policyholder data and fund real depth on those — a facilitated session, expert-authored, with the business-context reasoning the self-service models lack. Second, use the breadth to *find* the tier. The 700 shallow models are how you discover which acquired system is quietly internet-exposed; you did not know that before you had them. The other structural move is to put the acquisitions' shared and legacy infrastructure into operational models early. The acquired estate's worst risks are usually not inside any one application; they are in the connective tissue — a shared database credential, an old integration bus, a vendor VPN — and the operational model is the only place in VAST where those have a home. ## Where the premise breaks VAST's scalability rests on a team that knows its own system being available to draw it. For an acquired application with no owner, no documentation and a vendor who left, there is no one to produce the model, and pushing the mandate produces a diagram someone guessed. Those systems need a different treatment: model them from the outside in the operational view — what they connect to, what data they hold, who can reach them — and be explicit that no application model exists. ## What a strong answer sounds like Name the constraint (specialist time), name the mechanism (notation the team owns, specialist moves from author to reviewer), name the second benefit (portfolio-level queries), then volunteer the losses without being asked, and finish with the tiering that makes the trade defensible. Candidates who claim VAST loses nothing, or who dismiss it as "threat modeling theatre" without engaging with the arithmetic that motivated it, both come across as having only read about it.