En tancar el mòdul anterior vam deixar ZAP situat no com una eina solta, sinó com una peça d'un engranatge més gran: la verificació dinàmica automatitzada dins d'un procés. Aquest procés té nom propi. Un Cicle de Vida de Desenvolupament Segur (Secure Software Development Life Cycle, S-SDLC) és la disciplina que converteix la seguretat d'un esdeveniment puntual —una auditoria abans de sortir a producció— en una propietat contínua del desenvolupament. En aquest mòdul teixim tot l'après: el Top Ten com a catàleg de riscos, ASVS com a requisits verificables, SAMM com a mesura de maduresa i ZAP com a verificació dinàmica. Aquesta primera lliçó construeix el marc on totes aquestes peces encaixen, i l'aterra en un S-SDLC concret per a BazarNube.

1. Què és un SDLC i per què "assegurar-lo"
2. El principi shift-left
3. Seguretat en cada fase del cicle
4. Gates de seguretat (portes de qualitat)
5. On encaixen ASVS, SAMM i ZAP
6. Un S-SDLC concret per a BazarNube
7. Errors comuns i consells
8. Exercicis
9. Conclusió

Tot programari segueix un cicle de vida, es documenti o no: algú demana alguna cosa (requisits), algú ho dissenya, s'implementa, es prova, es desplega i es manté fins que es retira. Un SDLC és simplement fer explícites i repetibles aquestes fases. Un S-SDLC afegeix a cada fase activitats de seguretat, de manera que una fallada es detecti com abans millor i no arribi a producció.

La diferència és econòmica abans que tècnica. El cost de corregir un defecte creix de forma abrupta a mesura que avança el cicle:

Assegurar el SDLC és, en el fons, moure la detecció cap a l'esquerra del gràfic.

Shift-left ("desplaçar a l'esquerra") és la idea rectora de l'S-SDLC: portar les activitats de seguretat el més a prop possible de l'inici del cicle. En lloc d'un pentest final que descobreix problemes quan ja són cars d'arreglar, es sembra seguretat des dels requisits.

Shift-left no significa abandonar les proves tardanes. La seguretat es distribueix al llarg de tot el cicle; simplement es deixa de concentrar tot l'esforç al final. Un model madur combina controls primerencs (requisits ASVS, modelatge d'amenaces) amb controls tardans (DAST, monitorització en operació). A aquesta idea complementària se l'anomena de vegades shift-right: seguir observant en producció.

Aquí es defineix què ha de fer el sistema i, amb la mateixa serietat, què no ha de permetre. Es capturen requisits de seguretat com a històries o criteris d'acceptació. ASVS és la font natural: en lloc de "el login ha de funcionar", escrivim "les contrasenyes s'emmagatzemen amb un algorisme de hashing adaptatiu (ASVS 2.4.1)".

