Les tres eines anteriors —Top Ten, ASVS i SAMM— són documents i marcs: et diuen què mirar, què verificar i com madurar, però cap no ataca l'aplicació per tu. A l'autoavaluació SAMM, BazarNube va descobrir el seu buit més urgent: la pràctica de proves de seguretat (Verification) estava en nivell 0, perquè no provaven activament la seva pròpia aplicació. Marc ho resumeix bé: "Tenim checklists precioses, però ningú no ha intentat de veritat trencar l'API". Necessiten una eina executable que colpegi l'aplicació en funcionament i els digui què hi troba. Aquesta és la quarta peça de la caixa: OWASP ZAP, el Zed Attack Proxy. En aquesta lliçó la presentem; la seva instal·lació i ús detallat són el contingut del mòdul 6.

1. Què és ZAP
2. Quin tipus de proves fa: DAST (proves dinàmiques)
3. ZAP davant de SAST i SCA: on encaixa cadascun
4. Casos d'ús de ZAP
5. Com provaria BazarNube la seva API amb ZAP

OWASP ZAP (Zed Attack Proxy) és una eina de codi obert i gratuïta per trobar vulnerabilitats en aplicacions web en execució. És un dels projectes flagship d'OWASP i una de les eines de seguretat més utilitzades del món. Té dues ànimes que convé distingir des del principi:

• Un proxy d'intercepció. ZAP se situa entre el navegador i l'aplicació, de manera que tot el trànsit HTTP/HTTPS hi passa. Això li permet veure, pausar i modificar les peticions i respostes al vol. És com posar una "càmera amb comandament a distància" al mig de la conversa entre client i servidor.
• Un escàner DAST. Sobre aquest trànsit, ZAP pot llançar proves automatitzades que busquen vulnerabilitats conegudes (injeccions, XSS, capçaleres absents, etc.).

En ser programari lliure i comptar amb una comunitat enorme, és una elecció natural per a una startup com BazarNube: cost zero de llicència i capacitat d'integrar-se en el seu pipeline.

ZAP practica proves de tipus DAST (Dynamic Application Security Testing). La paraula clau és dinàmic: ZAP prova l'aplicació mentre s'està executant, atacant-la des de fora, igual que faria un atacant real. No necessita veure el codi font.

Com funciona, a grans trets (el detall és del mòdul 6):

1. Explora (spider/crawl). ZAP recorre l'aplicació per descobrir-ne les URLs, formularis i endpoints.
2. Ataca (active scan). Sobre el que ha descobert, envia peticions manipulades (payloads) per veure si l'aplicació reacciona de manera insegura.
3. Observa i reporta. Analitza les respostes i genera un informe amb les vulnerabilitats trobades, la seva gravetat i evidència.

El gran avantatge de l'enfocament dinàmic: troba fallades tal com es manifesten en execució real, incloent-hi problemes de configuració del servidor que una anàlisi del codi mai no veuria. El seu límit: només veu el que pot assolir des de fora; si un endpoint no es descobreix, no es prova.

ZAP no substitueix altres eines de seguretat: les complementa. Per no confondre-les, convé situar les tres grans famílies de l'anàlisi automatitzada. Aquí les presentem a alt nivell; aprofundim en la combinació a la lliçó 02-05 i al mòdul 7.

La idea essencial: cap eina no ho veu tot. SAST veu el codi però no el comportament real; SCA veu les dependències però no la teva lògica; DAST (ZAP) veu el comportament real però no el codi intern. Una estratègia madura les combina. Per al buit de Verification que SAMM va detectar a BazarNube, ZAP (DAST) és el punt d'entrada més natural, perquè prova l'aplicació tal com està desplegada, sense necessitat d'instrumentar el codi.

ZAP és versàtil. Els seus usos més habituals, de menor a major sofisticació:

• Exploració manual assistida. Navegar l'aplicació amb ZAP com a proxy per inspeccionar i manipular peticions a mà (ideal per entendre com funciona i provar hipòtesis).
• Escaneig automatitzat puntual. Llançar un active scan contra l'aplicació abans d'una release per obtenir un informe ràpid de vulnerabilitats.
• Prova d'APIs. Alimentar ZAP amb la definició de l'API (per exemple, una especificació OpenAPI) perquè provi els seus endpoints de manera sistemàtica. Molt rellevant per a BazarNube, la lògica de la qual viu en una API.
• Integració en CI/CD (DevSecOps). Executar ZAP automàticament al pipeline en cada desplegament, de manera que una fallada nova trenqui el build. Això connecta amb el mòdul 7.

Apliquem-ho al cas. La lògica de negoci de BazarNube viu en la seva API Node.js/Express, amb un mòdul legacy Java al darrere. ZAP és ideal per provar-la. El flux que seguiria l'equip (detallat al mòdul 6) seria:

1. Aixecar l'entorn. BazarNube corre en contenidors Docker, així que la SRE desplega una còpia de l'API en un entorn de proves (mai contra producció sense control).
2. Donar a ZAP el mapa de l'API. Com que l'API està documentada amb OpenAPI, se li passa aquesta definició perquè conegui tots els endpoints (/api/login, /api/comandes/:id, /api/cercar, etc.).
3. Llançar l'escaneig. ZAP explora i ataca cada endpoint amb payloads de prova.

