Definition
Agile SDLC methodology is based on collaborative decision making between requirements and solutions teams, and a cyclical, iterative progression of producing working software. Work is done in regularly iterated cycles, known as sprints, that usually last two to four weeks. In Agile, you often don’t design for needs that could come up in the future, even if they seem obvious. This is a point where development teams and security teams tend to struggle. Security teams aim to anticipate attacks, attackers, and risks. As needs emerge and are refined over time, security requirements can emerge that weren’t anticipated at the beginning of the process. This is normal and natural in Agile, but it can be disorienting to security people who aren’t able to secure against various likely attacks. A key takeaway from a security perspective is that Agile is all about the sprint. If a security requirement isn’t in the backlog, it won’t be scheduled for delivery in a sprint. If it isn’t scheduled in a sprint, it won’t get done. When security needs are articulated in the backlog, they’re prioritized alongside everything else.
How does Agile drive secure development?
Fifteen years after the Agile Manifesto was released, similar inefficiencies still plague application security efforts in software development. Security is often seen as something separate from—and external to—software development. It’s time to change the approach to building secure software using the Agile methodology.
When building secure software in an Agile environment, it’s essential to focus on four principles. These principles are patterned after those in the original Agile Manifesto: while we value the things on the right, we must value the things on the left more.
The goal is to guide the development of new activities and make adjustments to existing activities to make it natural and efficient to build security into an agile process. These four principles are meant to inspire us to build secure software in an agile way:
- Rely on developers and testers more than security specialists.
- Secure while we work more than after we’re done.
- Implement features securely more than adding on security features.
- Mitigate risks more than fix bugs.
Building secure software in an agile way is fundamentally the same as building software in an agile way.
The Agile Security Manifesto
The Agile SDLC train
Agile SDLC works a lot like a train. Each rotation of the train wheels represents a sprint. During each sprint rotation, new needs are coming in from the backlog, rolling through the planning, implementation, testing, evaluation, and deployment phases of the Agile software development life cycle (SDLC).
Each Agile phase within each sprint rotation meets the software security tracks through a series of security activities tailored to each phase. There’s no need to stop the train to think about security. If a vulnerability is identified, treat it like any other bug and resolve it along the way.
Manage Risk at Enterprise Scale
How to Build a Rock-Solid Software Security Initiative in 5 Steps
Get started with our sample roadmap
Consolidate and Simplify AppSec to Manage your Software Risk
Learn how to optimize your AppSec strategy
How to Evaluate the ROI of your Software Security Program
Learn where to look for ROI in an AppSec program
