Security in Scrum: Shifting Left on Application Security
The traditional approach to application security follows a familiar pattern. The development team builds the product through its iterations. Weeks or months before the planned release date, a security team or external firm conducts a penetration test. The pen test returns a list of findings — some critical, some high, a long tail of medium and low severity issues. The team scrambles to remediate the critical findings before go-live, plans to address the high-severity issues in the next release, and logs the rest as technical debt. This pattern has well-understood problems. Security vulnerabilities discovered late are dramatically more expensive to fix than those caught during design or development. Remediation work appears in the backlog unplanned, disrupting Sprint commitments. And the gate-at-the-end model means security is the development team's last consideration, not an ongoing one.
What shifting left actually means
Shifting left is not simply about moving the penetration test earlier. It is about embedding security practices throughout the development lifecycle — from the moment a feature is conceived to the moment it is deployed. In a Scrum context, this means security considerations enter at three levels: the product backlog (security requirements, threat models), the Sprint (secure coding practices, automated testing), and the Definition of Done (security criteria that must be met before any story is closed). The goal is to make security a continuous activity that every team member contributes to, rather than a specialised review that happens once before release.
Security practices for Scrum teams
Threat modelling at Sprint Zero or feature inception. Threat modelling is the practice of systematically identifying how an application could be attacked, which assets are at risk, and what mitigations should be in place. For Scrum teams, threat modelling sessions work best at the start of a new feature or at Sprint Zero when the team is establishing the architecture. The output is not a lengthy report — it is a set of security-focused user stories and acceptance criteria that belong in the Product Backlog and will be addressed in upcoming Sprints. Lightweight approaches such as STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) can be applied in a half-day workshop without requiring deep security expertise.
Secure coding standards in the Definition of Done. The Definition of Done is the Scrum team's quality gate. Adding a security component to the DoD means every story must meet a defined secure coding standard before it can be considered complete. In practice this means: input validation has been implemented according to the team's standards; authentication and authorisation controls have been applied correctly; sensitive data is handled according to the data classification policy; and the code has been reviewed with security intent, not just functionality.
Static Application Security Testing (SAST) in the CI pipeline. SAST tools analyse source code or compiled binaries to identify common vulnerability patterns — SQL injection, cross-site scripting, insecure deserialization, and others — without executing the application. Integrated into the CI pipeline, SAST runs automatically on every commit and provides developers with immediate feedback about security issues they can fix in the same context they created them. The key implementation decision is how to treat findings: failing the build on confirmed critical findings while routing lower-severity findings to a review queue prevents both false positives blocking legitimate work and genuine issues being ignored.
Software Composition Analysis (SCA) for dependency scanning. Modern applications depend on large libraries of open-source software. SCA tools scan these dependencies against databases of known vulnerabilities — such as the CVE (Common Vulnerabilities and Exposures) database — and alert when a dependency with a known vulnerability is in use. Because vulnerabilities in third-party libraries account for a significant proportion of application security incidents, SCA is as important as SAST in a mature shift-left programme. Like SAST, SCA should run automatically on every build and the findings should be triaged, not silently accumulated.
Security acceptance criteria in user stories. User stories that touch authentication, authorisation, data handling, or external integrations should have explicit security acceptance criteria written alongside functional acceptance criteria. A login story should include acceptance criteria specifying account lockout behaviour after failed attempts, session timeout, and secure transmission. A file upload story should specify allowed file types, maximum file size, and malware scanning. Writing these criteria at story creation rather than at code review is what shifts the security thinking leftward in practice.
The Security Champion on a Scrum team
A Security Champion is a team member — usually a developer — who has taken on additional security knowledge and responsibility as part of their role on the Scrum team. Security Champions are not replacements for a security engineering function: they are connective tissue between the team and the security organisation. In practice, a Security Champion leads threat modelling sessions, reviews security findings from SAST and SCA tools, proposes security-focused improvements to the Definition of Done, and acts as the first point of escalation when the team encounters a security decision that requires specialist input. Organisations that run Security Champion programmes consistently report faster vulnerability remediation times and higher security awareness among development teams than those that rely solely on centralised security review.
If your development teams are finding that security is consistently a source of late-stage rework and release delays, XNM's program and project delivery advisory can help you build a shift-left security programme that integrates with your Scrum practices rather than adding overhead on top of them.