The checkout threat model we built in the previous lesson left a list of mitigations turned into verifiable requirements. That said, a requirement that only gets checked when someone remembers is a fragile requirement. The promise of this module was that security would move from a final phase to a continuous property of the process, and that continuity comes from automation. DevSecOps is the evolution of DevOps that integrates security as a shared, automated responsibility within the software delivery flow. In this lesson we look at how to orchestrate the controls—SAST, SCA, DAST, secret scanning, IaC, and containers—inside a pipeline, and we design BazarNube's DevSecOps pipeline.

1. What DevSecOps is and why it arose
2. A culture of shared responsibility
3. Security as Code
4. The controls of a secure pipeline
5. Gates, secrets management, and policy as code
6. BazarNube's DevSecOps pipeline
7. Common mistakes and tips
8. Exercises
9. Conclusion

DevOps brought development and operations together to deliver software faster and more frequently. But that speed clashed with the classic security model: a manual review at the end, which became a bottleneck or, worse, got skipped. DevSecOps resolves the tension by integrating security into the automated flow, not after it. The "Sec" is not a third phase between "Dev" and "Ops": it is a cross-cutting attribute of both.

The core idea is that if we deploy a hundred times a day, security cannot depend on one person reviewing by hand; it has to run on its own, on every change, and give feedback in minutes. It is the shift-left of lesson 07-01 taken to its operational conclusion.

DevSecOps is, before it is tooling, a cultural shift. In the old model, security "belonged" to the security team; in DevSecOps it is the responsibility of everyone who touches the product.

• Development fixes security findings like any other bug, within its own flow.
• Operations/SRE contribute hardening, monitoring, and response.
• The security team moves from "doing" security to enabling it: defining policies, choosing tools, training, and advising. This is the security champions model we will explore further in 07-04.

The antipattern to avoid is the "wall you throw it over": development finishes and "throws" the code to security. DevSecOps tears down that wall. This culture is exactly what SAMM measures in its Governance domain and in the training practice.

The technical principle that makes DevSecOps possible is security as code: expressing security—controls, policies, configuration, infrastructure—as versioned files in the repository, not as manual steps or documents in a wiki.

Advantages of treating security as code:

• Versionable and auditable: every policy change has a history in Git (who, when, why).
• Reviewable: a policy goes through a pull request like any other code.
• Repeatable: it applies the same across all environments, eliminating "it works on my machine."
• Automatable: the pipeline runs it without intervention.

Under this umbrella fall the pipeline itself (CI YAML), the infrastructure (Terraform), the policies (OPA/Rego), and the scanner configuration.

A DevSecOps pipeline orchestrates several families of tools, each covering a different angle of risk. Here we present them at a high level as pieces of the process; the concrete catalog of tools we will see in 07-05, and the ZAP details we already covered in module 6.

The placement logic follows the cost of feedback: the fastest, lowest-false-positive checks (secrets, SAST, SCA) run early and often; the slowest (DAST, which needs the app running) runs later, against a deployed environment.

As we saw in 07-01, a gate blocks progress if a criterion is not met. In DevSecOps, gates are codified in the pipeline. The practical key is to distinguish severities: block on the critical, warn on the rest, so you do not paralyze delivery with noise.

A pipeline needs credentials (to deploy, to access registries), and that is a sensitive point: if the pipeline itself leaks secrets, we have opened a breach at the heart of the process. Basic rules:

• Never put secrets in the YAML or the code: they are injected from a secrets manager (Vault, the CI provider's secrets, etc.).
• Least privilege and short lifetimes: credentials scoped to what the job needs and, where possible, ephemeral (OIDC instead of long-lived keys).
• Secret scanning as a safety net to detect accidental leaks.

Security rules are expressed as evaluable code. For example, with Open Policy Agent (OPA) you can require that no image be deployed without having passed the scan, or that no bucket be public.

BazarNube starts from a CI that only ran unit tests. The SRE and Lucía design a staged evolution, mapping each control to the checkout threat model mitigation that was still pending automation.

Adoption strategy (avoids team pushback):

1. Weeks 1-2: blocking secret scanning (high value, low noise) and everything else in warning mode.
2. Month 1: blocking SAST and SCA only for critical/high severity, after cleaning up the existing findings.
3. Month 2: DAST in staging and the aggregate release gate.
4. Ongoing: raise the bar as debt drops, aligned with the SAMM maturity goal.

The result is that the mitigations that in 07-02 were "requirements in the backlog" become checks the pipeline runs on every change, without depending on someone remembering.

• Turning on all gates at once. The team finds the build broken by dozens of preexisting findings and loses confidence in the process. Introduce controls in warning mode, clean up the debt, and only then block.
• Alert fatigue. A thousand low-severity findings bury the three that matter. Prioritize by severity, suppress known false positives, and tune the rules.
• Secrets in the pipeline. Putting a token directly in the YAML is a breach waiting to happen. Always use the secrets manager and short-lived credentials.
• Automating without culture. A perfect pipeline is useless if development ignores the findings because they are not "their" job. Shared responsibility is the prerequisite.
• Tip: measure the feedback time. If the security pipeline takes 40 minutes, people avoid it. Parallelize jobs and move the slow part (DAST) to a later phase so the fast feedback arrives in minutes.

Exercise 1. Order these controls from earliest to latest in the pipeline and justify your answer: DAST, secret scanning, SCA.

Exercise 2. A BazarNube developer wants to deploy urgently and the release gate blocks on a "High" vulnerability in a dependency. What legitimate options are there, and which is the antipattern?

Exercise 3. Explain why secret scanning is a good candidate for the first blocking gate in terms of the value/noise ratio, connecting it to secrets management in CI.

Solution 1. Order: secret scanning → SCA → DAST. Secret scanning is the cheapest and fastest (it analyzes text, with almost no false positives) and runs as early as pre-commit. SCA analyzes the dependency tree in CI, fast and deterministic. DAST is the latest because it needs the application deployed and running in staging, so it can only run after the build and the deploy. The order follows the principle of giving the fastest feedback as early as possible.

Solution 2. Legitimate options: (a) update the dependency to a patched version—the ideal—; (b) if there is no patch, assess whether the vulnerability is exploitable in context and apply a compensating mitigation; (c) request a formal exception, approved by someone responsible (the CTO at BazarNube), recorded and with an expiration date. The antipattern is disabling the gate or raising the threshold "temporarily" without any record: that exception becomes permanent and erodes the entire process.

Solution 3. Secret scanning has an excellent value/noise ratio: a leaked token or key is practically unambiguous (an extremely low false-positive rate) and its impact is maximal (an exposed credential is an immediate incident, potentially in the pipeline itself). Since secrets management in CI is a particularly sensitive point, detecting accidental leaks in a blocking way protects the heart of the process without slowing down legitimate work, which makes it ideal as the first gate.

DevSecOps turns security controls into automated, versioned, shared-responsibility checks, orchestrated inside the delivery pipeline. We have seen its families of controls, secrets management, and policy as code, and we have designed BazarNube's pipeline with a realistic adoption strategy that automates the threat model's mitigations. But no tool or pipeline replaces the judgment of the people who write the code and approve the pull requests: the decisive link is still human. In the next lesson, 07-04, we address that human factor: how training and awareness—secure coding, security champions, gamification—sustains the whole culture that DevSecOps takes for granted.