CCSP Secure SDLC: Business Requirements, Phases, Waterfall vs. Agile and DevSecOps

A secure Software Development Life Cycle (SDLC) is a development process in which security activities are built into every phase, from the first requirements to the retirement of the system, instead of being added as a check just before release. The phases are usually described as requirements (including business requirements), design, development (code), testing, deployment, operations and maintenance, and disposal. Each one has its own security work, and each one produces evidence the next phase relies on.

The main reason is the cost of defects. A flaw that is prevented in the requirements costs a conversation; the same flaw found in design costs a redrawn diagram; found in testing it costs rework of code and retesting; found after release it costs an incident, an emergency fix and possibly a breach. Moving security activities earlier is often called shifting left.

A useful diagnostic follows from this. When the same class of flaw keeps appearing late (for example, in every pre-release penetration test), adding more late testing finds it again at the most expensive point. The lasting fix is in the phase that should have prevented the flaw: usually a missing requirement or an unreviewed design. A tool in the build can catch some coding mistakes earlier, but it cannot check a business rule that no specification states.

Security requirements are derived from business requirements: what the business needs the system to do, the data it will hold, and the legal, regulatory and contractual obligations that come with that data. Typical sources are data sensitivity and classification, data residency and sovereignty rules, availability and recovery targets, privacy law, industry standards (for example PCI DSS for payment card data) and customer contracts.

Gathering them means asking the right stakeholders. The data owner in the business is accountable for the data and classifies it, which sets the protection the system must provide. The data custodian (often IT or operations) implements and runs the controls the classification calls for but does not decide it. Developers implement protections, and the cloud provider offers controls, but neither decides how sensitive the business's data is. Legal, compliance and privacy teams contribute the obligations; business sponsors are a legitimate source of requirements, and the security professional's job is to help refine what they say into something usable, not to replace them.

Order matters. Requirements are documented before design starts: choosing provider regions, an architecture or an SLA before residency and availability needs are written down is designing (or contracting) ahead of the requirements. A short way to remember the sequence is define before you design, and assess before you contract. The contract and SLA should then be checked against the documented requirements, not the other way round.

A missing requirement is a root cause that nothing downstream catches. If a compliance obligation, such as never writing full card numbers to logs, never becomes a requirement, the design review has nothing to check it against, no test case is written for it, and code review finds it only by luck.

A good security requirement states a measurable, verifiable outcome and stays implementation-neutral. Measurable means a tester can show it is met or not met; implementation-neutral means it says what must be true, not which mechanism, product or party delivers it, which is left to design. If a statement cannot be tested, it is a goal, not a requirement, and it must be refined before design starts.

A requirements traceability matrix (RTM) links each requirement to the design element that addresses it, the code that implements it and the test case that verifies it. Because it is organised per requirement, it is the evidence of coverage: for any requirement, you can follow the chain to where it was designed, built and verified, and any requirement with a broken chain stands out. Reports that describe a set of controls in aggregate, or record a single assessment or approval, are useful assurance, but they are not organised by requirement and so cannot show coverage.

The RTM also absorbs change. A requirement that arrives mid-project, such as a major customer's contractual demand for multi-factor authentication on a partner portal, enters the RTM like any other: it is linked to the design items it affects and to the tests that will verify it. That keeps it inside the normal design, build and verification chain instead of being bolted on at the end, where it is either unverified or discovered late.

Design is secured by reviewing the architecture against the requirements, code by a secure coding standard and review of each change, testing by test cases built from the security requirements, and deployment by hardened, verified and controlled releases. The right control is the one that belongs to the phase in question.

Design. When a design review finds that the planned architecture does not meet a requirement (say, a design that sends personal data to an analytics service outside the region the residency requirement allows), the recommendation is to correct the design before the affected components are built. Redesign on paper is the cheapest fix the project will ever get; anything that works around the flaw or schedules it for later leaves the requirement unmet in the meantime and moves the real fix to the expensive end of the lifecycle.

Code. Assurance that a coding standard is followed comes from examining the code itself, change by change, before it is merged, ideally by reviewers who are independent of the author. The same holds when the code is outsourced: direct evidence about the code beats indirect evidence about the supplier. A process certification or general attestation says how a supplier usually works, and testing a finished component shows exploitable symptoms, but only examining the changes themselves during coding shows whether they conform to the standard.

Test. Test cases are derived mainly from the system's documented security requirements; that is what makes testing verification. Other sources (lessons from earlier systems, the code itself) can add cases but cannot define what "correct" means. The corollary: testing cannot find what the requirements never stated. If a system passes all its security tests and still allows something the business never wanted, such as a discount code that can be redeemed without limit, the root cause is an incomplete requirement, and the fix starts there.

Deployment. Release the build that was reviewed and tested, not a rebuilt or hand-modified copy: promote it through environments with controlled, logged steps, verify its integrity (for example, by checking signatures or hashes), and deploy it with hardened, secure-by-default settings and secrets supplied from a managed store rather than embedded in the package.

The detail of threat modeling methods and secure coding standards belongs to applying the SDLC (task 4.3), and the testing techniques themselves (SAST, DAST, IAST, SCA and others) to software assurance and validation (task 4.4).

In operations and maintenance, every change re-enters the lifecycle, scaled to its size. A new capability, such as opening a partner API on an existing internal system, gets its own security requirements, design review and testing before release. Change management decides whether and when a change is released; it is not a substitute for analysing the security of what the change does. Earlier test results describe the system as it was, so they say nothing about new functionality.

