DevSecOps Pipelines

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

Core Philosophy: Modern software is built and shipped through automated pipelines — a continuous flow from code change to deployed application. DevSecOps means weaving security into that pipeline, so security is built into how software ships, automatically, continuously, on every change. It is the culmination of Track C — and of a theme running through the whole curriculum — security as something built in, not bolted on. And it is, at heart, your DevOps module with security woven through it.

Part 1: The Problem

Across Track C — and Track B before it — you have accumulated a set of security activities that share a striking property: they are automatable and they are most powerful when run continuously, on every change. Application security testing (5B.3 — SAST, DAST, SCA). Cloud configuration checking (5C.2). Container image scanning (5C.3). Infrastructure as Code security scanning and policy enforcement (5C.4).

Each of those pages said, in its own way: this works best automated, in the pipeline. This page is where that promise is fulfilled. The question it answers: how do you weave all of that security into the way software is actually built and shipped, so it happens automatically, every time?

The answer is DevSecOps — and it is the culmination of Track C, pulling together cloud security and application security into a single idea: security built into the delivery pipeline itself.

Part 2: The Concept — From DevOps to DevSecOps

DevOps (covered in your On-Prem/DevOps module) is the modern practice of building and delivering software through automation and a continuous, integrated flow — development and operations working as one, with software moving from code change to deployment through an automated pipeline (the CI/CD pipeline, 5B.3).

DevOps made software delivery fast and automated. But traditionally, security was not part of that flow — it remained a separate, slower, after-the-fact activity. The result: software shipped through a fast automated pipeline, with security trying to catch up afterward. Security became the bottleneck, or got skipped.

DevSecOps fixes this. It is DevOps with security woven in — security made an integral, automated part of the delivery pipeline itself, not a separate stage bolted on.

   DEVOPS
   code ──► build ──► test ──► deploy   (fast, automated)
        security: separate, after-the-fact, the bottleneck

   DEVSECOPS
   code ──► [build + SECURITY] ──► [test + SECURITY]
        ──► [deploy + SECURITY]    (security woven into the flow)
        security: integral, automated, continuous, every change

The name itself — DevSecOps — places security inside DevOps. The core idea: security is everyone’s responsibility and part of the flow, automated and continuous, not a separate gate at the end.

For you, this is a comfortable destination: you already understand DevOps from your On-Prem module. DevSecOps is that — with the security of this whole curriculum woven through it. You are not learning a new world; you are adding the security layer to one you know.

Part 3: The Concept — Security Woven Through the Pipeline

What does “security woven into the pipeline” concretely look like? It means security checks and controls at every stage of the delivery flow — and you have learned every one of these checks already, across Tracks B and C.

   THE DEVSECOPS PIPELINE — security at every stage

   code commit
        │
        ▼
   ┌──────────────────────────────────────────────────┐
   │ secrets scanning  — catch hard-coded secrets      │ (5B.3)
   │ SAST              — scan application source code  │ (5B.3)
   │ SCA               — check dependencies            │ (5B.3, 2.10)
   │ IaC security scan — check infrastructure code     │ (5C.4)
   │ policy as code    — enforce security guardrails   │ (5C.4)
   │ build                                              │
   │ image scanning    — scan container images         │ (5C.3)
   │ DAST              — test the running application  │ (5B.3)
   │ ... more security checks                           │
   └──────────────────────────────────────────────────┘
        │
        ▼
   deploy  ──►  + continuous monitoring & posture scanning
                in production (4.6, 5C.2)

Notice what this diagram is: it is the entire security toolkit of Tracks B and C, placed into the automated delivery pipeline. DevSecOps is not new security techniques — it is the integration of everything you have already learned into the flow of how software ships.

Two consequences make this powerful:

• Security happens automatically, on every change. No one has to remember to run it. Every code change, every infrastructure change, every build is security-checked as a normal part of the flow.
• Security gates (the 5B.3 / 5C.4 idea). The pipeline can be configured so that serious security findings block deployment — insecure code or insecure infrastructure does not ship.

And security does not stop at deployment: it continues into production with continuous monitoring (4.6) and continuous cloud posture scanning (5C.2). DevSecOps secures the whole lifecycle, continuously — embodying Phase 4’s closing lesson that security is an ongoing operation.

Part 4: The Concept — DevSecOps Is Culture, Not Just Tooling

