El threat model del checkout que vam construir a la lliçó anterior va deixar una llista de mitigacions convertides en requisits verificables. Ara bé, un requisit que només es comprova quan algú se'n recorda és un requisit fràgil. La promesa d'aquest mòdul era que la seguretat passés de fase final a propietat contínua del procés, i aquesta continuïtat l'aporta l'automatització. DevSecOps és l'evolució de DevOps que integra la seguretat com a responsabilitat compartida i automatitzada dins del flux de lliurament de programari. En aquesta lliçó veiem com orquestrar els controls —SAST, SCA, DAST, secret scanning, IaC i contenidors— dins d'un pipeline, i dissenyem el pipeline DevSecOps de BazarNube.

1. Què és DevSecOps i per què sorgeix
2. Cultura de responsabilitat compartida
3. Security as Code
4. Els controls del pipeline segur
5. Gates, gestió de secrets i polítiques com a codi
6. El pipeline DevSecOps de BazarNube
7. Errors comuns i consells
8. Exercicis
9. Conclusió

DevOps va unir desenvolupament i operacions per lliurar programari més ràpid i amb més freqüència. Però aquesta velocitat va xocar amb el model clàssic de seguretat: una revisió manual al final, que es convertia en coll d'ampolla o, pitjor, s'ometia. DevSecOps resol la tensió integrant la seguretat en el flux automatitzat, no després d'ell. La "Sec" no és una tercera fase entre "Dev" i "Ops": és un atribut transversal de tots dos.

La idea central és que si despleguem cent vegades al dia, la seguretat no pot dependre d'una persona que revisa a mà; ha d'executar-se sola, a cada canvi, i donar feedback en minuts. És el shift-left de la lliçó 07-01 portat a la seva conseqüència operativa.

DevSecOps és, abans que eines, un canvi cultural. En el model antic la seguretat "pertanyia" a l'equip de seguretat; en DevSecOps és responsabilitat de tothom que toca el producte.

• El desenvolupament corregeix les troballes de seguretat com qualsevol altre bug, en el seu propi flux.
• Operacions/SRE aporten enduriment, monitorització i resposta.
• L'equip de seguretat passa de "fer" la seguretat a habilitar-la: defineix polítiques, tria eines, forma i assessora. És el model de security champions que aprofundirem a 07-04.

L'antipatró a evitar és el "mur sobre el qual es llança": desenvolupament acaba i "llança" el codi a seguretat. DevSecOps enderroca aquest mur. Aquesta cultura és exactament el que SAMM mesura al seu domini de Govern i a la pràctica de formació.

El principi tècnic que fa possible DevSecOps és security as code: expressar la seguretat —controls, polítiques, configuració, infraestructura— com a fitxers versionats al repositori, no com a passos manuals o documents en un wiki.

Avantatges de tractar la seguretat com a codi:

• Versionable i auditable: cada canvi de política té història a Git (qui, quan, per què).
• Revisable: una política passa per pull request com qualsevol codi.
• Repetible: s'aplica igual a tots els entorns, eliminant el "a la meva màquina funciona".
• Automatitzable: el pipeline l'executa sense intervenció.

Sota aquest paraigua cauen el pipeline mateix (YAML de CI), la infraestructura (Terraform), les polítiques (OPA/Rego) i la configuració dels escàners.

Un pipeline DevSecOps orquestra diverses famílies d'eines, cadascuna cobrint un angle diferent del risc. Aquí les presentem a alt nivell com a peces del procés; el catàleg concret d'eines el veurem a 07-05, i el detall de ZAP ja el vam cobrir al mòdul 6.

La lògica de col·locació segueix el cost del feedback: el més ràpid i amb menys falsos positius (secrets, SAST, SCA) s'executa aviat i sovint; el més lent (DAST, que necessita l'app aixecada) s'executa després, contra un entorn desplegat.

Com vam veure a 07-01, un gate impedeix avançar si no es compleix un criteri. En DevSecOps els gates es codifiquen al pipeline. La clau pràctica és distingir severitats: bloquejar davant del crític, avisar davant de la resta, per no paralitzar el lliurament amb soroll.

Un pipeline necessita credencials (per desplegar, per accedir a registries), i aquest és un punt sensible: si el mateix pipeline filtra secrets, hem obert una bretxa al cor del procés. Regles bàsiques:

• Mai secrets al YAML ni al codi: s'injecten des d'un gestor de secrets (Vault, secrets del proveïdor de CI, etc.).
• Mínim privilegi i vida curta: credencials acotades al que el job necessita i, si és possible, efímeres (OIDC en lloc de claus de llarga durada).
• Secret scanning com a xarxa de seguretat per detectar filtracions accidentals.

