Table of contents
- Key Takeaways
- What is SDLC in Software Engineering?
- Phases of the SDLC Life Cycle
- Popular SDLC Models: Waterfall, Agile, and More
- Embedding Security into the SDLC
- Benefits and Importance of Following SDLC
- Common Challenges and Mistakes in SDLC Implementation
- How Orca Connects the SDLC to Runtime Risk
- Frequently Asked Questions About the SDLC
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
No. The acronym is shared, and NIST flags the collision in a footnote to SP 800-218: “SDLC is also widely used for system development life cycle.” The systems version covers hardware, networks, facilities, and people, and it is the sense most federal IT documents use. Check which one a standard means before mapping your process to it.
Two things need separate owners: the written process, and each team’s instance of it. Engineering leadership is the usual home for the first. Problems start when nobody owns the definition, which shows up as three teams using the same phase names for different activities. A single owner for the written life cycle, with teams free to adapt it inside stated limits, is the arrangement that survives growth.
Yes. The usual move is a waterfall front end for requirements and architecture, then iterative delivery once the shape of the system is settled. The risk is that governance stays with the old model, so a team ships weekly while a change board still meets monthly.
Measure the outcomes the phases are supposed to produce, not adherence to the phases. Three signals do most of the work: releases shipped on the planned date, defect age by introducing phase, and incidents traced to an unwritten requirement. Adherence metrics reward paperwork.
Less than most teams produce, and more than most teams keep. The durable set is what somebody outside the team needs later: agreed requirements, an architecture record with its trust boundaries, test results, and a release record naming what shipped. Everything else is working material and can live in tickets and pull requests.
Table of contents
- Key Takeaways
- What is SDLC in Software Engineering?
- Phases of the SDLC Life Cycle
- Popular SDLC Models: Waterfall, Agile, and More
- Embedding Security into the SDLC
- Benefits and Importance of Following SDLC
- Common Challenges and Mistakes in SDLC Implementation
- How Orca Connects the SDLC to Runtime Risk
- Frequently Asked Questions About the SDLC