What is the agile SDLC and where does security fit?

The agile SDLC is a way of building software in short iterations, usually one to four weeks, with working software at the end of each. Security fits by becoming small, repeatable tasks inside every iteration, not a single review before release.

What is different about agile?

The Agile Manifesto principles speak of delivering working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale. They also say that working software is the primary measure of progress and that teams should reflect regularly on how to become more effective.

Compare that with a sequential model where requirements, design, build, test and release happen in order. A security review placed after "build" in that model has a natural slot. In agile there is no "after build" because every sprint builds, tests and often releases.

That is why a late gate fails in agile teams. It either blocks a release that was ready, or gets skipped.

Where does security belong in each stage?

NIST's Secure Software Development Framework (SP 800-218) is deliberately method neutral. It says its practices can fit any software development life cycle model. Its groups are: prepare the organization, protect the software, produce well-secured software, and respond to vulnerabilities. Here is how they map to agile ceremonies.

• Backlog and refinement. Add security requirements as acceptance criteria. For a login story, "lock the account after repeated failures" is a testable line.
• Sprint planning. Flag stories that touch authentication, payments, personal data or new third parties for a short design chat.
• During the sprint. Automated checks run on every pull request: dependency checks, secret scanning, static analysis.
• Review. Reviewers use a short security checklist alongside the functional one.
• Sprint review and demo. Show security work as work, such as a fixed vulnerability or a new check, so it stays visible.
• Retrospective. Look at any security issue found late and ask which earlier step could have caught it.
• Release. Keep a record of what shipped, including dependency list and test results.

A constructed example

A team has two-week sprints. Story: "Users can export their data as a file." In refinement, the product owner adds three criteria: the export is only available to the account owner, the link expires, and the file name does not include user input. In the sprint, a pull request check flags an outdated compression library. The developer upgrades it before merge. In review, a teammate asks whether the export is rate limited, and a ticket is added for the next sprint. None of this needed a security meeting.

What goes wrong?

• Security as a separate sprint. A "hardening sprint" at the end is a waterfall gate in disguise.
• Too many findings. If automated checks flood the board, teams stop looking.
• No owner. If everyone is responsible, a security backlog item can sit unassigned.
• Skipping design. Short iterations do not remove the need to think about threats for risky features. They make the thinking smaller, not absent.

How to check or apply this

1. Write a one page definition of done that includes security items: tests pass, no new critical findings, secrets removed, dependencies reviewed.
2. Add a "touches sensitive area" tag to the story template, with a short list of triggers.
3. Put automated checks into the pipeline in report mode first, then enforce on new findings.
4. Reserve a fixed share of each sprint, such as ten to fifteen percent, for security and reliability work, and review the share each quarter.
5. Name one security champion per team who attends refinement for tagged stories.
6. Track time to fix vulnerabilities and report it at the retrospective.

OWASP SAMM offers a maturity model if you want to measure these practices over time.

Quick check

Sources

• Principles behind the Agile Manifesto
• NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1
• OWASP SAMM

Last reviewed: 18 October 2026.