La lección anterior terminó con una pregunta incómoda: el Top Ten conciencia sobre qué riesgos existen, pero no sirve para demostrar que una aplicación es segura. Cuando Lucía tiene que responder a un cliente corporativo que exige "garantías de seguridad" en el contrato de BazarNube, o cuando quiere darle a un pentester una lista clara de qué comprobar, el Top Ten se queda corto. Necesita algo distinto: no una lista de peligros, sino una lista de requisitos verificables. Esa es la segunda herramienta de nuestra caja: OWASP ASVS, el Application Security Verification Standard. En esta lección la presentamos a alto nivel; el detalle —niveles, requisitos concretos, cómo implementarlo— es el contenido del módulo 4.

1. Qué es ASVS
2. ASVS frente al Top Ten: requisitos vs riesgos
3. Los tres niveles de verificación (visión general)
4. Casos de uso: checklist, contratos y pentests
5. Cómo usaría ASVS el equipo de BazarNube

El OWASP ASVS (Application Security Verification Standard) es un estándar de requisitos de seguridad verificables para aplicaciones web. Dicho en simple: es una lista organizada de "cosas que la aplicación debe cumplir", redactadas de forma que se puedan comprobar una por una (verificar si se cumplen o no).

Sus rasgos esenciales:

• Es un estándar, no un documento de concienciación. Mientras el Top Ten dice "cuidado con la inyección", ASVS dice algo comprobable como "toda consulta a base de datos debe usar consultas parametrizadas".
• Está organizado por capítulos temáticos (autenticación, control de acceso, validación de entrada, criptografía, gestión de sesiones, etc.), no por "top de riesgos".
• Cada requisito es una afirmación verificable, pensada para responder con un sí/no y una evidencia. Esto lo hace ideal para auditorías, checklists y contratos.
• Se estructura en niveles (L1, L2, L3) según cuánta seguridad necesita la aplicación.

La palabra que resume ASVS es verificación. No pregunta "¿conoces este riesgo?", sino "¿puedes demostrar que lo has mitigado?".

Este es el punto clave de la lección. Top Ten y ASVS no compiten: son complementarios y operan en planos distintos. Confundirlos es un error común.

Una forma intuitiva de verlo:

Analogía útil: el Top Ten es como el folleto de "los diez accidentes domésticos más comunes"; ASVS es como la inspección técnica con su lista de puntos a comprobar (¿la instalación eléctrica cumple?, ¿hay detector de humos?, ¿el gas está revisado?). Lo primero te conciencia; lo segundo te permite firmar que la casa es habitable.

No toda aplicación necesita el mismo grado de seguridad: no es lo mismo un blog personal que la pasarela de pagos de BazarNube. Por eso ASVS define tres niveles de exigencia crecientes. Aquí solo los presentamos; el módulo 4 explica qué requisitos concretos entran en cada uno.

Ideas que conviene fijar ya, sin entrar en detalle:

• Los niveles son acumulativos: L2 incluye todo lo de L1, y L3 incluye todo lo de L2.
• El nivel se elige según el riesgo del negocio y los datos que maneja la aplicación, no por capricho.
• Para un marketplace que procesa pagos y datos personales como BazarNube, el objetivo razonable suele ser L2. L3 se reserva para lo más crítico.

¿Para qué sirve ASVS en el día a día? Sus tres usos más habituales:

1. Como checklist de verificación de seguridad. El equipo repasa los requisitos aplicables y marca cuáles cumple BazarNube, cuáles no y cuáles no aplican. El resultado es un inventario objetivo del estado de seguridad, mucho más útil que "creemos que estamos bien".
2. Como base para contratos y requisitos. Cuando BazarNube contrata un desarrollo externo, o cuando un cliente le exige garantías, se puede escribir en el contrato "la aplicación cumplirá ASVS nivel 2". Eso convierte una exigencia vaga ("que sea seguro") en un compromiso medible y auditable.
3. Como guion para pentests y auditorías. En lugar de que cada pentester improvise, ASVS ofrece un alcance común: "verifica estos requisitos del capítulo de autenticación y control de acceso". Los informes salen estructurados y comparables entre auditorías.

Apliquémoslo. El backlog de hallazgos que empezamos a etiquetar con el Top Ten es bueno para detectar problemas, pero no para demostrar que estamos completos. Aquí entra ASVS. El equipo daría estos pasos (que el módulo 4 desarrolla):

1. Elegir el nivel objetivo. Como BazarNube maneja pagos y datos personales, fijan ASVS L2 como meta. Lo anotan como decisión de arquitectura.
2. Convertir requisitos en tareas verificables. Cada requisito ASVS aplicable se convierte en una comprobación concreta sobre la app. Veamos cómo se ve, de forma simplificada, esa traducción:

Fíjate en la potencia de este formato frente al Top Ten:

• Cada línea es una afirmación comprobable con un veredicto (CUMPLE / NO CUMPLE / REVISAR).
• Cada incumplimiento enlaza con un hallazgo del backlog, que a su vez lleva su etiqueta Top Ten (A01, A03, A07...). Así, Top Ten y ASVS se refuerzan: el Top Ten nombra el riesgo, ASVS lo verifica.
• El conjunto da una foto objetiva y presentable a dirección o a un cliente: "cumplimos el 82% de los requisitos L2, estos son los pendientes".

3. Usar la checklist como puente hacia el pentest. Cuando contraten un pentest o usen ZAP (lección 02-04), el alcance ya está definido por los requisitos ASVS marcados como "REVISAR" o "NO CUMPLE".

En resumen: ASVS le da a BazarNube el lenguaje para pasar de "conocemos los riesgos" a "podemos demostrar, requisito a requisito, dónde estamos".

• Confundir ASVS con el Top Ten. No son intercambiables: el Top Ten conciencia (riesgos), ASVS verifica (requisitos). Se usan juntos, no uno en lugar del otro.
• Elegir L3 "por ser el más seguro". Apuntar a un nivel superior al que necesitas genera un coste enorme y requisitos que no aportan a tu riesgo real. Elige el nivel por el valor de los datos, no por perfeccionismo. Para BazarNube, L2 es la meta sensata.
• Tratar ASVS como todo-o-nada. No hace falta cumplir el 100% de golpe. La checklist sirve precisamente para ir midiendo el avance y priorizar.
• Verificar solo en la interfaz. Muchos requisitos (especialmente L2/L3) exigen mirar el código y el diseño, no solo probar la app desde fuera. Verificar únicamente la UI da falsa tranquilidad.
• Consejo: empieza por los capítulos de control de acceso y autenticación. Suelen ser donde más incumplimientos aparecen y donde más impacto tiene arreglarlos.

Ejercicio 1. Para cada frase, indica si corresponde al Top Ten o a ASVS: (a) "El sistema debe invalidar la sesión del lado del servidor al cerrar sesión"; (b) "Uno de los riesgos más críticos es el control de acceso roto"; (c) "La aplicación cumplirá el nivel L2 según auditoría externa".

Ejercicio 2. BazarNube maneja pagos y datos personales, pero no es un banco. Argumenta en 3–4 líneas qué nivel ASVS sería el objetivo razonable y por qué no L1 ni L3.

Ejercicio 3. Explica cómo se complementan Top Ten y ASVS en el flujo de trabajo de BazarNube, usando un ejemplo concreto de hallazgo que pase por ambos.

Solución 1. (a) ASVS (es un requisito verificable, concreto y comprobable); (b) Top Ten (es una afirmación de concienciación sobre un riesgo, corresponde a A01); (c) ASVS (habla de cumplir un nivel de verificación, propio del estándar).

Solución 2. El objetivo razonable es L2. L1 es un mínimo pensado para apps de bajo riesgo, insuficiente para quien procesa pagos y datos personales (exposición a GDPR/PCI-DSS). L3 está reservado a sistemas de valor extremo (banca central, infraestructuras críticas, salud) y supone un coste de verificación desproporcionado para un marketplace joven. L2 cubre el riesgo real de BazarNube sin sobrecargar al equipo.

Solución 3. Ejemplo: durante la autoevaluación ASVS, el requisito "cada endpoint verifica autorización en el servidor" aparece como NO CUMPLE. Ese incumplimiento se registra en el backlog como un hallazgo y se etiqueta con Top Ten como A01 (Broken Access Control). Así, el Top Ten aporta el nombre y la categoría del riesgo (comunicación y priorización), mientras que ASVS aporta el requisito verificable y la evidencia de que estaba incumplido (auditoría y demostración). Uno conciencia, el otro verifica; juntos cierran el ciclo.

Has conocido la segunda herramienta de la caja OWASP: ASVS, un estándar de requisitos verificables que responde a lo que el Top Ten no puede: demostrar el estado de seguridad de una aplicación. Sabes que se diferencia del Top Ten en el plano (requisitos vs riesgos), que define tres niveles (L1, L2, L3) según el valor de la aplicación, y que se usa como checklist, base contractual y guion de pentests. Y has visto cómo BazarNube apuntaría a L2, convirtiendo su backlog en una checklist verificable enlazada con las etiquetas del Top Ten.

Con Top Ten y ASVS tenemos herramientas centradas en la aplicación: sus riesgos y sus requisitos. Pero surge una pregunta de nivel superior: ¿está la organización BazarNube preparada, como equipo y como proceso, para producir software seguro de forma sostenida? Eso ya no se mide sobre una app, sino sobre la propia organización. Es el terreno de la siguiente herramienta: en la lección 02-03 presentamos OWASP SAMM, el modelo de madurez del programa de seguridad.