A security review developers don't dread

If the security review happens at the end, it's a gate, and gates get argued with. If it happens at the start, it's a design conversation, and design conversations get welcomed. Same people, same findings, opposite reception.

What changes when it's early

The questions are about what the system should do, not what's wrong with what was built. Where does data enter, where does it leave, who's allowed to do what, what happens when a dependency fails. Developers like those questions. They're the interesting part of the job.

How I'd run it

• Thirty minutes at design time, with a whiteboard, not a form. Trust boundaries, data flows, the one thing that would be worst to get wrong.
• One page of agreed decisions afterwards, owned by the team, not by security.
• Automated checks in the pipeline for the things that can be automated: secrets, known vulnerable dependencies, obvious misconfigurations. Nobody should wait for a human to tell them about a leaked key.
• A human look at the things that can't be automated, which is mostly authorisation logic and anything involving money or identity.

What to stop doing

Hundred-item checklists. Findings with no suggested fix. Reviews that start after the release date is fixed. Treating every finding as blocking. Each of those teaches developers that security is an obstacle, and they'll route around it, which is worse for everyone.

The measure that matters

Not findings per review. Whether the things that would have hurt got caught before they shipped, and whether the team asks for the review or hides from it. The second one tells you everything.

If your reviews are producing friction instead of safer software, I can help you rebuild them around the engineers rather than against them.

Explore: More on software engineering · Work with me