A critical point, and the one most often missed: DevSecOps is not just a pipeline with security tools in it. It is a culture.

You can put every security tool into a pipeline and still not have DevSecOps — if the mindset has not changed. The cultural shift DevSecOps requires:

• Security is everyone’s responsibility. Not “the security team’s job” while developers just build features. In DevSecOps, security is a shared responsibility — built into how everyone works. (This is the 5B.5 lesson — secure development as the whole organization’s property — at the level of the whole delivery process.)
• Security is integrated, not gating. Security woven into the flow, providing fast automated feedback — not a separate slow stage that blocks at the end. The goal is security that keeps pace with fast delivery.
• Speed and security together, not traded off. The old assumption was that security slows things down. DevSecOps’ core proposition is that, done right, you get both — automated security that is fast enough to keep up, and guardrails (5C.4) that let teams move fast safely.
• Collaboration over gatekeeping. Exactly the 5B.5 lesson — security working with developers and operations as a shared effort, not as an outside gatekeeper.
• Built-in, not bolted-on. The recurring theme of this entire curriculum’s defensive half — security designed and built in from the start (4.3, 5B.1, 5C.4), not added afterward.

This is why DevSecOps “shifts left” but also covers the whole pipeline: it is security present everywhere in the flow because the culture treats it as integral. A pipeline full of security tools, run by an organization that still thinks of security as someone else’s separate job, is not really DevSecOps. The tooling is necessary; the culture is what makes it real.

The honest practical note: this cultural shift is the hard part. The tooling is comparatively straightforward to set up. Changing how an organization thinks about security — making it genuinely shared, genuinely integral — is the real work, and it connects directly to the people-and-influence skills of 5B.5.

Part 5: The Concept — Making DevSecOps Work

Beyond tools and culture, the practical principles that make DevSecOps actually effective — most of which you have already met, because they recur throughout the defensive curriculum:

• Automate everything that can be automated. The power of DevSecOps is automated, continuous security. Manual security steps become bottlenecks. Automate the checks (the engineering work — your developer-background advantage).
• Fast feedback. Security feedback must reach developers fast — ideally within the pipeline run, while the change is fresh (the 5B.3 lesson). Slow security feedback gets ignored or becomes a bottleneck.
• Tune to avoid noise. The false-positive lesson from 5B.3 applies to the whole DevSecOps pipeline: if the pipeline floods developers with false positives and low-value findings, they will resent and route around it. Tune the tools; prioritize by real risk (1.1); make findings actionable.
• Tune the gates thoughtfully. Security gates (Part 3) must block on what genuinely matters and not on noise — or they make security the enemy of delivery (the 5B.3 gate-tuning lesson).
• Make findings actionable and well-placed. Findings must reach the right people, with clear what/where/why/how-to-fix, in the tools they already use (5B.3, 5B.5).
• Defense in depth across the pipeline. No single check catches everything (SAST misses what DAST catches, etc. — 5B.3). Multiple, complementary checks across the pipeline (4.3’s defense in depth, applied to the pipeline).
• Don’t forget production. DevSecOps covers the whole lifecycle — monitoring (4.6), cloud posture scanning (5C.2), and incident response (4.7) for what reaches production. The pipeline secures delivery; production security continues.
• It is an evolving practice. Like all security (Phase 4’s closing lesson, and 1.5’s continuous-learning truth), a DevSecOps practice is continuously improved — better automation, better coverage, better tuning.

The DevSecOps engineer’s role pulls all of this together: building and maintaining the security automation in the pipeline, integrating the tooling, tuning it, and — crucially — helping drive the cultural shift (Part 4) that makes it real. It is a role that blends engineering, security, and the collaborative people-skills of 5B.5 — and one in high demand precisely because it is exactly the gap organizations have.

Part 6: The Concept — DevSecOps as the Culmination, and Track C Complete

DevSecOps is where Track C — and several threads of the whole curriculum — come together.

It pulls Track C together. Cloud fundamentals (5C.1), preventing cloud misconfiguration (5C.2), container and orchestration security (5C.3), Infrastructure as Code security (5C.4) — DevSecOps is how all of it is delivered: automated, continuous, woven into the pipeline. Track C built the pieces; DevSecOps assembles them.