De manera il·lustrativa, així es veuria un fragment d'informe de ZAP sobre l'API de BazarNube (format simplificat; l'eina real i la seva sortida es veuen al mòdul 6):

Observa la potència d'això i com tanca el cicle amb les eines anteriors:

• Cada troballa de ZAP es bolca al backlog i s'etiqueta amb la seva categoria Top Ten (A03, A05, A01), el vocabulari que vam fixar a 02-01.
• Cada troballa es pot creuar amb la checklist ASVS de 02-02: l'IDOR confirma que el requisit de control d'accés estava realment incomplert, no era una sospita.
• El simple fet d'executar ZAP amb regularitat fa pujar la pràctica de Verification de SAMM (02-03) de nivell 0 a nivell 1.

Així, ZAP no és una eina aïllada: és el motor de detecció activa que alimenta d'evidències reals tot el sistema (Top Ten + ASVS + SAMM) que BazarNube ha anat muntant.

• Escanejar producció sense permís ni control. ZAP ataca de veritat: un active scan pot crear dades brossa, disparar accions o degradar el servei. S'executa contra entorns de proves o amb autorització i finestra controlada.
• Creure que ZAP ho troba "tot". DAST només veu l'assolible des de fora i el que sap reconèixer. No detecta fallades de lògica de negoci profundes ni substitueix SAST/SCA ni la revisió humana.
• Escanejar només la superfície web i oblidar l'API. En apps modernes com BazarNube, la lògica és a l'API. Cal donar a ZAP la definició de l'API (OpenAPI) perquè la cobreixi; si no, es prova només una fracció.
• Executar-lo un cop i arxivar l'informe. El valor és en la repetició: integrar-lo al pipeline per detectar regressions. Un escaneig aïllat envelleix en dies.
• Consell: comença amb un escaneig manual/exploratori per entendre l'app abans d'automatitzar. Comprendre el trànsit amb el proxy t'ensenya més sobre la teva pròpia aplicació del que imagines.

Exercici 1. Classifica cada eina com a SAST, DAST o SCA: (a) analitza el codi Java del mòdul de facturació buscant patrons insegurs sense executar-lo; (b) revisa el package.json de l'API buscant llibreries amb CVEs coneguts; (c) ataca /api/cercar amb payloads mentre l'aplicació corre.

Exercici 2. La SRE proposa afegir ZAP al pipeline de CI/CD perquè s'executi en cada desplegament a staging. Explica en 3–4 línies quina pràctica de SAMM millora això i per què és preferible a un escaneig manual esporàdic.

Exercici 3. Un company diu: "Amb ZAP ja no necessitem ASVS ni revisions de codi, perquè ZAP troba les vulnerabilitats". Rebat aquesta afirmació amb dos arguments.

Solució 1. (a) SAST (anàlisi estàtica del codi font, sense executar-lo); (b) SCA (anàlisi de composició: dependències de tercers i les seves vulnerabilitats conegudes); (c) DAST (anàlisi dinàmica de l'aplicació en execució; és el que fa ZAP).

Solució 2. Millora la pràctica de proves de seguretat del domini Verification de SAMM, i ajuda també el desplegament segur (Implementation/DevSecOps). És preferible a l'escaneig esporàdic perquè el converteix en sistemàtic i repetible: cada release es prova automàticament, es detecten regressions de seguida i la pràctica puja de nivell de maduresa (d'"ad hoc" a "definit"), en lloc de dependre que algú es recordi de llançar-lo.

Solució 3. (1) ZAP és DAST: només veu l'assolible des de fora i el que sap reconèixer; no detecta moltes fallades de lògica de negoci, ni problemes en codi no exposat, ni components vulnerables (això és SCA). (2) ASVS i les revisions de codi compleixen una funció diferent i complementària: verificar requisits i raonar sobre el disseny i el codi intern, coses que un escàner dinàmic no fa. La seguretat madura combina SAST, DAST, SCA i verificació manual; cap eina no les reemplaça totes.

Has conegut la quarta eina de la caixa OWASP: ZAP, un proxy d'intercepció i escàner DAST de codi obert que prova l'aplicació en execució, des de fora, com un atacant real. Saps situar-lo davant de SAST (codi) i SCA (dependències) —es complementen, no es substitueixen— i has vist els seus casos d'ús, des de l'exploració manual fins a la integració en CI/CD. I, sobretot, has vist com BazarNube provaria la seva API amb ZAP i com cada troballa tanca el cicle: s'etiqueta amb Top Ten, es creua amb ASVS i fa madurar el seu SAMM.

Amb ZAP completem els quatre projectes flagship que vertebren aquest curs (Top Ten, ASVS, SAMM, ZAP), cadascun amb el seu mòdul dedicat més endavant. Però la caixa d'eines d'OWASP té molt més a oferir: guies de testing, xuletes de remediació, escàners de dependències i aplicacions per practicar. A la lliçó 02-05, l'última del mòdul, presentem aquests altres projectes clau que BazarNube combinarà amb els quatre grans per tenir una estratègia completa.