Security requirements are product requirements
If it is not in the requirements it will not be built, and security stated as a principle is not a requirement.
"Must be secure" produces nothing. "Must rate-limit authentication to five attempts per account per minute" produces something testable that appears in a backlog. Treating security as a separate conversation after the requirements are agreed is how it becomes a negotiation about delay rather than part of the work.
More on Secure development
- Threat modelling asks how a design can fail before code existsBreak it on paper first
- Input validation defines what the application acceptsOne shape fits
- Code review and automated scanning see different risksThe magnet and the eye
- Security tests should exercise abuse casesThe load nobody specified
- Feature flags can become security statesSomebody left it up
- Error handling should fail predictablyBreak the same way every time