It unifies with Track B. Application security testing (Track B’s 5B.3) and cloud/infrastructure security (Track C) meet in the same pipeline. A real DevSecOps pipeline secures both the application code and the infrastructure — Tracks B and C are not separate worlds; DevSecOps is where they join.

It is the ultimate expression of the curriculum’s defensive philosophy. Trace the thread: secure design built in early (4.3); “shift left” for application code (5B.1); “shift left” for infrastructure (5C.4); security as an ongoing operation (Phase 4.8). DevSecOps is the full realization — security designed in, built in, automated, continuous, and everyone’s responsibility, across the whole delivery lifecycle. It is “built in, not bolted on” made total.

It is the answer to why you started. Your motivation for this whole curriculum was that everyone ships code and nobody secures it. DevSecOps is, quite precisely, the organizational and technical solution to exactly that problem — at the level of the whole delivery process. It makes “ship fast” and “ship secure” the same act. A developer who can build DevSecOps is filling the exact gap that motivated you to start.

It is your developer background, fully leveraged. DevSecOps is engineering — pipelines, automation, tooling, code, infrastructure-as-code — with security and with the collaborative culture-building of 5B.5. It draws on your DevOps knowledge, your development skill, and the entire security curriculum. Of the three Phase 5 tracks, Track C connects most directly to your existing On-Prem/DevOps module — and DevSecOps is its peak: the point where DevOps, security, and engineering become one.

🔑 The deep lesson — and the close of Track C: DevSecOps is DevOps with security woven in — security made an automated, continuous, integral part of the delivery pipeline, on every change. It is not just tooling — it is a culture in which security is everyone’s shared responsibility, integrated rather than gating, and speed and security are achieved together. It pulls together everything in Tracks B and C — application and infrastructure security, all of it automated into the pipeline — and it is the full realization of the curriculum’s defensive philosophy: security designed in, built in, continuous, and everyone’s. It is, precisely, the answer to “everyone ships, nobody secures” — and it is where your developer and DevOps background, plus this whole curriculum, come together.

📓 Key Terms

🧪 Hands-On Lab

Build on the pipeline work from 5B.3 and the IaC work from 5C.4. This connects directly to your On-Prem/DevOps module — use that knowledge.

Task 1 — Review DevOps. Revisit the CI/CD and pipeline material in your On-Prem/DevOps module. Confirm you are solid on what a delivery pipeline is — DevSecOps is that, with security woven in.

Task 2 — Build a basic pipeline. Set up a simple CI/CD pipeline for a small project (or extend the one from 5B.3). Confirm the basic flow — code change to build — works.

Task 3 — Weave in application security. Add the Track B security checks to the pipeline: secrets scanning, SAST, SCA. See them run automatically on every change.

Task 4 — Weave in infrastructure security. Add the Track C checks: IaC security scanning (5C.4) and, if possible, a policy-as-code check. Add container image scanning (5C.3) if the project uses containers. Now the pipeline secures both application and infrastructure.

Task 5 — Configure security gates. Configure the pipeline so a serious finding blocks deployment. Then introduce a deliberate issue and watch the gate stop it. Reflect on tuning — how would you make gates block real problems without blocking on noise?

Task 6 — Build the full picture. In Notion, draw your complete DevSecOps pipeline — every security check, mapped to the curriculum page that taught it (the Part 3 diagram, made concrete for your pipeline). See the whole of Tracks B and C assembled into one flow.

Task 7 — Reflect on the culture. Write a reflection on Part 4: why is DevSecOps a culture, not just tooling? What would it take, in a real organization, to make security genuinely shared and integral? Connect this to the 5B.5 people-and-influence skills.

Task 8 — Write a DevSecOps note. In Notion, create a “DevSecOps” page — DevOps to DevSecOps, security woven through the pipeline, the cultural shift, and the principles for making it work. The capstone reference for Track C.

⚠️ Common Mistakes

