As we closed the previous module, we positioned ZAP not as a standalone tool but as one cog in a larger machine: automated dynamic verification within a process. That process has a name of its own. A Secure Software Development Life Cycle (S-SDLC) is the discipline that turns security from a one-off event, an audit right before going to production, into a continuous property of development. In this module we weave together everything we have learned: the Top Ten as a catalog of risks, ASVS as verifiable requirements, SAMM as a measure of maturity, and ZAP as dynamic verification. This first lesson builds the framework where all of those pieces fit, and grounds it in a concrete S-SDLC for BazarNube.

1. What an SDLC is and why "securing" it matters
2. The shift-left principle
3. Security in every phase of the cycle
4. Security gates (quality gates)
5. Where ASVS, SAMM, and ZAP fit
6. A concrete S-SDLC for BazarNube
7. Common mistakes and tips
8. Exercises
9. Conclusion

All software follows a life cycle, whether it is documented or not: someone asks for something (requirements), someone designs it, it is implemented, it is tested, it is deployed, and it is maintained until it is retired. An SDLC simply makes those phases explicit and repeatable. An S-SDLC adds security activities to every phase, so that a flaw is caught as early as possible and never reaches production.

The difference is economic before it is technical. The cost of fixing a defect grows sharply as the cycle advances:

Securing the SDLC is, at heart, about moving detection toward the left of that chart.

Shift-left is the guiding idea of the S-SDLC: bring security activities as close to the start of the cycle as possible. Instead of a final pentest that surfaces problems when they are already expensive to fix, you sow security starting from requirements.

Shift-left does not mean abandoning late testing. Security is distributed across the entire cycle; you simply stop concentrating all the effort at the end. A mature model combines early controls (ASVS requirements, threat modeling) with late controls (DAST, monitoring in operation). This complementary idea is sometimes called shift-right: keep observing in production.

This is where you define what the system must do and, with equal seriousness, what it must not allow. You capture security requirements as stories or acceptance criteria. ASVS is the natural source: instead of "login must work," we write "passwords are stored with an adaptive hashing algorithm (ASVS 2.4.1)."

• Functional security requirements (authentication, access control, encryption).
• Non-functional requirements (resilience, logging and monitoring).
• Data classification (what is PII, what is a secret).

This is where you decide how it is built. It is the phase with the highest return on security investment, because a design flaw cannot be fixed with a patch. This is where threat modeling lives (we will cover it in depth in 07-02), along with the application of principles such as defense in depth, least privilege, and fail-safe defaults. Recall that the 2021 Top Ten introduced A04: Insecure Design precisely to give weight to this phase.

Writing code without reintroducing the risks in the catalog. It relies on:

• Secure coding guidelines and the OWASP Cheat Sheets.
• Linters and SAST integrated into the editor and into commit hooks.
• Code review with a security focus.
• Using libraries and frameworks that already solve the problem (for example, parameterized queries instead of SQL concatenation).

Verifying that the security requirements are met. It combines:

• SAST (static analysis of the code).
• SCA (analysis of third-party dependencies).
• DAST (dynamic testing against the running app: this is where ZAP comes in).
• Manual testing guided by the WSTG (Web Security Testing Guide).

Shipping to production securely: hardened configuration (against A05: Security Misconfiguration), secrets management kept out of the code, reviewed infrastructure as code, and container scanning.

Security does not end at deployment. In operation you monitor (A09: Security Logging and Monitoring Failures), manage newly disclosed vulnerabilities in dependencies (A06: Vulnerable and Outdated Components), patch, and gather lessons that feed back into the requirements of the next cycle.

A gate is a checkpoint where work does not advance to the next phase unless it meets a security criterion. It is the mechanism that gives the S-SDLC its "teeth": without gates, good practices are optional and get skipped under deadline pressure.

A good gate distinguishes between blocking (breaks the build) and advisory (informs but lets work through). Starting with too many blocking gates breeds team pushback; you introduce them gradually, in line with the maturity SAMM measures.

The pieces we have studied do not compete: each answers a different question in the process.

A useful way to remember it: the Top Ten educates, ASVS specifies, SAMM measures, and ZAP checks. The S-SDLC is the thread that connects them.

BazarNube used to bolt security on "at the end": a rushed review before every release. The goal is to distribute it. This is the master table that Lucía and the SRE propose to the CTO, mapping each phase to an activity and its supporting OWASP artifact:

And the release gate they agree on, expressed as a pipeline criterion:

The detail of why each ASVS level applies to each asset, and of how the threat model feeds these requirements, is developed in the following lessons. What matters now is seeing the skeleton: each phase has an activity, an owner, and an artifact, and there are gates that prevent advancing without meeting them.

• Confusing an S-SDLC with "buying tools." A pipeline full of scanners with no gates or owners generates noise, not security. Process and people come first.
• All-or-nothing gates from day one. Breaking the build over any medium finding frustrates the team and pushes people to bypass the control. Introduce gates gradually: informational first, then blocking for what is critical.
• Forgetting the operation phase. Many programs die at deployment. Vulnerable components (A06) show up after going to production; without continuous management, the S-SDLC expires.
• Not assigning owners. "Security is everyone's job" ends up being "no one's job." Every activity in the table needs a named owner.
• Tip: start with one phase where the return is high and visible, usually design (threat modeling) or the commit gate (SAST + secrets), and expand from there. An S-SDLC is built through iterations, just as you level up in SAMM.

Exercise 1. Classify each activity into its S-SDLC phase: (a) scanning the Docker image before publishing it, (b) writing the criterion "a user cannot see another user's orders," (c) running ZAP against the staging environment, (d) drawing a data flow diagram of the checkout.

Exercise 2. BazarNube wants its first blocking gate. It has SAST, SCA, secret scanning, and DAST available. Which one would you make blocking first, and why? Justify it in terms of noise versus value.

Exercise 3. Using the relative-cost model, explain why moving threat modeling from the testing phase to the design phase saves money.

Solution 1.

• (a) Deployment. (b) Requirements. (c) Testing. (d) Design.

Solution 2. The most reasonable candidate is secret scanning: it has a very low false-positive rate (an AWS key or a token is unmistakable), its impact is extremely high (a leaked secret is an immediate incident), and blocking does not slow down legitimate work. SAST and DAST generate more noise and are better run in advisory mode first before blocking. This maximizes value and minimizes friction, earning the team's trust for stricter gates.

Solution 3. A design flaw caught in testing costs on the order of 10x to fix, because it means reworking code and tests already written; caught in design it costs 1x, because you only change a diagram or an architecture decision before writing a single line. Threat modeling in design avoids building on an insecure foundation, whereas in testing it only confirms a problem that has already materialized.

An S-SDLC transforms security from a final control into a property distributed across the entire cycle, held together by the shift-left principle and by gates that prevent advancing without compliance. We have seen how the Top Ten, ASVS, SAMM, and ZAP each fit into their phase, and we have sketched BazarNube's S-SDLC phase by phase. The phase with the highest return is design, and its flagship activity is threat modeling: the discipline of anticipating what can go wrong before building it. That is exactly what we develop in depth in the next lesson, 07-02, picking up the introduction we left pending in 03-05.