The Secure Development Lifecycle

CAP, ACID vs BASE, latency numbers, back-of-envelope estimation, single points of failure — the vocabulary every system designer thinks in.

Core Philosophy: Security cannot be a final inspection bolted onto finished software — by then, flaws are baked into the design and expensive (or impossible) to remove. Application Security works because it weaves security into every stage of how software is built: the design, the coding, the testing, the deployment. That woven-in approach has a name — the Secure Development Lifecycle — and understanding it is the foundation of the entire AppSec discipline.

Part 1: The Problem

Software is built through a process — broadly: plan, design, code, test, deploy, maintain. This is the Software Development Lifecycle (SDLC), and as a developer you have lived inside it.

The traditional, failed approach to software security treats security as something that happens near the end — a security test just before release, or worse, after. This fails for reasons you now understand deeply from Phase 4:

• Insecure design cannot be patched cheaply (4.3). If a security flaw is in the architecture, finding it at the end means an expensive re-architecture — or shipping it.
• Late-found bugs are costly. A vulnerability caught at design is a diagram change; the same vulnerability caught in production is an incident.
• A final security gate cannot catch everything. One inspection at the end cannot find flaws spread across design decisions, code, configuration, and dependencies.

Application Security exists to fix this. Its foundational idea: build security into every stage of the SDLC, not bolt it on at the end. That security-woven-in version of the development process is the Secure Development Lifecycle (SDLC — Secure), often called the SSDLC or Secure SDLC. This page is that foundation.

Part 2: The Concept — What Application Security Is

Application Security (AppSec) is the discipline of making software secure — finding, fixing, and preventing vulnerabilities in applications, across their entire lifecycle.

It is worth being precise about how AppSec differs from what you did in Phases 2–3 and how it relates to Phase 4:

   PHASE 2–3 (offensive)   — attack finished/running software
                             from the outside, find its bugs
   PHASE 4 (defensive)     — the techniques of secure code,
                             design, hardening, operations
   APPSEC (this track)     — the PROFESSIONAL DISCIPLINE of
                             building security INTO how an
                             organization develops software

AppSec is essentially Phase 4 made into a professional, organizational practice, focused specifically on software development. Where Phase 4 taught you how to write secure code, design securely, and find vulnerabilities, Track B is about doing all of that as a role, as a process, across a development organization.

The AppSec engineer’s job is not “be the person who attacks our apps” — it is “make our organization develop secure software by default.” That is a job of process, of tooling, of working with developers, and of design — and it is the natural home for a security-minded developer.

Part 3: The Concept — The Secure Development Lifecycle

The core framework of AppSec is the Secure Development Lifecycle — the ordinary SDLC with security activities woven into every stage.

A typical SDLC, and the security activity that belongs at each stage:

   SDLC STAGE          SECURITY WOVEN IN
   ─────────────────────────────────────────────────────
   1. Requirements   → security requirements; consider
                       what must be protected (1.1)
   2. Design         → threat modeling (1.2, 5B.4);
                       secure design review (4.3)
   3. Implementation → secure coding (4.1, 4.2);
      (coding)         security code review (5B.2)
   4. Testing        → security testing — SAST, DAST,
                       dependency scanning (5B.3)
   5. Deployment     → secure configuration, hardening (4.4);
                       security gates in the pipeline (5B.3)
   6. Maintenance    → vulnerability management (4.8),
                       monitoring, response (4.6, 4.7)
   ─────────────────────────────────────────────────────
   Security is present at EVERY stage — not a final gate.

Notice that every security activity in this diagram is something the curriculum already taught you. The Secure Development Lifecycle is not new material — it is the organizing framework that puts everything you learned in Phases 1 and 4 into its correct place in the development process. The rest of Track B’s pages are the deep dives: code review (5B.2), security testing automation (5B.3), threat modeling as practice (5B.4), and working with developers (5B.5).

The key principle the SDLC framework expresses is “shift left” (Part 4) — move security activity earlier in the lifecycle, because earlier is cheaper and more effective.

Part 4: The Concept — “Shift Left”

“Shift left” is one of the most important phrases in modern application security, and it captures the entire reason the Secure Development Lifecycle works.

