What does a data-flow diagram deliberately omit, and which threats hide in those omissions?

## What a data-flow diagram is actually for A data-flow diagram (DFD) is a static picture of where data lives and where it travels: **processes** that transform data, **data stores** that hold it, **external entities** outside your control, and **flows** connecting them, cut by **trust boundaries** where the level of trust changes. That projection is chosen deliberately. Element-by-element enumeration methods work directly off this element list: STRIDE walks each element asking about spoofing (violating authentication), tampering (violating integrity), repudiation (violating non-repudiation), information disclosure (violating confidentiality), denial of service (violating availability) and elevation of privilege (violating authorization). A DFD is the notation that makes that walk mechanical. Every diagram is a projection, and a projection is defined as much by what it discards as by what it keeps. ## The four families a DFD discards 1. **Control flow and ordering.** An arrow means data moves in that direction. It does not mean this call happens first, or once, or only after that other call. There is nowhere on a DFD to say what state the process was in when the flow arrived. 2. **Retries, timeouts and delivery semantics.** Whether a flow is at-most-once, at-least-once or exactly-once is not expressible. Neither is what the caller does when it times out. 3. **Error, exception and fallback paths.** DFDs are drawn from the happy path. The branch taken when validation fails, when a dependency is down, or when deserialization throws, usually never gets drawn. 4. **Time, state and volume.** Session lifetimes, token expiry, rate, and how long data lingers in a store are all outside the notation. ## The threats that hide in the gaps - **Replay.** A message captured and re-sent is accepted again, because nothing on the diagram says a flow may only be honoured once. - **Time-of-check to time-of-use races.** The check and the use are two flows on the diagram with no ordering relationship drawn between them. - **Double-processing.** At-least-once delivery plus a non-idempotent handler produces a double credit or a double shipment. The DFD shows one arrow either way. - **State-machine skipping.** A step reached without its prerequisite, because the diagram never claimed a prerequisite existed. - **Failure-path spill.** Raw payloads written into a dead-letter store, a log line or a crash dump that appear on no diagram and in no data inventory. - **Insecure fallback.** A downgrade to a weaker path when the primary one fails, invisible because the failure branch was never drawn. ### A worked case An event-driven order pipeline models cleanly: a checkout process, an order service, an order store, one boundary at the internet edge. The consumer cannot deserialize a malformed message, so the platform dead-letters the raw message into an object bucket for operators to inspect. That bucket is on no diagram. The raw message carries the customer's name, delivery address and contact details, and every operator with read access to that bucket now holds a copy that never entered the data inventory or the retention policy. The adversary here is an insider with entirely legitimate access; the asset is customer personal data. No amount of staring at the DFD surfaces this, because the notation has no place for error handling. Walking the failure path of each flow surfaces it immediately, and the remedy is to draw the failure sink back onto the DFD as a real data store with its own boundary crossing. ## What to do about it Treat the DFD as the entry point, not the whole model. For each flow, ask three unhappy-path questions: what happens if it fails, what happens if it is repeated, and what happens if it arrives out of order. When any answer is interesting, draw a message-ordering view of that one flow, showing each message in sequence with its freshness or idempotency protection annotated, and enumerate against that instead. Then draw whatever failure sinks you discovered back onto the DFD, because that is what the DFD is good at: showing where data comes to rest and which boundaries it crosses. The mistake to avoid is the opposite over-correction, replacing the DFD with a behavioural view. An ordering view of one interaction tells you nothing about the eleven data stores elsewhere in the system or where your boundaries are. The two views answer different questions, and a competent model uses the cheapest view that makes the threat you are hunting visible.