Spec it safe: shift left and harden your specs with security requirements

Spec-driven development (SDD) is changing how large teams build software. Instead of relying on a prompt alone, you author a specification that guides an AI coding agent through design, tasks, and implementation; a flow we abbreviate here as Specify → Plan → Execute. But most specs describe what the software should do, the features a user can see and exercise, and don’t mention how it should withstand misuse. Functional requirements are naturally self-demonstrating: if login is broken, someone notices. Security requirements are often not; an app can pass every functional check while leaving an injection or authorization flaw wide open, because nothing exercises the failure case. So when a security constraint is missing from the spec, the agent has no security-focused target to build and iterate against. It falls back on whatever the framework defaults happen to do, which may be sufficient or may leave a hole, and nothing in the spec forces the question either way. Closing that gap isn’t about adding a better model or tacking on a security review at the end. It’s about moving the work earlier, to a layer you fully control: the specification. When you write a security obligation into the spec, the coding…