SDLC: Core Phases and Best Practices Explained

Key Takeaways

• SDLC stands for software development life cycle, the set of activities that take software from a plan to a running system somebody maintains.
• The seven phases describe activities, not calendar stages. A team deploying twice a day still performs all seven, compressed and repeated.
• The model you pick decides how often those activities repeat and how expensive a late change is. It does not decide whether the activities happen.
• A practical secure SDLC assigns the right security activities to each phase, with clear ownership and evidence that the work was completed. Bolting a scanner to the end of the pipeline is not the same thing.
• Risk keeps accumulating in maintenance, after the point where most teams treat the SDLC as finished. Orca closes that loop by tracing a running exposure back to the commit that caused it.

SDLC stands for software development life cycle, the set of activities a team runs to plan, build, release, and maintain software. Most descriptions cover seven phases: planning, requirements analysis, design, development, testing, deployment, and maintenance. Every team runs a life cycle, whether or not anybody wrote it down.

The phases themselves are documented everywhere. Almost none of those accounts cover the part that decides whether software ships safely: which security activity belongs in each phase, who owns it, and what evidence it leaves.

None of this depends on running a tidy seven-stage schedule. The phases describe activities, not dates on a calendar, and a team that deploys twice a day still performs all seven of them.

What is SDLC in Software Engineering?

SDLC in software engineering refers to the process a team follows to take software from an idea to a running system that somebody keeps alive. NIST SP 800-218 defines a software development life cycle as “a formal or informal methodology for designing, creating, and maintaining software.” The word informal carries the weight there. A two-person team with a shared branch and a deploy script is running a life cycle, and so is a bank with a change advisory board.

The neutral standard behind all of this is ISO/IEC/IEEE 12207, which defines software life cycle processes instead of a fixed list of phases. The current edition is 12207:2026, published in April 2026, and ISO withdrew the 2017 edition the same day. The standard states outright that it “does not identify or require any specific software life cycle model.” The familiar seven-phase list is a convention that grew up around those processes, not a rule anyone enforces.

Phases of the SDLC Life Cycle

The SDLC phases describe what has to happen to software, not when it happens. Most accounts of the SDLC life cycle settle on the same seven: planning, requirements analysis, design, development, testing, deployment, and maintenance. ISO/IEC/IEEE 12207 notes that its processes apply “concurrently, iteratively, and recursively,” which is why continuous delivery does not remove a phase from the list.

Each phase below ends with the security work that belongs to it. Skipping that work does not take it out of the life cycle. It moves it to maintenance, where it costs more and lands on somebody who did not write the code.

Phase 1: Planning

Planning decides what the release is for and what it is allowed to cost. The team fixes scope, budget, timeline, and the constraints the software has to live inside, including regulatory obligations and the platforms it has to run on. Feasibility sits here too: whether this team can build this thing, with these people, in this time.

Security enters as a requirement, not as a review. The plan should name the data the system will hold and the compliance regime it falls under, because both are expensive to reverse once an architecture exists.

Phase 2: Requirements Analysis

Requirements documents list what the system must do. Far fewer state what it must not do. That omission is cheap to make and expensive to find, because a missing negative requirement is invisible to every test that follows it. Requirements analysis turns the plan into specific, testable statements: what each role can see, which fields are mandatory, and how the system behaves when an input is wrong.

The security activity here is writing abuse cases beside the use cases. If a use case says a customer can download an invoice, the abuse case says they cannot download anyone else’s. Testing finally has something to aim at.

Phase 3: Design

A handful of design decisions set the risk profile for years: trust boundaries, where data rests, how services authenticate to each other, and what sits in which network. A design review that approves an architecture with no answer for where the credentials live has approved a secret in an environment variable, whether or not anyone said so.

Two activities belong here. Threat modeling walks the proposed architecture looking for what an attacker would try. Most of that architecture now ships as infrastructure as code, so scanning infrastructure as code templates catches the mistakes while they are still text.

Phase 4: Development

Development produces the artifact every later phase acts on: source code in a repository, written in an integrated development environment, plus the dependency tree that arrives with it. Most of what ships was written by somebody else. Third-party packages pull in their own transitive dependencies, so software composition analysis finds libraries nobody on the team chose.

Security work in this phase runs where the developer already is, in the editor and the pull request. That means code security checks on every change, source code security practices covering branch protection and review, and secrets detection that catches a credential before it reaches history.

Phase 5: Testing

Does the software do what the requirements said, and does it refuse to do what they said it must not? Testing answers both questions, or it answers only the first. Functional, integration, performance, and acceptance testing verify the positive requirements. The negative ones need tests of their own, written from the abuse cases produced two phases earlier.

This is where application security testing belongs. The techniques answer different questions: static analysis compared to software composition analysis covers the code and its dependencies, and dynamic testing covers the application while it runs.

Phase 6: Deployment

