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.