Al cerrar el módulo 3 nos quedamos con una idea incómoda: el OWASP Top Ten es un mapa excelente de los riesgos más frecuentes, pero es solo eso, los "diez más frecuentes". No es un checklist exhaustivo ni algo que un tester pueda verificar requisito a requisito y firmar como "cumplido". BazarNube necesita dar el siguiente paso: pasar de "conocemos los grandes riesgos" a "podemos verificar, de forma sistemática y por niveles, que la aplicación cumple un catálogo completo de requisitos de seguridad". Ese estándar existe y se llama ASVS. En esta lección veremos qué es, cómo está estructurado, a quién sirve y por qué es distinto (y complementario) del Top Ten.

1. Qué es el ASVS y para qué sirve
2. La diferencia clave: requisitos verificables vs. riesgos
3. Estructura del estándar: capítulos V1–V14
4. Anatomía de un requisito ASVS
5. A quién sirve: desarrolladores, testers y compradores
6. Cómo decide BazarNube adoptar ASVS

ASVS son las siglas de Application Security Verification Standard (Estándar de Verificación de Seguridad de Aplicaciones). Es un proyecto insignia de OWASP que ofrece una lista abierta y comunitaria de requisitos de seguridad verificables para aplicaciones web y servicios.

Su propósito es responder a una pregunta muy concreta que el Top Ten no responde bien:

"¿Qué debe cumplir exactamente mi aplicación para considerarse razonablemente segura, y cómo compruebo, uno por uno, que lo cumple?"

El ASVS proporciona ese "qué" en forma de cientos de afirmaciones comprobables. Cada requisito está redactado para poder responderse con un sí / no / no aplica tras una revisión de código, una prueba de penetración o una comprobación de diseño. Sirve para tres cosas fundamentales:

• Como métrica: mide cuánto de seguro es un producto en una escala definida.
• Como guía: dice a los desarrolladores qué controles construir.
• Como base de contrato: permite exigir un nivel de seguridad concreto a un proveedor o auditor.

En el módulo 2 ya presentamos el ASVS de forma panorámica y lo definimos como el estándar de requisitos verificables con tres niveles (L1–L3). Ahora lo abrimos en profundidad. La versión de referencia clásica es la v4.0.3; la comunidad ha trabajado en una v5.0 que reorganiza y moderniza los capítulos, pero los conceptos que veremos (niveles, capítulos temáticos, requisitos atómicos) son estables entre versiones. Usaremos la numeración V1–V14 de la familia v4.x por ser la más extendida.

Esta distinción es el corazón del módulo, así que conviene fijarla bien.

Un ejemplo lo aclara. En el Top Ten, A07 – Fallos de Identificación y Autenticación es una categoría de riesgo: "la autenticación puede estar mal hecha". El ASVS descompone ese mismo territorio en decenas de requisitos concretos y comprobables:

El Top Ten te dice dónde mirar; el ASVS te dice qué exigir y cómo comprobarlo. No compiten: el Top Ten es la puerta de entrada didáctica y el ASVS es el instrumento de verificación riguroso.

El ASVS agrupa sus requisitos en capítulos temáticos, cada uno identificado con una V (de Verification) y un número. Conocer el mapa completo permite orientarse rápido cuando buscas un requisito.

Cada capítulo se subdivide en secciones (por ejemplo V2.1 "Requisitos de contraseñas") y cada sección contiene requisitos individuales (V2.1.1, V2.1.2...). La versión v5.0 reorganiza algunos de estos capítulos y renumera, pero la lógica temática se mantiene: siempre encontrarás autenticación, sesiones, control de acceso, validación, criptografía, logging, etc. como bloques reconocibles.

Todo requisito comparte una estructura común. Verlo en detalle nos ayudará a leerlos con soltura en las próximas lecciones.

Fíjate en tres propiedades que hacen "verificable" a un requisito:

• Es una afirmación comprobable: empieza por "Verificar que..." y describe un estado que puede confirmarse o refutarse.
• Está mapeado a niveles: cada requisito indica si aplica en L1, L2, L3 o en varios (lo veremos en la lección 04-02).
• Suele referenciar un CWE: conecta con la taxonomía estándar de debilidades, útil para trazar y para herramientas.

Esta redacción atómica es lo que permite convertir el estándar en una checklist real, en criterios de aceptación y en evidencias de auditoría.

El ASVS está diseñado para servir a tres audiencias, y entender cada una ayuda a BazarNube a decidir cómo usarlo:

• Desarrolladores (como Lucía y Marc): lo usan como guía de construcción. Antes de escribir el módulo de login, consultan V2 y saben qué controles deben implementar. El estándar se convierte en un catálogo de "qué debo construir para estar bien".
• Testers y auditores (la parte de verificación): lo usan como guion de pruebas. Cada requisito es un caso de prueba; el resultado de la auditoría es un porcentaje de cumplimiento por nivel, no una opinión vaga.
• Compradores y responsables (product owners, clientes, dirección): lo usan como cláusula de contrato. En lugar de pedir "una aplicación segura" (indefinible), piden "conformidad ASVS Nivel 2 verificada por un tercero", que sí es medible y exigible.

Esta triple utilidad —construir, verificar y contratar sobre el mismo vocabulario— es lo que convierte al ASVS en un lenguaje común entre equipos que antes hablaban de seguridad de forma difusa.

