La lliçó anterior va acabar amb una pregunta incòmoda: el Top Ten conscienia sobre quins riscos existeixen, però no serveix per demostrar que una aplicació és segura. Quan Lucía ha de respondre a un client corporatiu que exigeix "garanties de seguretat" al contracte de BazarNube, o quan vol donar a un pentester una llista clara de què comprovar, el Top Ten es queda curt. Necessita una cosa diferent: no una llista de perills, sinó una llista de requisits verificables. Aquesta és la segona eina de la nostra caixa: OWASP ASVS, l'Application Security Verification Standard. En aquesta lliçó la presentem a alt nivell; el detall —nivells, requisits concrets, com implementar-lo— és el contingut del mòdul 4.

1. Què és ASVS
2. ASVS davant del Top Ten: requisits vs riscos
3. Els tres nivells de verificació (visió general)
4. Casos d'ús: checklist, contractes i pentests
5. Com faria servir ASVS l'equip de BazarNube

L'OWASP ASVS (Application Security Verification Standard) és un estàndard de requisits de seguretat verificables per a aplicacions web. Dit de manera simple: és una llista organitzada de "coses que l'aplicació ha de complir", redactades de manera que es puguin comprovar una per una (verificar si es compleixen o no).

Els seus trets essencials:

• És un estàndard, no un document de conscienciació. Mentre el Top Ten diu "compte amb la injecció", ASVS diu una cosa comprovable com "tota consulta a base de dades ha de fer servir consultes parametritzades".
• Està organitzat per capítols temàtics (autenticació, control d'accés, validació d'entrada, criptografia, gestió de sessions, etc.), no per "top de riscos".
• Cada requisit és una afirmació verificable, pensada per respondre amb un sí/no i una evidència. Això el fa ideal per a auditories, checklists i contractes.
• S'estructura en nivells (L1, L2, L3) segons quanta seguretat necessita l'aplicació.

La paraula que resumeix ASVS és verificació. No pregunta "coneixes aquest risc?", sinó "pots demostrar que l'has mitigat?".

Aquest és el punt clau de la lliçó. Top Ten i ASVS no competeixen: són complementaris i operen en plans diferents. Confondre'ls és un error comú.

Una manera intuïtiva de veure-ho:

Analogia útil: el Top Ten és com el fullet dels "deu accidents domèstics més comuns"; ASVS és com la inspecció tècnica amb la seva llista de punts a comprovar (la instal·lació elèctrica compleix?, hi ha detector de fums?, el gas està revisat?). El primer et conscienia; el segon et permet signar que la casa és habitable.

No tota aplicació necessita el mateix grau de seguretat: no és el mateix un blog personal que la passarel·la de pagaments de BazarNube. Per això ASVS defineix tres nivells d'exigència creixents. Aquí només els presentem; el mòdul 4 explica quins requisits concrets entren en cadascun.

Idees que convé fixar ja, sense entrar en detall:

• Els nivells són acumulatius: L2 inclou tot el de L1, i L3 inclou tot el de L2.
• El nivell es tria segons el risc del negoci i les dades que maneja l'aplicació, no per caprici.
• Per a un marketplace que processa pagaments i dades personals com BazarNube, l'objectiu raonable sol ser L2. L3 es reserva per al més crític.

Per a què serveix ASVS en el dia a dia? Els seus tres usos més habituals:

1. Com a checklist de verificació de seguretat. L'equip repassa els requisits aplicables i marca quins compleix BazarNube, quins no i quins no apliquen. El resultat és un inventari objectiu de l'estat de seguretat, molt més útil que "creiem que estem bé".
2. Com a base per a contractes i requisits. Quan BazarNube contracta un desenvolupament extern, o quan un client li exigeix garanties, es pot escriure al contracte "l'aplicació complirà ASVS nivell 2". Això converteix una exigència vaga ("que sigui segur") en un compromís mesurable i auditable.
3. Com a guió per a pentests i auditories. En lloc que cada pentester improvisi, ASVS ofereix un abast comú: "verifica aquests requisits del capítol d'autenticació i control d'accés". Els informes surten estructurats i comparables entre auditories.

Apliquem-ho. El backlog de troballes que vam començar a etiquetar amb el Top Ten és bo per detectar problemes, però no per demostrar que estem complets. Aquí entra ASVS. L'equip faria aquests passos (que el mòdul 4 desenvolupa):

1. Triar el nivell objectiu. Com que BazarNube maneja pagaments i dades personals, fixen ASVS L2 com a meta. Ho anoten com a decisió d'arquitectura.
2. Convertir requisits en tasques verificables. Cada requisit ASVS aplicable es converteix en una comprovació concreta sobre l'app. Vegem com es veu, de manera simplificada, aquesta traducció:

Fixa't en la potència d'aquest format davant del Top Ten:

• Cada línia és una afirmació comprovable amb un veredicte (COMPLEIX / NO COMPLEIX / REVISAR).
• Cada incompliment enllaça amb una troballa del backlog, que al seu torn porta la seva etiqueta Top Ten (A01, A03, A07...). Així, Top Ten i ASVS es reforcen: el Top Ten anomena el risc, ASVS el verifica.
• El conjunt dona una foto objectiva i presentable a direcció o a un client: "complim el 82% dels requisits L2, aquests són els pendents".

3. Fer servir la checklist com a pont cap al pentest. Quan contractin un pentest o facin servir ZAP (lliçó 02-04), l'abast ja està definit pels requisits ASVS marcats com a "REVISAR" o "NO COMPLEIX".

En resum: ASVS dona a BazarNube el llenguatge per passar de "coneixem els riscos" a "podem demostrar, requisit a requisit, on estem".

• Confondre ASVS amb el Top Ten. No són intercanviables: el Top Ten conscienia (riscos), ASVS verifica (requisits). Es fan servir junts, no un en lloc de l'altre.
• Triar L3 "per ser el més segur". Apuntar a un nivell superior al que necessites genera un cost enorme i requisits que no aporten al teu risc real. Tria el nivell pel valor de les dades, no per perfeccionisme. Per a BazarNube, L2 és la meta assenyada.
• Tractar ASVS com a tot-o-res. No cal complir el 100% de cop. La checklist serveix precisament per anar mesurant l'avanç i prioritzar.
• Verificar només a la interfície. Molts requisits (especialment L2/L3) exigeixen mirar el codi i el disseny, no només provar l'app des de fora. Verificar únicament la UI dona falsa tranquil·litat.
• Consell: comença pels capítols de control d'accés i autenticació. Solen ser on més incompliments apareixen i on més impacte té arreglar-los.

Exercici 1. Per a cada frase, indica si correspon al Top Ten o a ASVS: (a) "El sistema ha d'invalidar la sessió del costat del servidor en tancar sessió"; (b) "Un dels riscos més crítics és el control d'accés trencat"; (c) "L'aplicació complirà el nivell L2 segons auditoria externa".

Exercici 2. BazarNube maneja pagaments i dades personals, però no és un banc. Argumenta en 3–4 línies quin nivell ASVS seria l'objectiu raonable i per què no L1 ni L3.

Exercici 3. Explica com es complementen Top Ten i ASVS en el flux de treball de BazarNube, fent servir un exemple concret de troballa que passi per tots dos.

Solució 1. (a) ASVS (és un requisit verificable, concret i comprovable); (b) Top Ten (és una afirmació de conscienciació sobre un risc, correspon a A01); (c) ASVS (parla de complir un nivell de verificació, propi de l'estàndard).

Solució 2. L'objectiu raonable és L2. L1 és un mínim pensat per a apps de baix risc, insuficient per a qui processa pagaments i dades personals (exposició a GDPR/PCI-DSS). L3 està reservat a sistemes de valor extrem (banca central, infraestructures crítiques, salut) i suposa un cost de verificació desproporcionat per a un marketplace jove. L2 cobreix el risc real de BazarNube sense sobrecarregar l'equip.

Solució 3. Exemple: durant l'autoavaluació ASVS, el requisit "cada endpoint verifica autorització al servidor" apareix com a NO COMPLEIX. Aquest incompliment es registra al backlog com una troballa i s'etiqueta amb Top Ten com a A01 (Broken Access Control). Així, el Top Ten aporta el nom i la categoria del risc (comunicació i priorització), mentre que ASVS aporta el requisit verificable i l'evidència que estava incomplert (auditoria i demostració). Un conscienia, l'altre verifica; junts tanquen el cicle.

Has conegut la segona eina de la caixa OWASP: ASVS, un estàndard de requisits verificables que respon al que el Top Ten no pot: demostrar l'estat de seguretat d'una aplicació. Saps que es diferencia del Top Ten en el pla (requisits vs riscos), que defineix tres nivells (L1, L2, L3) segons el valor de l'aplicació, i que es fa servir com a checklist, base contractual i guió de pentests. I has vist com BazarNube apuntaria a L2, convertint el seu backlog en una checklist verificable enllaçada amb les etiquetes del Top Ten.

Amb Top Ten i ASVS tenim eines centrades en l'aplicació: els seus riscos i els seus requisits. Però sorgeix una pregunta de nivell superior: està l'organització BazarNube preparada, com a equip i com a procés, per produir programari segur de manera sostinguda? Això ja no es mesura sobre una app, sinó sobre la mateixa organització. És el terreny de la següent eina: a la lliçó 02-03 presentem OWASP SAMM, el model de maduresa del programa de seguretat.