Picture the SDLC laid out left-to-right — requirements and design on the left, deployment and maintenance on the right. “Shifting left” means moving security activities toward the left — earlier in the process.

   left  ◄─────────────────────────────────────►  right
   design ──── code ──── test ──── deploy ──── maintain

   ❌ traditional:  security happens here ──────────► (late)
   ✅ shift left:   security happens  ◄── here (early & throughout)

Why shifting left matters — and this is the economic heart of AppSec:

• Cost rises sharply the later a flaw is found. A security flaw caught in design is a conversation and a diagram edit. The same flaw caught in code review is a code change. Caught in testing, a bug-fix cycle. Caught in production, an incident — with all the cost and risk of 4.7. The later, the more expensive, by a large margin.
• Some flaws can only be fixed early. Insecure design (4.3) cannot be cheaply patched later — it must be caught at the design stage or it ships.
• Early security is preventive, not reactive. Catching a class of bug at design or in code review prevents it; catching it in production reacts to it after exposure.

“Shift left” does not mean “stop doing security at the later stages” — security testing, deployment gates, and production monitoring all still matter. It means also, and especially, doing security early — and continuously throughout — rather than only at the end. The Secure Development Lifecycle is “shift left” made concrete: security present at every stage, weighted toward the early ones.

For you, “shift left” should feel intuitive — it is the same logic as 4.3’s “design security in early, when a diagram can still be changed,” now as an organizing principle for the whole development process.

Part 5: The Concept — The AppSec Engineer’s Role

What does an Application Security engineer actually do, day to day? The role is broad, and the rest of Track B details its main activities — but the shape of it:

• Enable secure development. The AppSec engineer’s central job is to help the development organization produce secure software — by providing the processes, tools, guidance, and review that make security part of how software gets built.
• Threat modeling (5B.4) — leading or facilitating threat modeling during design, so security is considered before code is written.
• Security code review (5B.2) — reviewing code for vulnerabilities, and helping establish code-review practices.
• Security testing and automation (5B.3) — setting up and running the automated security testing (SAST, DAST, dependency scanning) woven into the development pipeline.
• Guidance and standards — defining secure coding standards, providing developers with guidance and training, being the security resource developers turn to.
• Vulnerability management for applications (4.8) — tracking and driving the remediation of application vulnerabilities.
• Working with developers (5B.5) — and this is central, not peripheral: AppSec is fundamentally a collaborative role. The AppSec engineer succeeds by making developers able and willing to build securely — not by being a gatekeeper who blocks them.

A crucial framing: the AppSec engineer is not the lone person responsible for “doing the security.” That model fails — one person cannot secure everything a whole development organization produces. The AppSec engineer’s real job is to make secure development a property of the whole organization — to make the developers themselves build securely, supported by good process and tooling. This is why 5B.5 (“working with developers”) exists as a full page: AppSec is as much about people and process as about code.

Part 6: The Concept — Why This Track Fits a Developer

This page closes by being explicit about something true of the whole track: Application Security is, of the three Phase 5 tracks, the one that most directly builds on a developer background. This is not encouragement — it is an accurate description of the role.

Why your developer background is the AppSec engineer’s core asset:

• You understand how software is actually built. AppSec is about securing the development process and the code — and you have lived inside both. You know how applications, APIs, and databases really fit together, where shortcuts get taken, how teams actually work. An AppSec engineer without that understanding is at a real disadvantage; you have it already.
• You can read and reason about code. Security code review (5B.2) is reading code. Vast amounts of AppSec work are code work — exactly your existing skill, now aimed at security.
• You can automate. Security testing automation (5B.3) and integrating tools into pipelines are engineering — scripting, tooling, CI/CD. Your Phase 0.6 skills and developer experience apply directly.
• You can speak to developers as a peer. 5B.5’s collaborative core — turning findings into fixes, guiding developers — works far better when you genuinely understand their world and can talk to them as one of them. A security person developers see as “one of us” is dramatically more effective than one they see as an outside gatekeeper.
• You understand the SDLC from the inside. This entire page’s framework — the Secure Development Lifecycle — is the development process you already know, with security woven in. You are not learning the process; you are learning the security layer over a process you have lived.

