Every project plan says security matters. Fewer plans say when and how. Security added in the final sprint is a patch; security built into the process is a property of the system.
In practice, security-first development means threat modeling during discovery, dependency scanning in CI on every commit, secrets managed outside the codebase, and access controls designed before the first endpoint is written. It also means boring disciplines: patch cadences, audit logs, and least-privilege defaults.
For public sector and regulated clients, this is not optional. Frameworks like OWASP ASVS and FedRAMP requirements are easier to meet when the evidence is generated as a byproduct of daily work rather than assembled retroactively.
If you are evaluating a development partner, ask one question: show me your security checklist for an average sprint. The answer tells you everything.
