Security engineering

The unglamorous things cause the incidents. Credentials committed to a repository or pasted into a chat, an object that can be fetched by changing an identifier in a URL, an internal service reachable from the internet because a security group was opened during debugging and never closed, a dependency with a known vulnerability that has been flagged for eight months. Sophisticated attacks exist, but a business that has closed this list is not the one most attackers are going to spend time on.

Authorisation is where application security is usually weakest, and the pattern is consistent: the check lives in the interface rather than at the data boundary. A hidden button is not a permission, and neither is a route guard, because an API can be called directly. The question worth asking of any endpoint is not whether the UI prevents this, but what happens if someone calls it with another organisation's identifier — and that question should be answered by a test rather than by a conversation.

Compliance work like SOC 2 is mostly evidence rather than engineering, and treating it as an engineering project is why it takes twice as long as expected. What auditors want is proof that controls existed continuously — access reviews that happened on a schedule, changes that went through review, logs that were retained, an incident process that was followed. Most of that is instrumentation and record-keeping you can put in place in advance, and almost none of it can be produced retroactively.