Deployment turns a build into a running system, and the sequence matters more than the moment: build, sign, promote through environments, release. A service that ships with a debug endpoint enabled inherited an environment configuration from a place where debugging was fine. Pipeline permissions and release approvals sit inside this phase, not beside it.

The security activity is hardening the pipeline and recording what shipped. CI/CD security covers the first half. A software bill of materials generated at build time covers the second, and it turns the next supply chain disclosure into a query instead of a fire drill.

Phase 7: Maintenance

Risk keeps accumulating after release, because most of a system’s life happens there and new vulnerabilities keep landing on code that already shipped. A service whose base image has not been rebuilt in a year runs a known set of vulnerabilities disclosed after it shipped. No amount of pre-release testing could have caught them. Maintenance covers patching, dependency updates, configuration drift, incident fixes, and the eventual decision to retire the service.

Security here is continuous triage, not a gate. It needs cloud patch management for the platform layer and a working route from a newly disclosed vulnerability to the running service that carries the affected package.

Popular SDLC Models: Waterfall, Agile, and More

SDLC models decide how often the seven phases repeat, not whether they happen. The choice changes the size of the batch, the length of the feedback loop, and what a late change costs. NIST SP 800-218 lists waterfall, spiral, agile, and agile combined with DevOps practices as the models teams run.

Pick by the shape of the work, not the shape of the org chart. Fixed requirements and a contractual delivery date pull toward a single pass. Uncertain requirements and reachable users pull toward short iterations.

Model	How work is sequenced	Cost of a late change	Feedback loop	Best fit
Waterfall	Each phase runs once, in order	High	At the end	Stable requirements, regulated or fixed-scope projects
Agile	Every phase repeats each iteration	Low	Every sprint	Evolving requirements, users available to ask
Iterative and spiral	Cycles repeat, each adding risk analysis	Moderate	Per cycle	Large systems with high technical or safety risk
DevOps and continuous delivery	Phases collapse into an automated pipeline	Low	Every commit	Cloud services with automated test and deploy

The Waterfall Model

The waterfall SDLC runs each phase once and treats the output of one as the input to the next. Requirements are signed off before design begins, design before code, and code before test. It gets caricatured, but it remains useful where requirements are relatively stable, changes require formal approval, and each stage needs documented evidence, including many regulated, safety-critical, and fixed-scope projects.

Its weakness is the feedback loop. A requirement misunderstood in month one surfaces in acceptance testing in month nine. By then it is embedded in a design, a schema, and a test suite.

The Agile Model

An agile SDLC replaces the single pass with short iterations, each running the whole set of phases against a slice of the product. Planning happens per iteration, testing happens continuously, and progress is measured through working software rather than completion of a sequential document set. ISO/IEC/IEEE 12207:2026 recognizes agile as one of the approaches “most widely used for software development, sustainment, and maintenance.”

The trade-off is that design decisions get made in small pieces. Few teams schedule a threat model for a two-week iteration, so architectural security work has to attach to a recurring event or it does not happen at all.

Iterative and Spiral Models

Iterative development builds the system in successive versions, each more complete than the last. The spiral model adds one step to every cycle: identify the biggest remaining risk, then spend the cycle reducing it, whether that risk is technical, schedule, or security.

That makes spiral the honest option when the expensive unknown is not the feature set. Teams pay for it in overhead, since every cycle carries planning and risk analysis a smaller project would not justify.

DevOps and Continuous Delivery Practices

DevOps collapses the phases into an automated pipeline where a commit can reach production the same day. The phases do not disappear. Design happens in a pull request, testing happens in the pipeline, and deployment becomes a property of the merge instead of an event on a calendar.

This operating model puts the most pressure on security, because the gap between a decision and production is measured in minutes. That pressure is why integrating security into DevOps became its own discipline, and why the checks have to run inside the CI/CD tooling.

Embedding Security into the SDLC

A secure SDLC is not a scanner bolted to the end of your pipeline. In practice, that means assigning the right security activities to each phase, with clear ownership and evidence that the work occurred. The difference surfaces during an audit, and again during an incident, when somebody asks which control was supposed to catch this. Everything below is application security work, organized by phase instead of by product category.

NIST’s Secure Software Development Framework exists for this reason. The current final framework, published as NIST SP 800-218 version 1.1, starts from a blunt observation: “Few SDLC models explicitly address software security in detail.” It groups practices into four: Prepare the Organization (PO), Protect Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV). The framework “does not prescribe how to implement each practice,” which makes it a mapping layer, not a tool list.

Security Activities by Phase

Each row below highlights one representative security activity, the artifact it produces, and the role that typically owns it. The artifact column is the one teams skip, and it is what makes an activity auditable. A threat model that cannot be retrieved or reconstructed provides little audit evidence, and an SBOM generated months after the fact may describe a different build. The design and requirements rows both sit under SSDF practice PW.1, “Design Software to Meet Security Requirements and Mitigate Security Risks.”