Tras el módulo 3, el backlog de seguridad de BazarNube tiene decenas de entradas: control de acceso reforzado, cifrado de datos de pago, cabeceras de seguridad, validación de entrada, logging, mitigación de SSRF... Lucía plantea el problema en la retrospectiva:

"Hemos arreglado muchas cosas, pero no tenemos forma de decir cuánto de seguros estamos ni de demostrárselo a un cliente enterprise que nos lo va a auditar. Necesitamos un marco de verificación, no otra lista de miedos."

La SRE añade que el nuevo cliente corporativo exige, por contrato, "conformidad demostrable con un estándar reconocido". El Top Ten no sirve para firmar eso; el ASVS sí. El equipo toma tres decisiones que guiarán el resto del módulo:

1. Adoptar ASVS como catálogo de requisitos verificables de referencia.
2. Elegir un nivel objetivo acorde a su criticidad (lo decidiremos en 04-02).
3. Mapear el backlog actual del Top Ten a requisitos ASVS concretos, para no empezar de cero (lo haremos en 04-03).

Con esa hoja de ruta, BazarNube deja de "apagar fuegos" y empieza a "verificar por catálogo".

• Confundir ASVS con el Top Ten. No son lo mismo ni sustitutos: el Top Ten es awareness de riesgos; el ASVS es verificación de requisitos. Se usan juntos.
• Intentar cumplir "todo el ASVS" de golpe. El estándar está pensado para aplicarse por niveles; sin elegir nivel, la lista es abrumadora y desmotiva.
• Leer un requisito como una recomendación difusa. Cada requisito es una afirmación con respuesta binaria; si no puedes responder sí/no/no aplica, es que aún no lo has entendido o probado.
• Ignorar el número de capítulo. V2, V3, V4... son un índice mental muy potente; memorizar el mapa V1–V14 acelera enormemente el trabajo.
• Consejo: empieza siempre localizando el capítulo temático (¿esto es autenticación? → V2), luego la sección, y solo después el requisito concreto. Ir de lo general a lo específico evita perderse.

Ejercicio 1. Explica con tus palabras la diferencia entre "A07 – Fallos de Autenticación" del Top Ten y el requisito "V2.1.1 – Verificar que las contraseñas tienen al menos 12 caracteres" del ASVS. ¿Por qué se dice que uno es un riesgo y el otro un requisito verificable?

Ejercicio 2. BazarNube tiene en su backlog "reforzar el control de acceso porque teníamos IDOR". ¿En qué capítulo del ASVS (V1–V14) buscarías los requisitos correspondientes y por qué?

Ejercicio 3. Un cliente pide a BazarNube "que la aplicación sea segura". Reescribe esa petición como una cláusula contractual usando el vocabulario del ASVS y explica por qué tu versión es verificable y la original no.

Solución 1. "A07 – Fallos de Autenticación" es una categoría de riesgo: señala un área donde suelen aparecer problemas, pero no dice qué comprobar exactamente. "V2.1.1" es un requisito verificable: es una afirmación concreta ("las contraseñas tienen ≥12 caracteres") que un tester puede confirmar o refutar con un sí/no. El primero crea conciencia y prioriza; el segundo se comprueba y se firma. El ASVS descompone el riesgo amplio del Top Ten en muchos requisitos atómicos como este.

Solución 2. En el capítulo V4 – Control de acceso. IDOR (Insecure Direct Object Reference) es un fallo de autorización: el usuario accede a un objeto que no le pertenece. Los requisitos de autorización, comprobación de propiedad de recursos y prevención de referencias directas inseguras viven en V4. (El territorio corresponde a A01 del Top Ten, que en el ASVS se verifica desde V4.)

Solución 3. Versión ASVS: "El proveedor entregará la aplicación con conformidad verificada al OWASP ASVS Nivel 2 (v4.0.3), demostrada mediante evidencias de cumplimiento por requisito y una verificación por un tercero independiente". Es verificable porque define un estándar concreto, un nivel medible (L2), un método de comprobación (evidencias por requisito) y una validación externa. La petición original ("que sea segura") no es medible: no dice contra qué, hasta qué punto, ni cómo se comprueba, así que nadie puede firmar su cumplimiento.

El ASVS es el estándar de OWASP para verificar la seguridad de una aplicación mediante un catálogo completo de requisitos comprobables, organizados en los capítulos V1–V14 y redactados como afirmaciones con respuesta sí/no/no aplica. Se diferencia del Top Ten en que este último enumera riesgos frecuentes mientras que el ASVS enumera requisitos verificables, y ambos se complementan. Sirve a desarrolladores (guía), testers (guion de pruebas) y compradores (contrato). BazarNube lo adopta para poder medir y demostrar su seguridad ante un cliente que lo exige por contrato.

Pero hemos dejado una pieza pendiente: el ASVS no exige lo mismo a un blog personal que a una plataforma de pagos. Cada requisito está marcado para uno o varios niveles de aseguramiento. En la siguiente lección, 04-02 Niveles de Verificación, veremos qué exigen L1, L2 y L3, cómo elegir el nivel adecuado según la criticidad y los datos que maneja la aplicación, y decidiremos qué nivel objetivo tiene sentido para BazarNube.