Les regles de seguretat s'expressen com a codi avaluable. Per exemple, amb Open Policy Agent (OPA) es pot exigir que cap imatge es desplegui sense haver passat l'escaneig, o que cap bucket sigui públic.

BazarNube parteix d'un CI que només executava tests unitaris. La SRE i Lucía dissenyen una evolució per etapes, mapejant cada control amb la mitigació del threat model del checkout que quedava pendent d'automatitzar.

Estratègia d'adopció (evita el rebuig de l'equip):

1. Setmana 1-2: secret scanning bloquejant (alt valor, baix soroll) i la resta en mode avís.
2. Mes 1: SAST i SCA bloquejants només per a severitat crítica/alta, després d'haver netejat les troballes existents.
3. Mes 2: DAST en staging i gate de release agregat.
4. Continu: pujar el llistó a mesura que baixa el deute, alineat amb l'objectiu de maduresa de SAMM.

El resultat és que les mitigacions que a 07-02 eren "requisits al backlog" passen a ser comprovacions que el pipeline executa a cada canvi, sense dependre que algú se'n recordi.

• Encendre tots els gates alhora. L'equip es troba el build trencat per desenes de troballes preexistents i perd la confiança en el procés. Introdueix controls en mode avís, neteja el deute i després bloqueja.
• Fatiga d'alertes. Mil troballes de baixa severitat enterren les tres que importen. Prioritza per severitat, suprimeix falsos positius coneguts i ajusta les regles.
• Secrets al pipeline. Posar un token directament al YAML és una bretxa esperant a passar. Usa sempre el gestor de secrets i credencials de vida curta.
• Automatitzar sense cultura. Un pipeline perfecte no serveix si desenvolupament ignora les troballes per no ser "la seva" feina. La responsabilitat compartida és el prerequisit.
• Consell: mesura el temps de feedback. Si el pipeline de seguretat triga 40 minuts, la gent l'evita. Paral·lelitza jobs i mou el lent (DAST) a una fase posterior perquè el feedback ràpid arribi en minuts.

Exercici 1. Ordena aquests controls de més primerenc a més tardà al pipeline i justifica-ho: DAST, secret scanning, SCA.

Exercici 2. Un desenvolupador de BazarNube vol desplegar urgent i el gate de release bloqueja per una vulnerabilitat "High" en una dependència. Quines opcions legítimes hi ha i quin és l'antipatró?

Exercici 3. Explica per què el secret scanning és un bon candidat a primer gate bloquejant en termes de la relació valor/soroll, connectant-ho amb la gestió de secrets en CI.

Solució 1. Ordre: secret scanning → SCA → DAST. El secret scanning és el més barat i ràpid (analitza text, gairebé sense falsos positius) i s'executa ja en pre-commit. El SCA analitza l'arbre de dependències en CI, ràpid i determinista. El DAST és el més tardà perquè necessita l'aplicació desplegada i en execució en staging, per la qual cosa només pot córrer després del build i el deploy. L'ordre segueix el principi de donar el feedback més ràpid com abans millor.

Solució 2. Opcions legítimes: (a) actualitzar la dependència a una versió pedaçada —l'ideal—; (b) si no hi ha pedaç, avaluar si la vulnerabilitat és explotable en el context i aplicar una mitigació compensatòria; (c) sol·licitar una excepció formal, aprovada per un responsable (el CTO a BazarNube), registrada i amb caducitat. L'antipatró és desactivar el gate o pujar el llindar "temporalment" sense registre: aquesta excepció es torna permanent i erosiona tot el procés.

Solució 3. El secret scanning té una relació valor/soroll excel·lent: un token o clau filtrada és pràcticament inequívoc (baixíssim fals positiu) i el seu impacte és màxim (una credencial exposada és un incident immediat, potencialment al mateix pipeline). Com que a més la gestió de secrets en CI és un punt especialment sensible, detectar filtracions accidentals de forma bloquejant protegeix el cor del procés sense alentir la feina legítima, cosa que el fa ideal com a primer gate.

DevSecOps converteix els controls de seguretat en comprovacions automàtiques, versionades i de responsabilitat compartida, orquestrades dins del pipeline de lliurament. Hem vist les seves famílies de controls, la gestió de secrets i les polítiques com a codi, i hem dissenyat el pipeline de BazarNube amb una estratègia d'adopció realista que automatitza les mitigacions del threat model. Però cap eina ni pipeline substitueix el criteri de les persones que escriuen el codi i aproven els pull requests: el baula decisiu segueix sent humà. A la lliçó següent, 07-04, abordem aquest factor humà: com la formació i conscienciació —secure coding, security champions, gamificació— sosté tota la cultura que DevSecOps pressuposa.