• Thinking DevSecOps is just tools in a pipeline. It is a culture — security as everyone’s shared, integral responsibility. Tools without the cultural shift are not really DevSecOps.
• Keeping security separate and after-the-fact. That is DevOps-without-the-Sec — security as a bottleneck. DevSecOps weaves security into the flow.
• Treating speed and security as a trade-off. Done right, DevSecOps delivers both — fast automated security and guardrails. The “security slows us down” assumption is what DevSecOps exists to disprove.
• Noisy pipelines. A pipeline flooding developers with false positives gets resented and routed around (the 5B.3 lesson, pipeline-wide). Tune tools, prioritize by risk, make findings actionable.
• Badly tuned gates. Gates blocking on noise make security the enemy of delivery. Block on what genuinely matters.
• Slow security feedback. Feedback must be fast — within the pipeline run. Slow feedback becomes a bottleneck or gets ignored.
• Forgetting production. DevSecOps covers the whole lifecycle — monitoring and posture scanning continue after deployment.
• Relying on one check. Defense in depth across the pipeline — SAST, DAST, SCA, IaC scan, image scan — each catches what the others miss.

✅ Recap & What’s Next

• DevSecOps is DevOps with security woven in — security made an automated, continuous, integral part of the delivery pipeline, running on every change, with security gates that block insecure code or infrastructure from shipping.
• It is culture, not just tooling — security as everyone’s shared responsibility, integrated rather than gating, achieving speed and security together.
• It is the culmination of Tracks B and C — application and infrastructure security, all automated into one pipeline — the full realization of “security built in, not bolted on,” and precisely the answer to “everyone ships, nobody secures.”

Track C complete. You can now operate in Cloud & DevSecOps security — understanding what the cloud changes and the shared responsibility model (5C.1), preventing the misconfigurations that cause cloud breaches (5C.2), securing the container and orchestration stack (5C.3), securing infrastructure as code before it deploys (5C.4), and weaving all of it into a DevSecOps pipeline (5C.5). This is the highest-demand specialization, and the one that connects most directly to your existing On-Prem/DevOps module.

Where to go from here:

• Track A — Bug Bounty Hunter is the freelancing specialization.
• Track B — Application Security Engineer is the employment specialization closest to a developer background — and it unifies with this track in the DevSecOps pipeline.
• Phase 6 — AI Security is the emerging frontier — and AI systems run in the cloud and ship through pipelines, so Cloud/DevSecOps skills apply directly to securing them.
• Phase 7 — Career & Freelancing turns all of this into a career — for a Cloud/DevSecOps direction, page 7.3 (breaking into a security job) is the most directly relevant, and 7.2 covers the (provider-specific) cloud security certifications.

You may do the other tracks now or return to them later — the skills compound, and Tracks B and C in particular meet in the DevSecOps pipeline.

📋 Phase 5, Track C — Page Checklist

Tick each page when its reading and its hands-on lab are done.

• [ ] 5C.1 — Cloud Security Fundamentals
• [ ] 5C.2 — Common Cloud Misconfigurations
• [ ] 5C.3 — Container and Kubernetes Security
• [ ] 5C.4 — Infrastructure as Code Security
• [ ] 5C.5 — DevSecOps Pipelines

Keep growing your living pages:

• [ ] Master Glossary — append every 📓 Key Terms box above.
• [ ] Tools & Reference Cheatsheet — cloud posture scanners, IaC security scanners, image scanners, policy-as-code tools.
• [ ] Cloud Security Fundamentals, Cloud Misconfigurations, Container & Kubernetes Security, Infrastructure as Code Security, DevSecOps notes.

🔑 The Track C throughline: the cloud changed the rules — identity is the new perimeter, and customer-side misconfiguration is the dominant risk. Because the cloud is software-defined, security is most effective built in — checked in infrastructure-as-code before deployment, and woven into the delivery pipeline as DevSecOps. It is the highest-demand specialization, it connects most directly to your DevOps background, and it is the precise organizational answer to “everyone ships, nobody secures.”

📋 PHASE 5 — COMPLETE (All Three Tracks)

Phase 5 — the specialization fork — is now complete across three files:

• Track A — Bug Bounty Hunter (Phase_5A_Bug_Bounty.md) — 5 pages — the freelancing path.
• Track B — Application Security Engineer (Phase_5B_AppSec.md) — 5 pages — the employment path closest to a developer background.
• Track C — Cloud & DevSecOps Security (Phase_5C_Cloud_DevSecOps.md, this file) — 5 pages — the highest-demand path.

15 specialization pages in total. Go deep on the one that matches your immediate goal; return for the others as your career develops — the skills compound, and Tracks B and C in particular meet in the DevSecOps pipeline.

Next — Phase 6: AI Security, the emerging frontier — securing AI systems, and using AI for security work. Then Phase 7: Career & Freelancing, which turns the whole curriculum into a career.