Specification is security

Every system has gaps between what was specified and what was built. A payment rule that seems robust until you ask what happens at midnight. An API endpoint that checks permissions on one path but not another. A rate limit that applies to individual requests but not batched ones.

These gaps are where bugs live. They're also where attackers live. Not in the code that was written, but in the behaviour that was never specified. The discipline of finding what's missing is the same whether you're preventing defects or preventing breaches.

Testclub has been doing this for twenty years. We started in functional testing and specification. We moved into security because the skill is identical: understand how a system is supposed to work, then think clearly about how it doesn't.

Testing is not verification after the fact. It's a way of thinking about systems before, during, and after they're built. The most valuable testing happens at the specification stage, when asking the right question can prevent a class of defects entirely.

We use structured examples to drive out ambiguity. What should happen when a user submits an empty form? What if they submit it twice in the same second? What if the session expires between steps two and three of a payment flow? These aren't edge cases. They're the cases nobody wrote down.

This approach applies equally to functional correctness and to security. An unspecified behaviour is an untested behaviour, and an untested behaviour is an attack surface.

Automated tests are valuable when they encode real specification. A test that checks a button exists is noise. A test that verifies a payment can't be processed twice under concurrent requests is specification made executable.