En tancar el mòdul 3 ens vam quedar amb una idea incòmoda: l'OWASP Top Ten és un mapa excel·lent dels riscos més freqüents, però és només això, els "deu més freqüents". No és un checklist exhaustiu ni una cosa que un tester pugui verificar requisit a requisit i signar com a "complert". BazarNube necessita fer el pas següent: passar de "coneixem els grans riscos" a "podem verificar, de manera sistemàtica i per nivells, que l'aplicació compleix un catàleg complet de requisits de seguretat". Aquest estàndard existeix i es diu ASVS. En aquesta lliçó veurem què és, com està estructurat, a qui serveix i per què és diferent (i complementari) del Top Ten.

1. Què és l'ASVS i per a què serveix
2. La diferència clau: requisits verificables vs. riscos
3. Estructura de l'estàndard: capítols V1–V14
4. Anatomia d'un requisit ASVS
5. A qui serveix: desenvolupadors, testers i compradors
6. Com decideix BazarNube adoptar ASVS

ASVS són les sigles d'Application Security Verification Standard (Estàndard de Verificació de Seguretat d'Aplicacions). És un projecte insígnia d'OWASP que ofereix una llista oberta i comunitària de requisits de seguretat verificables per a aplicacions web i serveis.

El seu propòsit és respondre una pregunta molt concreta que el Top Ten no respon bé:

"Què ha de complir exactament la meva aplicació per considerar-se raonablement segura, i com comprovo, un per un, que ho compleix?"

L'ASVS proporciona aquest "què" en forma de centenars d'afirmacions comprovables. Cada requisit està redactat per poder respondre's amb un sí / no / no aplica després d'una revisió de codi, una prova de penetració o una comprovació de disseny. Serveix per a tres coses fonamentals:

• Com a mètrica: mesura quant de segur és un producte en una escala definida.
• Com a guia: diu als desenvolupadors quins controls construir.
• Com a base de contracte: permet exigir un nivell de seguretat concret a un proveïdor o auditor.

Al mòdul 2 ja vam presentar l'ASVS de manera panoràmica i el vam definir com l'estàndard de requisits verificables amb tres nivells (L1–L3). Ara l'obrim en profunditat. La versió de referència clàssica és la v4.0.3; la comunitat ha treballat en una v5.0 que reorganitza i modernitza els capítols, però els conceptes que veurem (nivells, capítols temàtics, requisits atòmics) són estables entre versions. Farem servir la numeració V1–V14 de la família v4.x per ser la més estesa.

Aquesta distinció és el cor del mòdul, així que convé fixar-la bé.

Un exemple ho aclareix. Al Top Ten, A07 – Errors d'Identificació i Autenticació és una categoria de risc: "l'autenticació pot estar mal feta". L'ASVS descompon aquest mateix territori en desenes de requisits concrets i comprovables:

El Top Ten et diu on mirar; l'ASVS et diu què exigir i com comprovar-ho. No competeixen: el Top Ten és la porta d'entrada didàctica i l'ASVS és l'instrument de verificació rigorós.

L'ASVS agrupa els seus requisits en capítols temàtics, cadascun identificat amb una V (de Verification) i un número. Conèixer el mapa complet permet orientar-se ràpid quan busques un requisit.

Cada capítol se subdivideix en seccions (per exemple V2.1 "Requisits de contrasenyes") i cada secció conté requisits individuals (V2.1.1, V2.1.2...). La versió v5.0 reorganitza alguns d'aquests capítols i renumera, però la lògica temàtica es manté: sempre hi trobaràs autenticació, sessions, control d'accés, validació, criptografia, logging, etc. com a blocs recognoscibles.

Tot requisit comparteix una estructura comuna. Veure-ho en detall ens ajudarà a llegir-los amb soltesa a les pròximes lliçons.

Fixa't en tres propietats que fan "verificable" un requisit:

• És una afirmació comprovable: comença per "Verificar que..." i descriu un estat que pot confirmar-se o refutar-se.
• Està mapejat a nivells: cada requisit indica si aplica a L1, L2, L3 o a diversos (ho veurem a la lliçó 04-02).
• Sol referenciar un CWE: connecta amb la taxonomia estàndard de debilitats, útil per traçar i per a eines.

Aquesta redacció atòmica és el que permet convertir l'estàndard en una checklist real, en criteris d'acceptació i en evidències d'auditoria.

L'ASVS està dissenyat per servir a tres audiències, i entendre cadascuna ajuda BazarNube a decidir com fer-lo servir:

• Desenvolupadors (com Lucía i Marc): el fan servir com a guia de construcció. Abans d'escriure el mòdul de login, consulten V2 i saben quins controls han d'implementar. L'estàndard es converteix en un catàleg de "què he de construir per estar bé".
• Testers i auditors (la part de verificació): el fan servir com a guió de proves. Cada requisit és un cas de prova; el resultat de l'auditoria és un percentatge de compliment per nivell, no una opinió vaga.
• Compradors i responsables (product owners, clients, direcció): el fan servir com a clàusula de contracte. En lloc de demanar "una aplicació segura" (indefinible), demanen "conformitat ASVS Nivell 2 verificada per un tercer", que sí que és mesurable i exigible.