• Requisits funcionals de seguretat (autenticació, control d'accés, xifratge).
• Requisits no funcionals (resiliència, registre i monitorització).
• Classificació de dades (què és PII, què és un secret).

Es decideix com es construeix. És la fase amb major retorn d'inversió en seguretat perquè una fallada de disseny no s'arregla amb un pedaç. Aquí viu el modelatge d'amenaces (ho veurem a fons a 07-02) i l'aplicació de principis com defensa en profunditat, mínim privilegi i fallada segura. Recordem que el Top Ten 2021 va introduir A04: Disseny Insegur precisament per donar pes a aquesta fase.

Escriure codi sense reintroduir els riscos del catàleg. Es recolza en:

• Guies de codificació segura i OWASP Cheat Sheets.
• Linters i SAST integrats a l'editor i als hooks de commit.
• Revisió de codi amb focus en seguretat.
• Ús de llibreries i frameworks que ja resolen el problema (per exemple, consultes parametritzades enfront de concatenació de SQL).

Verificar que els requisits de seguretat es compleixen. Combina:

• SAST (anàlisi estàtica del codi).
• SCA (anàlisi de dependències de tercers).
• DAST (proves dinàmiques sobre l'app en execució: aquí entra ZAP).
• Proves manuals guiades per la WSTG (Web Security Testing Guide).

Portar a producció de forma segura: configuració endurida (contra A05: Configuració de Seguretat Incorrecta), gestió de secrets fora del codi, infraestructura com a codi revisada i escaneig de contenidors.

La seguretat no acaba al desplegament. En operació es monitoritza (A09: Fallades de Registre i Monitorització), es gestionen vulnerabilitats noves en dependències (A06: Components Vulnerables), es pedaça i es recullen lliçons que retroalimenten els requisits del cicle següent.

Un gate és un punt de control on la feina no avança a la fase següent si no compleix un criteri de seguretat. És el mecanisme que fa que l'S-SDLC tingui "dents": sense gates, les bones pràctiques són opcionals i s'ometen sota pressió de terminis.

Un bon gate distingeix entre bloquejant (trenca el build) i d'avís (informa però deixa passar). Començar amb massa gates bloquejants genera rebuig de l'equip; s'introdueixen de forma progressiva, en línia amb la maduresa que mesura SAMM.

Les peces que hem estudiat no competeixen: cadascuna respon a una pregunta diferent del procés.

Una forma útil de recordar-ho: el Top Ten educa, ASVS especifica, SAMM mesura i ZAP comprova. L'S-SDLC és el fil que les connecta.

BazarNube tenia seguretat "al final": una revisió apressada abans de cada release. L'objectiu és distribuir-la. Aquesta és la taula mestra que Lucía i la SRE proposen al CTO, mapejant cada fase amb una activitat i el seu artefacte OWASP de suport:

I el gate de release que acorden, expressat com a criteri del pipeline:

El detall de per què cada nivell d'ASVS aplica a cada actiu, i de com el threat model alimenta aquests requisits, es desenvolupa a les lliçons següents. L'essencial ara és veure l'esquelet: cada fase té una activitat, un amo i un artefacte, i hi ha gates que impedeixen avançar sense complir.

• Confondre S-SDLC amb "comprar eines". Un pipeline ple d'escàners sense gates ni amos genera soroll, no seguretat. El procés i les persones van primer.
• Gates tot-o-res des del primer dia. Bloquejar el build per qualsevol troballa mitjana frustra l'equip i empeny a ometre el control. Introdueix gates de forma gradual: primer informatius, després bloquejants per al crític.
• Oblidar la fase d'operació. Molts programes moren al desplegament. Els components vulnerables (A06) apareixen després de sortir a producció; sense gestió contínua, l'S-SDLC caduca.
• No assignar responsables. "La seguretat és de tots" acaba sent "de ningú". Cada activitat de la taula necessita un amo anomenat.
• Consell: comença per una fase on el retorn sigui alt i visible —normalment disseny (threat modeling) o el gate de commit (SAST + secrets)— i expandeix des d'aquí. Un S-SDLC es construeix per iteracions, igual que es puja de nivell a SAMM.

Exercici 1. Classifica cada activitat en la seva fase de l'S-SDLC: (a) escaneig de la imatge Docker abans de publicar-la, (b) escriure el criteri "l'usuari no pot veure comandes d'un altre usuari", (c) executar ZAP contra l'entorn de staging, (d) dibuixar un diagrama de flux de dades del checkout.

Exercici 2. BazarNube vol el seu primer gate bloquejant. Disposa de SAST, SCA, secret scanning i DAST. Quin convertiries en bloquejant primer i per què? Justifica-ho en termes de soroll/valor.

Exercici 3. Explica, amb el model de cost relatiu, per què moure el modelatge d'amenaces de la fase de proves a la de disseny estalvia diners.

Solució 1.

• (a) Desplegament. (b) Requisits. (c) Proves. (d) Disseny.

Solució 2. El candidat més raonable és el secret scanning: té una taxa molt baixa de falsos positius (una clau AWS o un token és inequívoc), el seu impacte és altíssim (un secret filtrat és un incident immediat) i bloquejar no alenteix la feina legítima. SAST i DAST generen més soroll i convé rodar-los primer en mode avís abans de bloquejar. Així es maximitza valor i es minimitza fricció, guanyant la confiança de l'equip per a gates més estrictes.

Solució 3. Una fallada de disseny detectada en proves costa de l'ordre de 10x corregir-la, perquè implica refer codi i proves ja escrites; detectada en disseny costa 1x, perquè només es canvia un diagrama o una decisió d'arquitectura abans d'escriure una línia. El modelatge d'amenaces en disseny evita construir sobre una base insegura, mentre que en proves només confirma un problema ja materialitzat.

Un S-SDLC transforma la seguretat d'un control final en una propietat distribuïda al llarg de tot el cicle, sostinguda pel principi shift-left i per gates que impedeixen avançar sense complir. Hem vist com el Top Ten, ASVS, SAMM i ZAP encaixen cadascun en la seva fase, i hem esbossat l'S-SDLC de BazarNube fase a fase. La fase amb major retorn és el disseny, i la seva activitat estrella és el modelatge d'amenaces: la disciplina d'anticipar què pot sortir malament abans de construir-ho. És exactament el que desenvolupem a fons a la lliçó següent, 07-02, reprenent la introducció que vam deixar pendent a 03-05.