Check the assumptions in the deployed system
Users, administrators, applications, queues, storage, identity providers and external services can each change the ownership, privilege or sensitivity involved in an operation. For example, an application may trust an identity header supplied by a proxy. That only works if an untrusted caller cannot reach the application with a header of its own.
The diagram may describe the intended arrangement correctly while the deployed system differs. SSDF provides development context and ASVS provides requirements that can be verified. Neither replaces understanding the application’s business rules or checking how its current deployment enforces them.
An export needs more than the first authorization check
Consider a fictional portal that checks a user’s tenant and then queues a customer export. The worker trusts the tenant in the queued request. The completed download also remains available after the user loses membership. The portal’s initial check does not explain whether the later processing and download are still authorized.
Define the worker’s authority and how long access to the result should last. Depending on that revocation contract, the workflow can derive trusted tenant context, check access again during processing and retrieval, limit the lifetime of downloads and remove obsolete exports. The design needs to say which behavior it intends before the test can decide whether it works.
Write down the decision at the queue
This record connects the assumption to a possible failure and a check for that failure. It keeps the queue review tied to the customer-export workflow instead of treating the queue as an isolated component.
| Field | Export example |
|---|---|
| Boundary | Portal to export queue. |
| Assumption | An untrusted caller cannot supply another tenant as the queued tenant. |
| Failure | The worker exports data outside the initiating authority. |
| Control | Derive and validate tenant context within the trusted workflow. |
| Verification | Test cross-tenant and revoked-access cases, then inspect output and logs. |
Test what happens when state changes
Try another tenant, an expired session, membership removed while a job waits and a retried job. Check the downstream result as well as the response. A denied request is still a problem if the worker created the protected file before the denial was returned.
A new integration or administrative feature can change these relationships. Update the model when it changes a boundary, and retain the diagram version with the test evidence. That makes it clear which implementation the review actually covered.
Keep the unanswered questions in the model
A threat model does not establish that every vulnerability has been found. It should retain excluded components, unknown implementation details and assumptions that still need checking. Those items identify where code review, testing or operational evidence is needed next; approving the diagram does not resolve them.