Aquesta triple utilitat —construir, verificar i contractar sobre el mateix vocabulari— és el que converteix l'ASVS en un llenguatge comú entre equips que abans parlaven de seguretat de manera difusa.

Després del mòdul 3, el backlog de seguretat de BazarNube té desenes d'entrades: control d'accés reforçat, xifratge de dades de pagament, capçaleres de seguretat, validació d'entrada, logging, mitigació de SSRF... Lucía planteja el problema a la retrospectiva:

"Hem arreglat moltes coses, però no tenim manera de dir quant de segurs estem ni de demostrar-ho a un client enterprise que ens ho auditarà. Necessitem un marc de verificació, no una altra llista de pors."

La SRE afegeix que el nou client corporatiu exigeix, per contracte, "conformitat demostrable amb un estàndard reconegut". El Top Ten no serveix per signar això; l'ASVS sí. L'equip pren tres decisions que guiaran la resta del mòdul:

1. Adoptar ASVS com a catàleg de requisits verificables de referència.
2. Triar un nivell objectiu d'acord amb la seva criticitat (ho decidirem a 04-02).
3. Mapejar el backlog actual del Top Ten a requisits ASVS concrets, per no començar de zero (ho farem a 04-03).

Amb aquesta full de ruta, BazarNube deixa d'"apagar focs" i comença a "verificar per catàleg".

• Confondre ASVS amb el Top Ten. No són el mateix ni substituts: el Top Ten és awareness de riscos; l'ASVS és verificació de requisits. Es fan servir junts.
• Intentar complir "tot l'ASVS" de cop. L'estàndard està pensat per aplicar-se per nivells; sense triar nivell, la llista és aclaparadora i desmotiva.
• Llegir un requisit com una recomanació difusa. Cada requisit és una afirmació amb resposta binària; si no pots respondre sí/no/no aplica, és que encara no l'has entès o provat.
• Ignorar el número de capítol. V2, V3, V4... són un índex mental molt potent; memoritzar el mapa V1–V14 accelera enormement la feina.
• Consell: comença sempre localitzant el capítol temàtic (això és autenticació? → V2), després la secció, i només després el requisit concret. Anar del general a l'específic evita perdre's.

Exercici 1. Explica amb les teves paraules la diferència entre "A07 – Errors d'Autenticació" del Top Ten i el requisit "V2.1.1 – Verificar que les contrasenyes tenen almenys 12 caràcters" de l'ASVS. Per què es diu que un és un risc i l'altre un requisit verificable?

Exercici 2. BazarNube té al seu backlog "reforçar el control d'accés perquè teníem IDOR". En quin capítol de l'ASVS (V1–V14) buscaries els requisits corresponents i per què?

Exercici 3. Un client demana a BazarNube "que l'aplicació sigui segura". Reescriu aquesta petició com una clàusula contractual fent servir el vocabulari de l'ASVS i explica per què la teva versió és verificable i l'original no.

Solució 1. "A07 – Errors d'Autenticació" és una categoria de risc: assenyala una àrea on solen aparèixer problemes, però no diu què comprovar exactament. "V2.1.1" és un requisit verificable: és una afirmació concreta ("les contrasenyes tenen ≥12 caràcters") que un tester pot confirmar o refutar amb un sí/no. El primer crea consciència i prioritza; el segon es comprova i es signa. L'ASVS descompon el risc ampli del Top Ten en molts requisits atòmics com aquest.

Solució 2. Al capítol V4 – Control d'accés. IDOR (Insecure Direct Object Reference) és un error d'autorització: l'usuari accedeix a un objecte que no li pertany. Els requisits d'autorització, comprovació de propietat de recursos i prevenció de referències directes insegures viuen a V4. (El territori correspon a A01 del Top Ten, que a l'ASVS es verifica des de V4.)

Solució 3. Versió ASVS: "El proveïdor lliurarà l'aplicació amb conformitat verificada a l'OWASP ASVS Nivell 2 (v4.0.3), demostrada mitjançant evidències de compliment per requisit i una verificació per un tercer independent". És verificable perquè defineix un estàndard concret, un nivell mesurable (L2), un mètode de comprovació (evidències per requisit) i una validació externa. La petició original ("que sigui segura") no és mesurable: no diu contra què, fins a quin punt, ni com es comprova, així que ningú pot signar-ne el compliment.

L'ASVS és l'estàndard d'OWASP per verificar la seguretat d'una aplicació mitjançant un catàleg complet de requisits comprovables, organitzats en els capítols V1–V14 i redactats com a afirmacions amb resposta sí/no/no aplica. Es diferencia del Top Ten en què aquest últim enumera riscos freqüents mentre que l'ASVS enumera requisits verificables, i tots dos es complementen. Serveix a desenvolupadors (guia), testers (guió de proves) i compradors (contracte). BazarNube l'adopta per poder mesurar i demostrar la seva seguretat davant un client que ho exigeix per contracte.

Però hem deixat una peça pendent: l'ASVS no exigeix el mateix a un blog personal que a una plataforma de pagaments. Cada requisit està marcat per a un o diversos nivells d'assegurament. A la lliçó següent, 04-02 Nivells de Verificació, veurem què exigeixen L1, L2 i L3, com triar el nivell adequat segons la criticitat i les dades que gestiona l'aplicació, i decidirem quin nivell objectiu té sentit per a BazarNube.