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.
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:
Building secure software in an agile way is fundamentally the same as building software in an agile way.
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.
Learn about the 10 most common web and software app vulnerabilities
Download the reportLearn how to gain visibility and secure your apps across the enterprise
Download the white paperGet the trends and recommendations to help improve your software security program
Download the reportThree steps to consolidate your effort, insight, and tools
Download the guide