Most breaches are not clever. They trace back to a decision nobody wrote down — a default left in place, a boundary nobody named, an assumption about who could reach what. By the time a system reaches a penetration test, the interesting decisions are already made: the trust boundaries, the blast radius, who can reach what.
Where security is actually decided
Trust boundaries were drawn when someone chose the service split. Blast radius was set when someone chose one database for everything. A test can find the consequences; it cannot undo the choice.
This is why we treat the specification as a security artefact rather than a product one. It is the last cheap place to change your mind.
A control that exists only in someone's head is not a control. It is a habit, and habits leave when people do.
Three lines that change a build
In practice, three sentences in a specification do more for a system's security posture than a quarter of remediation work: who the actors are, what each may reach, and what must be true before data crosses a boundary.
Writing a control into the spec
A control written as prose gets interpreted. A control written as an assertion gets tested. We prefer the second form, close enough to code that the build has nowhere to drift:
REQ-SEC-014 Tenant isolation
GIVEN an authenticated user of tenant A
WHEN any read or write names a resource of tenant B
THEN the request is refused at the data layer
AND the refusal is logged with actor, resource, decision
TEST automated, runs on every deploy
It is unglamorous, and it survives staff turnover, refactors and the audit two years from now.
What this buys at audit
When an auditor asks how tenant isolation is enforced, the answer is a requirement number, a test, and a log sample. Nobody has to reconstruct intent from a codebase. That is the whole trick: the specification becomes the evidence.
Originally published at dunime.com.