The mappings below are practical alignments rather than one-to-one assignments prescribed by NIST.

Phase	Security activity	Artifact produced	Typical owner	Closest SSDF practice group
Planning	Set security and compliance requirements for the release	Security requirements in the release plan	Product owner with security architect	Prepare the Organization (PO)
Requirements analysis	Write abuse cases beside the use cases	Abuse-case list with acceptance criteria	Business analyst with AppSec	Produce Well-Secured Software (PW)
Design	Threat model the architecture and scan IaC templates	Threat model plus a mitigation backlog	Software architect	Produce Well-Secured Software (PW)
Development	Scan code, dependencies, and secrets as they are written	Findings resolved in the pull request	Developer	Produce Well-Secured Software (PW)
Testing	Test the running application and verify the abuse cases	Test results traced to requirements	QA with AppSec	Produce Well-Secured Software (PW)
Deployment	Harden the pipeline and record what shipped	Signed build with an SBOM	Platform or release engineer	Protect Software (PS)
Maintenance	Triage new vulnerabilities against what is running	Remediation tickets and root-cause fixes	Service owner with security operations	Respond to Vulnerabilities (RV)

Who Owns Each Activity

Ownership is where a secure SDLC quietly fails. An activity assigned to “the security team” in every phase becomes a queue. A queue at the front of a pipeline is a bottleneck the delivery team learns to route around. The workable split gives the security team the design of the activity and the delivery team its execution.

That is a narrower claim than shifting security earlier in development, which argues about timing. This one is about accountability. Each row above has one owner, and the security function’s job is to make that owner’s version of the activity cheap enough to run every time. Application security posture management tools help teams track these activities, findings, ownership, and remediation across services and development tools.

Benefits and Importance of Following SDLC

The case for running a defined life cycle is not that process is virtuous. It is that four specific things get cheaper, and each one is measurable.

Release planning becomes more predictable. Defined requirements, decision points, and acceptance criteria make changes visible before they silently disrupt delivery. A team that renegotiates scope during development cannot forecast anything, because the target moves faster than the estimate.

Fixing a defect costs less the earlier it surfaces. The mechanism is rework, not a multiplier from a listicle. A wrong requirement caught in analysis edits one document. The same requirement caught after release edits a design, a schema, code, tests, documentation, and whatever data the wrong behavior already produced.

Audit evidence falls out of the work instead of being assembled. Phase artifacts are what auditors ask for: approved requirements, a design review, test results, a release record. Teams without a defined life cycle reconstruct these from chat history in the week before the audit.

Security gets something to attach to. A phase is a stable place to hang an activity, an owner, and a due date. Without one, security attaches to individuals, and it leaves when they do.

Common Challenges and Mistakes in SDLC Implementation

The SDLC becomes documentation instead of a working agreement. A documented life cycle that nobody follows may still satisfy a superficial evidence review, while producing the same defects in practice. The test is whether a developer can name the phase they are in and what has to be true before the next one starts.

Security sits at a single gate at the end. One review before release finds design problems at the point where design is the most expensive thing to change. The activity is not wrong, but it arrived six phases late, and the team learns to treat it as a formality.

The model is chosen for the org chart. A department picks waterfall because approvals map to reporting lines, or picks agile because leadership asked for agility. Neither reason describes the work, which is what should decide the shape of the loop.

Requirements never say what the system must not do. This one recurs because negative requirements have no obvious owner. Nobody requests them, and their absence produces no failing test, so the gap survives every review.

Maintenance is treated as somebody else’s phase. The team that built the service moves to the next project, and the service inherits a rota instead of an owner. Closing this gap depends less on tooling than on the security practices developers will actually adopt. 

OWASP SAMM version 2 makes the same point structurally. It scores fifteen security practices across Governance, Design, Implementation, Verification, and Operations, each at one of three maturity levels. Operations is the function covering the life a system has after release, and it is the one this failure mode leaves empty.

How Orca Connects the SDLC to Runtime Risk

Every phase in this article produces evidence before software reaches production. Maintenance is different. New vulnerabilities appear in running environments long after release, and the fix often belongs in the repository, IaC template, or commit that introduced the issue. Without that connection, security teams spend time identifying ownership before they can begin remediation.

Orca closes that loop. Its Unified Data Model connects runtime exposure to the IaC template, repository, and commit that produced it, while adding context such as exploitability, accessibility, and business impact. This insight helps teams prioritize the risks that matter most and route remediation back to the right development owner instead of treating every finding as an isolated runtime issue. That is the value a cloud-native application protection platform provides, and the same approach powers how Orca prioritizes code fixes by what is reachable and exploitable.

Get a demo to see how Orca connects runtime risks to their code origins and helps teams prioritize the fixes that matter most.

Frequently Asked Questions About the SDLC