A la lliçó anterior vam veure que cada requisit de l'ASVS està marcat per a un o diversos nivells d'assegurament. Aquesta és una de les grans virtuts de l'estàndard: no exigeix el mateix a un blog de receptes que a una passarel·la de pagaments. L'ASVS defineix tres nivells —L1, L2 i L3— que van sumant rigor. Triar bé el nivell és la decisió més important en adoptar l'estàndard, perquè determina quants requisits apliquen i amb quina profunditat cal verificar-los. En aquesta lliçó entendrem què exigeix cada nivell, com triar l'adequat segons la criticitat de l'aplicació, i decidirem amb arguments quin nivell objectiu té sentit per a BazarNube.

1. Per què l'ASVS té nivells
2. Nivell 1 (L1): oportunista / bàsic
3. Nivell 2 (L2): estàndard
4. Nivell 3 (L3): avançat / crític
5. Taula comparativa L1 / L2 / L3
6. Com triar el nivell segons criticitat i dades
7. Quin nivell tria BazarNube i per què

Aplicar els centenars de requisits de l'ASVS a tota aplicació per igual seria absurd: un formulari de contacte estàtic no necessita el mateix blindatge que un sistema bancari. Els nivells resolen aquest problema graduant l'exigència. Són acumulatius: cada nivell superior inclou tots els requisits de l'inferior i hi afegeix els seus.

La idea és senzilla: pujar de nivell no canvia de checklist, amplia l'existent i augmenta la profunditat amb què cal verificar cada control.

El Nivell 1 és el mínim de seguretat que tota aplicació hauria d'assolir. Cobreix els controls davant les amenaces més comunes i de menor esforç —l'atacant "oportunista" que fa servir eines automàtiques i tècniques conegudes sense dedicar recursos especials.

Característiques clau:

• Verificable de manera totalment externa, sense accés al codi font ni a la documentació. Es pot comprovar mitjançant proves de caixa negra / pentest.
• Protegeix davant vulnerabilitats àmpliament conegudes (bona part del Top Ten es cobreix aquí).
• És el terra, no l'objectiu, per a gairebé qualsevol aplicació que gestioni dades d'usuaris.

Exemples d'exigències típiques de L1:

• Existeix control d'accés i les funcions sensibles requereixen autenticació.
• Les contrasenyes tenen una longitud mínima i no són les d'una llista de compromeses.
• L'aplicació codifica la sortida per prevenir XSS.
• El trànsit va sobre TLS.

Aplicacions típiques L1: llocs de baix risc, aplicacions internes sense dades sensibles, o com a pas previ de maduresa abans d'assolir L2.

El Nivell 2 és el recomanat per a la majoria de les aplicacions, especialment les que gestionen dades personals, transaccions o informació de negoci significativa. Defensa davant atacants hàbils i motivats que fan servir eines i tècniques avançades de manera dirigida.

Característiques clau:

• Requereix accés a documentació, disseny i codi font per verificar-se correctament (no n'hi ha prou amb caixa negra). Es combina revisió de codi amb proves.
• Afegeix controls de defensa en profunditat: gestió de sessions robusta, control d'accés a nivell d'objecte, criptografia ben aplicada, logging d'esdeveniments de seguretat, validació exhaustiva.
• És el nivell que solen exigir clients enterprise, normatives de protecció de dades i auditories serioses.

Exemples d'exigències que L2 afegeix sobre L1:

• Verificació de propietat del recurs en cada accés (evita IDOR de manera sistemàtica).
• Dades sensibles xifrades en repòs amb gestió de claus adequada.
• Registre d'esdeveniments de seguretat rellevants amb protecció davant manipulació.
• Anti-automatització i protecció davant credential stuffing.

Aplicacions típiques L2: comerç electrònic, SaaS B2B, aplicacions amb dades personals o de pagament. Aquí encaixa BazarNube.

El Nivell 3 és el més alt i es reserva per a aplicacions crítiques: aquelles el compromís de les quals tindria conseqüències greus per a la vida, la seguretat nacional, grans volums econòmics o infraestructures essencials.

Característiques clau:

• Exigeix el màxim rigor: revisió de codi exhaustiva, anàlisi d'arquitectura, modelatge d'amenaces documentat i defensa en profunditat en totes les capes.
• Requereix justificar el disseny de seguretat, no només que els controls existeixin: cal demostrar que l'arquitectura és resistent.
• L'esforç de verificació és substancialment més gran; s'aplica només quan el risc ho justifica.

Exemples d'exigències que L3 afegeix sobre L2:

• Segregació estricta de components i confiança mínima entre mòduls.
• Verificació que existeix modelatge d'amenaces i que el disseny el reflecteix.
• Controls criptogràfics avançats i gestió de claus de màxim nivell.
• Traçabilitat i logging aptes per a anàlisi forense complet.

Aplicacions típiques L3: banca core, salut, sistemes militars, infraestructures crítiques, plataformes que processen grans volums de pagaments com a nucli del negoci.

L'elecció del nivell no és una preferència estètica: es deriva del risc, que depèn de quines dades es gestionen i què passaria si es comprometessin. Un procediment pràctic:

1. Inventaria les dades i funcions sensibles. Hi ha dades personals? Mitjans de pagament? Historials mèdics? Diners reals movent-se?
2. Estima l'impacte d'un compromís. Molèstia, pèrdua econòmica moderada, dany greu a persones o al negoci?
3. Considera obligacions externes. Normativa (RGPD, PCI-DSS), exigències contractuals de clients, sector regulat.
4. Mapeja a nivell:

Un antipatró habitual és "aspirar a L3 perquè sona més segur". L3 té un cost de verificació molt alt i només es justifica quan el risc ho exigeix; sobredimensionar el nivell consumeix recursos que estarien millor invertits a complir bé el nivell correcte.

Apliquem el procediment a BazarNube:

1. Dades que gestiona: comptes d'usuari, adreces, historial de compres i, sobretot, dades de pagament i dades personals de compradors i venedors del marketplace.
2. Impacte d'un compromís: frau econòmic, filtració de dades personals (amb sanció RGPD), pèrdua de confiança i del contracte amb el client enterprise.
3. Obligacions externes: el client corporatiu exigeix conformitat demostrable; el tractament de pagaments acosta a exigències tipus PCI-DSS; el RGPD aplica per les dades personals.
4. Però no és banca core ni infraestructura crítica que posi vides en joc.

La conclusió de l'equip és clara:

BazarNube adopta ASVS Nivell 2 (L2) com a objectiu.

Raonament que Lucía documenta al backlog:

• L1 es queda curt: gestiona pagaments i dades personals; el terra bàsic no cobreix els seus riscos ni satisfà el client enterprise.
• L3 és sobredimensionat: no és un sistema on un error costi vides ni un banc core; el cost de verificació L3 no està justificat pel risc real.
• L2 és el punt correcte: exigeix defensa en profunditat, verificació amb codi i disseny, control d'accés a nivell d'objecte, criptografia i logging robustos —just el que un marketplace amb pagaments necessita— i és el nivell que clients i auditors esperen.

Es deixa la porta oberta a elevar puntualment certs mòduls (per exemple, el subsistema de pagaments) a exigències de L3, sense portar tota l'aplicació a aquest nivell. Aquesta idea de "L2 general amb reforços selectius" és una estratègia madura i realista.

• Triar el nivell per ambició i no per risc. "Anem a per L3" sense justificar-ho dispara el cost i alenteix sense aportar seguretat proporcional.
• Creure que L1 es verifica igual que L2. L1 admet caixa negra; L2 i L3 exigeixen accés a codi i disseny. Prometre L2 amb només un pentest de caixa negra és incomplir el mètode.
• Oblidar que els nivells són acumulatius. L2 inclou tots els requisits L1; no es "salta" el nivell inferior.
• Aplicar un únic nivell a un sistema molt heterogeni. És vàlid fixar L2 general i reforçar a L3 els components més crítics (com pagaments).
• Consell: documenta per què tries el nivell (dades, impacte, obligacions). Aquesta justificació és la primera evidència que demanarà un auditor.

Exercici 1. Una startup llança una web informativa sense comptes d'usuari ni dades personals, només contingut públic. Quin nivell ASVS li recomanaries i per què? Quin mètode de verificació n'hi hauria prou?

Exercici 2. Justifica en 3–4 frases, com si ho escrivissis al backlog de BazarNube, per què L2 és més adequat que L3 per al marketplace tot i gestionar pagaments.

Exercici 3. L'equip de pagaments de BazarNube proposa: "tot el marketplace a L3 per estar segurs". Rebat o matisa la proposta proposant una alternativa més eficient.

Solució 1. Nivell 1 (L1). No gestiona dades personals ni sensibles i l'impacte d'un compromís és baix (com a molt defacement del contingut públic). El terra bàsic davant atacants oportunistes és proporcional al risc. En ser L1, n'hi hauria prou amb una verificació de caixa negra / pentest sense necessitat d'accés al codi, tot i que revisar-lo sempre és desitjable.

Solució 2. "BazarNube gestiona dades personals i de pagament, així que L1 no cobreix els seus riscos ni satisfà el client enterprise. Tanmateix, no és banca core ni infraestructura crítica amb impacte sobre vides, per la qual cosa L3 —amb el seu cost de threat modeling exhaustiu i verificació d'arquitectura— està sobredimensionat. L2 exigeix defensa en profunditat, control d'accés per objecte, criptografia i logging robustos verificats amb codi i disseny, que és just el nivell de rigor que un marketplace amb pagaments necessita i que auditors i clients esperen."

Solució 3. Portar tot el marketplace a L3 dispara enormement el cost de verificació (revisió exhaustiva d'arquitectura, threat modeling documentat de cada component) sense que la majoria de mòduls (catàleg, ressenyes, perfil) ho justifiquin pel seu risc. Alternativa més eficient: fixar L2 com a objectiu general i reforçar selectivament a exigències de L3 només el subsistema de pagaments, que és on l'impacte d'un error és més gran. S'obté el blindatge on importa sense pagar el cost L3 en tota l'aplicació.

L'ASVS gradua la seva exigència en tres nivells acumulatius: L1 (bàsic, davant atacants oportunistes, verificable en caixa negra), L2 (estàndard, per a la majoria d'apps amb dades, verificable amb codi i disseny) i L3 (avançat, per a sistemes crítics, amb threat modeling i revisió d'arquitectura). El nivell es tria per risc: quines dades es gestionen i quin impacte tindria el seu compromís. BazarNube adopta L2 per gestionar pagaments i dades personals sense ser un sistema crític, amb l'opció de reforçar puntualment el mòdul de pagaments.

Ja sabem quin estàndard fem servir i a quin nivell aspirem. Toca ara obrir el catàleg i veure els requisits concrets. A la lliçó següent, 04-03 Requisits de Seguretat, recorrerem els capítols més rellevants (autenticació, sessions, control d'accés, validació, criptografia, logging...), aprendrem a llegir un requisit verificable i mapejarem les troballes del Top Ten de BazarNube a requisits ASVS concrets.