The honest framing: AppSec still requires the security knowledge — the offensive understanding (Phases 2–3), the defensive disciplines (Phase 4), the security mindset (Phase 1). You needed the whole curriculum to get here. But on top of that security knowledge, the AppSec role rewards a developer background more directly than any other security specialization. For a developer making this career switch, Track B is, very often, the most natural and strongest fit.

🔑 The deep lesson: Application Security works by weaving security into every stage of the Secure Development Lifecycle rather than bolting it on at the end — the principle of “shift left,” because security found early is far cheaper and some flaws can only be fixed early. The AppSec engineer’s job is to make secure development a property of the whole organization. And of all the directions a developer can specialize in, this is the one that builds most directly on what you already are.

📓 Key Terms

🧪 Hands-On Lab

Track B’s labs are largely about process, review, and tooling rather than attacking. Use software projects (your own, or open-source) and the deliberately vulnerable apps from Phase 2.

Task 1 — Map a real SDLC. Take a development process you know (from your own developer experience, or a documented one). Write out its stages. Then, for each stage, write the security activity that should be woven in (using Part 3’s table). See the Secure Development Lifecycle on a real example.

Task 2 — Place your prior knowledge. Go through Phases 1 and 4 and, for each major topic (threat modeling, secure coding, secure design, hardening, security testing, vulnerability management), write which SDLC stage it belongs to. Confirm for yourself that the Secure Development Lifecycle is your existing knowledge, organized.

Task 3 — Cost-of-late-fixing reflection. Write a short reflection on “shift left”: take one vulnerability class from Phase 2 and describe what fixing it would cost if caught at design vs in code review vs in testing vs in production. Make the economic argument concrete in your own words.

Task 4 — Study a Secure SDLC framework. Find a reputable, published Secure Development Lifecycle / secure-SDLC framework or maturity model and read an overview. Note how the industry formally structures “security woven into development.”

Task 5 — Assess a project’s SDLC security. Take an open-source project (or one of your own). Assess: at which SDLC stages does it appear to have security activity? Where are the gaps? What would you add? This is the AppSec engineer’s assessing mindset.

Task 6 — Write your AppSec foundation note. In Notion, create an “Application Security” page: what AppSec is, the Secure Development Lifecycle, “shift left,” and the AppSec engineer’s role. This is the foundation the rest of Track B builds on.

Task 7 — Reflect on the fit. Write an honest reflection: how does your developer background map onto the AppSec engineer’s role (Part 6)? What developer skills are already AppSec assets? This feeds your career thinking (Phase 7).

⚠️ Common Mistakes

• Thinking security is a final inspection. Security bolted on at the end cannot catch design flaws and is expensive. It must be woven into every SDLC stage.
• Misunderstanding “shift left” as “only do security early.” Shift left means also and especially early — security testing, deployment gates, and monitoring still matter. It is about adding early security, not removing later security.
• Thinking the AppSec engineer “does the security” alone. One person cannot secure everything a development organization produces. AppSec makes secure development a property of the whole organization.
• Treating the Secure Development Lifecycle as new material. It is the organizing framework for what Phases 1 and 4 already taught — placed into the development process.
• Underrating the developer background. For AppSec it is a central, defining strength — understanding how software is built, reading code, automating, speaking to developers as a peer.
• Forgetting the security knowledge is still required. AppSec rewards a developer background, but it is built on the offensive and defensive security knowledge of the whole curriculum.

✅ Recap & What’s Next

• Application Security secures software by weaving security into every stage of the Secure Development Lifecycle — not bolting it on at the end.
• The guiding principle is “shift left”: move security earlier (and keep it throughout), because early-found flaws are far cheaper and some — insecure design especially — can only be fixed early.
• The AppSec engineer makes secure development a property of the whole organization — a role that, of the three tracks, builds most directly on a developer background.

Next (5B.2): The Secure Development Lifecycle’s coding stage centers on examining code for vulnerabilities. Page 5B.2 is security code review — reading code systematically, at a developer’s depth, to find what attackers would otherwise find for you.