Implementing a Secure Development Lifecycle
Integrate security into every SDLC phase rather than bolting it on at the end, choose testing types appropriately across the pipeline, manage third-party dependencies, and stay accountable for outsourced code.
Learning Objectives
- → Map security activities to each phase of the SDLC
- → Explain the difference in purpose between SAST, DAST, and penetration testing
- → Justify why dependency scanning is now a baseline expectation, not optional
- → Describe what accountability an organization retains for outsourced code
Foundation's Technological controls lesson introduced the secure development cluster (8.25-8.30) as a survey. Implementation means actually weaving security activities through each phase of the development lifecycle, and choosing the right testing tool for each stage rather than relying on a single method to catch everything.
Security activities by SDLC phase
Requirements → Define security requirements alongside functional ones
(e.g. "must support MFA," not just "must let users log in")
Design → Threat modeling — what could go wrong with THIS design,
specifically, not a generic checklist
Coding → Secure coding standards, peer code review including
a security lens, not just functionality review
Testing → SAST, DAST, dependency scanning (see below)
Deployment → Environment separation (Foundation, 8.31), change
management gates (this roadmap, lesson 6)
Maintenance → Ongoing vulnerability management (Foundation, 8.8),
patching on a defined cadence
The most common implementation mistake is treating security testing as something that happens only at the very end, right before release — by then, a design-level flaw (e.g., missing authorization checks baked into the architecture) is far more expensive to fix than if threat modeling had caught it during design.
Choosing the right testing type for each stage
| Method | What it catches | When to run it |
|---|---|---|
| SAST (Static Application Security Testing) | Code-level issues — injection risks, hardcoded secrets, insecure patterns — without running the application | Every commit or pull request, early and often |
| DAST (Dynamic Application Security Testing) | Runtime behavior issues — how the running application actually responds to malicious input | Pre-release, against a deployed test/staging build |
| Penetration testing | Deeper, human-driven testing including business logic flaws and chained vulnerabilities automated tools miss | Periodically (e.g. annually, or before a major release), not for every small change |
None of these three replaces the others — SAST is fast and cheap but can't see runtime behavior; DAST needs a running application and won't catch code-level issues SAST would flag instantly; a skilled human tester can find business-logic flaws (e.g., a discount code that shouldn't stack with another) that no automated tool is designed to look for at all. A mature implementation runs all three, at the cadence appropriate to each.
Dependency scanning is now a baseline, not optional
Modern applications routinely depend on dozens or hundreds of third-party libraries — a vulnerability discovered in a widely used dependency can affect enormous numbers of applications simultaneously the moment it's disclosed. Implementing this control means automated dependency scanning integrated into the build pipeline (flagging known-vulnerable versions before they ship) and a defined process for actually acting on findings — a scanner that runs but whose output nobody reviews provides no more real protection than not scanning at all, echoing this roadmap's earlier lesson on monitoring without action.
Outsourced development: accountability doesn't transfer
If a contractor or outsourced team writes code that ends up in production, the organization remains accountable for that code meeting its own secure development requirements — the same principle from Foundation's supplier controls (5.19-5.23) applied specifically to code. In practice, this means contracts should specify secure coding requirements and testing obligations explicitly, and the organization should still run its own SAST/DAST/dependency scanning against outsourced code before it ships — not simply trust that the vendor did so, without verification.
A company's SDLC includes: writing functional requirements, coding, running SAST on every commit, running DAST before release, and periodic penetration testing. No threat modeling or security-specific design review ever happens. Six months in, a feature ships with an authorization flaw baked into its core architecture — any tool would need a fundamental redesign to fix it, not a small patch. Identify which SDLC phase's omission caused this outcome.
Which SDLC phase's omission is most directly responsible for this expensive, architecture-level flaw?
For each scenario, identify whether SAST, DAST, or penetration testing is the most appropriate method: (a) checking for hardcoded API keys in source code on every pull request, (b) testing whether a deployed staging application properly rejects malformed authentication tokens at runtime, (c) determining whether a promotional discount code can be chained with another discount in a way that violates business rules.
Which method is most appropriate for determining whether a discount code can be improperly chained with another, violating business logic?
A company's CI pipeline runs a dependency vulnerability scanner on every build. It has flagged 47 known-vulnerable dependencies over the past year. None have been upgraded, and no one reviews the scan output. Explain why this scanning setup, despite technically running, provides close to zero real security value.
Why does this scanning setup provide close to zero real security value, despite technically running successfully every time?