Embed security requirements in developer workflows and backlog
Implementation Effort: Medium – Embedding security acceptance criteria and review gates into planning and issue and pull request templates requires coordination across engineering and security teams. User Impact: Low – Adding security requirements to the backlog and templates changes the developer planning process; end users are not affected. Lifecycle Stage: Govern
Overview
Embed security requirements into developer workflows and backlog planning so that security is addressed as a first-class input to design — not discovered after code is written.
Most DevSecOps programs focus on detection: scanning code for vulnerabilities, checking dependencies for known CVEs, and analyzing IaC templates for misconfigurations. These controls are essential, but they all operate after design decisions have already been made.
Without security requirements defined upfront in the backlog, teams build features without considering abuse cases, trust boundaries, or data sensitivity, then discover security gaps late in the cycle when remediation is expensive and disruptive. This is the gap that Microsoft SDL Practice 1 (Establish security standards, metrics, and governance) is designed to close: ensuring that security and privacy considerations are part of the functional specification, not an afterthought.
Organizations should integrate security requirements into their existing planning process rather than creating a separate security workflow. During sprint planning or backlog grooming, require teams to identify security-relevant user stories and attach security acceptance criteria.
For example, a feature that introduces a new API endpoint should include acceptance criteria for authentication, authorization, input validation, rate limiting, and audit logging. Features that handle sensitive data should include data classification and encryption requirements. Features that modify deployment pipelines or infrastructure should include a threat model review checkpoint.
In GitHub, use issue templates and pull request templates that prompt developers to declare whether a change has security implications and link to the relevant security requirements. In Azure DevOps, use work item templates with mandatory security fields. Define a lightweight security review gate — such as a label-based triage in GitHub or a custom board column in Azure Boards — so that security-relevant stories are visible to the security champion or application security team before implementation begins.
Complement backlog-level requirements with abuse case modeling: for each user story, ask "how could a threat actor misuse this feature?" and document the resulting security controls as acceptance criteria. This practice shifts security left past code and into design, ensuring that the controls scanned for later in the pipeline have a requirements baseline to validate against.
Requiring abuse-case analysis and trust-boundary review during planning embeds the Assume breach principle into design, so features are built to withstand misuse rather than patched for it later.