Modern agile teams ship in small chunks, several times a week, sometimes several times a day. Security tooling bolted on at the end cannot keep up, and that is the core argument laid out in a Netsparker piece on building a secure software development lifecycle (SSDLC).
The piece points to a stubborn stat: up to 70% of development organisations skip at least some security steps as deadlines tighten. That number is the reason "add security later" no longer works. The pipeline has to carry it from day one.
Quick take:
- Traditional waterfall pushed all security testing into a single late phase, which became a bottleneck under faster delivery models.
- Agile and DevOps use CI/CD to ship in small, frequent releases.
- A secure SDLC layers security tasks into every phase rather than adding a separate review stage.
- Netsparker cites research showing up to 70% of dev teams skip some security steps under deadline pressure.
- Each SDLC phase (requirements, design, code, test, deploy, maintain) gets matching security activities.
From waterfall to a continuous security pipeline
The history is worth knowing. Pre-internet software had little remote connectivity, so security was rarely the blocker. As apps moved to the web and into cloud-hosted business models, the attack surface exploded. CI/CD let small teams ship large, complex apps, but security review stayed parked at the end of the pipeline.
The Netsparker framing is straightforward: the SDLC is a pipe. Adding security is wrapping that pipe in insulation, not inserting a new joint in the middle. Each phase gets its own security work, ideally automated, so the pipe does not have to stop.
Our analysis
The pitch is right and the friction is real. The friction is that "every phase" sounds like more meetings, more checklists, more sign-offs. In practice the win comes from automation in three places: threat modelling during requirements, static analysis and dependency checks during build, and dynamic scanning plus secrets detection in staging.
Who benefits? Teams that already run CI/CD well. They get to bolt security onto an existing automation backbone instead of building a parallel process. Who loses? Teams still doing manual regression at the end of a sprint. They will feel the cost of catching up.
Compared with the common "AppSec tool" pitch, the SSDLC framing is more honest about ownership. Security is not a separate team's job that runs before launch. It is a property of the build, like tests or lint.
A scenario: adding security to a two-week sprint
Say your team ships a customer portal every two weeks. Take the six SSDLC phases from the reference and map them onto the sprint.
Requirements: include abuse cases alongside user stories. Design: review the data flow for sensitive fields before the build kicks off. Code: enable pre-commit hooks for secrets and run static analysis in CI. Test: schedule dynamic scans against staging nightly, not once at the end. Deploy: sign artefacts and check infrastructure as code against a baseline. Maintain: feed production findings back into the next sprint's backlog so the loop closes.
None of that requires a new hire. It requires one person on the team owning the security backlog, which is a Scrum role the team can absorb.
What to watch next
Watch for two signals. First, whether your CI pipeline reports security findings the same way it reports test failures; if not, the gap will widen. Second, whether your threat model survives contact with the next big feature. If it does not, your "secure SDLC" is a checklist, not a practice.
Key takeaways
- Security has to live inside the build, not at the end of it.
- Map the six SDLC phases to your sprint so coverage is automatic, not heroic.
- Give one person on the team ownership of the security backlog.
Frequently asked questions
What is a secure SDLC?
It is a software development lifecycle in which security activities are built into every phase, from requirements through maintenance, rather than treated as a final review step.
Why does waterfall fail at modern app security?
Waterfront pushes all security work into a late testing phase, which becomes a bottleneck under CI/CD delivery cadences and lets flaws ship.
Do agile teams actually skip security steps?
Netsparker cites research showing up to 70% of development organisations skip at least a few security steps when deadlines approach.
Where should security controls sit in a CI/CD pipeline?
Across every phase: requirements (abuse cases), design (data flow review), code (SAST, secrets scanning), test (DAST), deploy (artefact signing, IaC baselines), maintain (feedback into backlog).