Reassessment can also be triggered without any code change. If the business decides to process a more sensitive kind of data in an existing application (for example, starting to collect biometric identifiers in a system built for contact details), the business requirements have changed. The next step is to reassess the security requirements against the new classification, then let any gaps flow into design, implementation and testing. Individual controls and contracts for the new data may well be needed, but the reassessment comes first because it decides which ones. Changes in regulation, contracts or how the system is used are triggers too.

Disposal (retirement) is a planned SDLC phase with its own checklist:

1. Settle what must be kept first. Confirm retention requirements and any legal hold with legal and the data owner before sanitizing anything. Sanitization is designed to be irreversible, so any record that must be kept has to be identified and preserved before it starts.
2. Sanitize the data by an approved method, such as crypto-shredding (cryptographic erase: destroying the keys that encrypt the data, recognised in NIST SP 800-88), and keep evidence of it.
3. Remove everything linked to the application, not just its compute: DNS records, credentials, keys, certificates, storage, network rules and integrations. A DNS record left pointing at a released provider resource lets an attacker take over the subdomain (a dangling DNS record).

Waterfall runs sequential phases in a single pass, each reviewed and signed off before the next begins. Security fits naturally at those gates: a security sign-off of the requirements, of the design, and so on. Agile methods (such as Scrum) deliver in short iterations, reprioritizing a backlog after each sprint as feedback arrives, so security has to be built into every iteration rather than into a single phase.

Security in waterfall. A requirement that appears late (for instance, a customer contract signed during coding that adds an audit-logging obligation) is handled through the methodology's own change mechanism: a formal change that reopens requirements and design for the affected parts, so the new work passes through the same security gates as everything else. The principle is that a change re-enters the lifecycle at the earliest phase it affects, so every gate it would have passed still applies; the methodology's own change process is how that happens, and a mandatory obligation stays a requirement rather than a risk the project can choose to carry.

Security in agile. The definition of done is the team's shared checklist that every item must meet to count as complete, so security criteria placed there (security requirements met, change reviewed, security checks passed) apply to every story automatically. Acceptance criteria are written per story, so they suit story-specific security conditions but cannot guarantee a common bar. Leaving all security to a hardening sprint before release is an anti-pattern: it concentrates a quarter's flaws at the latest point. Security tasks and findings belong in each sprint's backlog.

Choosing. Select the methodology from the project's constraints. A regulator-specified interface with fixed requirements and a hard date suits waterfall; an app whose features will be shaped by user feedback suits agile. Regulation does not force waterfall: when features change but a regulator wants evidence of security approval before each production release, agile with a documented security approval built into every release meets both needs. The evidence is the organization's own review; the regulator does not approve releases for it.

The spiral model is risk-driven, the iterative model refines a whole product version by version, and the V-model pairs every development phase with a test level. Each is defined by that one feature.

Iterative vs. agile. An iterative lifecycle repeats planned build cycles, each producing a more complete version, usually against a largely planned scope. Agile methods also iterate, but they add short fixed timeboxes, continuous reprioritization of a backlog from feedback, and a self-organizing team delivering working increments; agile is iterative, but not every iterative lifecycle is agile.

The V-model's usual four-level form pairs requirements with acceptance testing, system design with system testing, architecture design with integration testing, and module (detailed) design with unit testing, with coding at the base of the V. Its key practice is to plan each test level during the phase it mirrors: writing the acceptance tests while the requirements are being defined shows at once when a requirement cannot be tested, which is far cheaper than discovering it in final acceptance.

Do not confuse the spiral's risk-driven cycles with Scrum's: Scrum also iterates, but its backlog is ordered by the product owner for value, not by a formal risk analysis that drives each cycle.

DevSecOps is the practice of integrating security into DevOps continuous delivery: security becomes automated checks in the delivery pipeline that run on every change, and a shared responsibility of development, security and operations. It is the answer when deployment frequency makes manual pre-release sign-off impossible: the checks move at the pipeline's speed instead of slowing the pipeline to the speed of a manual review. Under shared responsibility the customer still owns the security of its own application code, whatever controls the platform provides underneath.

Who fixes findings. The team that owns the code fixes its findings, with guidance from the security team. The security team supplies tools, standards, training and expertise; if it became the team that fixes everything, it would recreate the bottleneck DevSecOps exists to remove, and the code owners would never learn from their findings.

Tiering checks. Not every check fits on the critical path. A common pattern is to gate each change on fast checks (those that finish in minutes, such as static analysis and dependency checks) and run slower, deeper analysis asynchronously on a frequent schedule, feeding its findings into the owning team's backlog. The aim is that no check is dropped and none blocks delivery: coverage comes from running everything regularly, speed from gating only on what is fast.

NIST SP 800-218, the Secure Software Development Framework (SSDF), is a set of high-level secure development practices that can be added to any SDLC methodology. It groups them into four practice groups:

The two groups most often confused are Prepare and Respond. Process improvement that is driven by analysing a vulnerability found in released software (fix it, find the class of mistake, change the process so it does not recur) is Respond to Vulnerabilities; setting up roles, training and toolchains in advance is Prepare the Organization. Likewise, protecting the code and releases themselves is Protect the Software, while building secure code is Produce Well-Secured Software.

Responsibility for an application's SDLC follows who writes the code. On IaaS and PaaS, the customer builds and deploys the application, so the customer runs its secure SDLC; the provider runs the lifecycle of the infrastructure or platform underneath. With SaaS, the vendor builds the software, so the customer cannot run that SDLC; its job is to assess the vendor's SDLC as part of supplier due diligence.

Hosting code does not make a provider its developer: a SaaS vendor that runs a customer's custom extensions does not gather the customer's requirements or review its code. A vendor's SOC 2 report is one input to assessing it, not a substitute for assessment: the customer still reviews the report's scope and exceptions and operates its own complementary controls.