En la lección anterior vimos que cada requisito del ASVS está marcado para uno o varios niveles de aseguramiento. Esa es una de las grandes virtudes del estándar: no exige lo mismo a un blog de recetas que a una pasarela de pagos. El ASVS define tres niveles —L1, L2 y L3— que van sumando rigor. Elegir bien el nivel es la decisión más importante al adoptar el estándar, porque determina cuántos requisitos aplican y con qué profundidad hay que verificarlos. En esta lección entenderemos qué exige cada nivel, cómo elegir el adecuado según la criticidad de la aplicación, y decidiremos con argumentos qué nivel objetivo tiene sentido para BazarNube.

1. Por qué el ASVS tiene niveles
2. Nivel 1 (L1): oportunista / básico
3. Nivel 2 (L2): estándar
4. Nivel 3 (L3): avanzado / crítico
5. Tabla comparativa L1 / L2 / L3
6. Cómo elegir el nivel según criticidad y datos
7. Qué nivel elige BazarNube y por qué

Aplicar los cientos de requisitos del ASVS a toda aplicación por igual sería absurdo: un formulario de contacto estático no necesita el mismo blindaje que un sistema bancario. Los niveles resuelven ese problema graduando la exigencia. Son acumulativos: cada nivel superior incluye todos los requisitos del inferior y añade los suyos.

La idea es sencilla: subir de nivel no cambia de checklist, amplía la existente y aumenta la profundidad con la que hay que verificar cada control.

El Nivel 1 es el mínimo de seguridad que toda aplicación debería alcanzar. Cubre los controles frente a las amenazas más comunes y de menor esfuerzo —el atacante "oportunista" que usa herramientas automáticas y técnicas conocidas sin dedicar recursos especiales.

Características clave:

• Verificable de forma totalmente externa, sin acceso al código fuente ni a la documentación. Se puede comprobar mediante pruebas de caja negra / pentest.
• Protege frente a vulnerabilidades ampliamente conocidas (buena parte del Top Ten se cubre aquí).
• Es el suelo, no el objetivo, para casi cualquier aplicación que maneje datos de usuarios.

Ejemplos de exigencias típicas de L1:

• Existe control de acceso y las funciones sensibles requieren autenticación.
• Las contraseñas tienen una longitud mínima y no son las de una lista de comprometidas.
• La aplicación codifica la salida para prevenir XSS.
• El tráfico va sobre TLS.

Aplicaciones típicas L1: sitios de bajo riesgo, aplicaciones internas sin datos sensibles, o como paso previo de madurez antes de alcanzar L2.

El Nivel 2 es el recomendado para la mayoría de las aplicaciones, especialmente las que manejan datos personales, transacciones o información de negocio significativa. Defiende frente a atacantes hábiles y motivados que usan herramientas y técnicas avanzadas de forma dirigida.

Características clave:

• Requiere acceso a documentación, diseño y código fuente para verificarse correctamente (no basta caja negra). Se combina revisión de código con pruebas.
• Añade controles de defensa en profundidad: gestión de sesiones robusta, control de acceso a nivel de objeto, criptografía bien aplicada, logging de eventos de seguridad, validación exhaustiva.
• Es el nivel que suelen exigir clientes enterprise, normativas de protección de datos y auditorías serias.

Ejemplos de exigencias que L2 añade sobre L1:

• Verificación de propiedad del recurso en cada acceso (evita IDOR de forma sistemática).
• Datos sensibles cifrados en reposo con gestión de claves adecuada.
• Registro de eventos de seguridad relevantes con protección frente a manipulación.
• Anti-automatización y protección frente a credential stuffing.

Aplicaciones típicas L2: comercio electrónico, SaaS B2B, aplicaciones con datos personales o de pago. Aquí encaja BazarNube.

El Nivel 3 es el más alto y se reserva para aplicaciones críticas: aquellas cuyo compromiso tendría consecuencias graves para la vida, la seguridad nacional, grandes volúmenes económicos o infraestructuras esenciales.

Características clave:

• Exige el máximo rigor: revisión de código exhaustiva, análisis de arquitectura, modelado de amenazas documentado y defensa en profundidad en todas las capas.
• Requiere justificar el diseño de seguridad, no solo que los controles existan: hay que demostrar que la arquitectura es resistente.
• El esfuerzo de verificación es sustancialmente mayor; se aplica solo cuando el riesgo lo justifica.

Ejemplos de exigencias que L3 añade sobre L2:

• Segregación estricta de componentes y confianza mínima entre módulos.
• Verificación de que existe modelado de amenazas y de que el diseño lo refleja.
• Controles criptográficos avanzados y gestión de claves de máximo nivel.
• Trazabilidad y logging aptos para análisis forense completo.

Aplicaciones típicas L3: banca core, salud, sistemas militares, infraestructuras críticas, plataformas que procesan grandes volúmenes de pagos como núcleo del negocio.

La elección del nivel no es una preferencia estética: se deriva del riesgo, que depende de qué datos se manejan y qué pasaría si se comprometieran. Un procedimiento práctico:

1. Inventaría los datos y funciones sensibles. ¿Hay datos personales? ¿Medios de pago? ¿Historiales médicos? ¿Dinero real moviéndose?
2. Estima el impacto de un compromiso. ¿Molestia, pérdida económica moderada, daño grave a personas o al negocio?
3. Considera obligaciones externas. Normativa (RGPD, PCI-DSS), exigencias contractuales de clientes, sector regulado.
4. Mapea a nivel:

Un antipatrón habitual es "aspirar a L3 porque suena más seguro". L3 tiene un coste de verificación muy alto y solo se justifica cuando el riesgo lo exige; sobredimensionar el nivel consume recursos que estarían mejor invertidos en cumplir bien el nivel correcto.

Apliquemos el procedimiento a BazarNube:

1. Datos que maneja: cuentas de usuario, direcciones, historial de compras y, sobre todo, datos de pago y datos personales de compradores y vendedores del marketplace.
2. Impacto de un compromiso: fraude económico, filtración de datos personales (con sanción RGPD), pérdida de confianza y del contrato con el cliente enterprise.
3. Obligaciones externas: el cliente corporativo exige conformidad demostrable; el tratamiento de pagos acerca a exigencias tipo PCI-DSS; el RGPD aplica por los datos personales.
4. Pero no es banca core ni infraestructura crítica que ponga vidas en juego.

La conclusión del equipo es clara:

BazarNube adopta ASVS Nivel 2 (L2) como objetivo.

Razonamiento que Lucía documenta en el backlog:

• L1 se queda corto: maneja pagos y datos personales; el suelo básico no cubre sus riesgos ni satisface al cliente enterprise.
• L3 es sobredimensionado: no es un sistema donde un fallo cueste vidas ni un banco core; el coste de verificación L3 no está justificado por el riesgo real.
• L2 es el punto correcto: exige defensa en profundidad, verificación con código y diseño, control de acceso a nivel de objeto, criptografía y logging robustos —justo lo que un marketplace con pagos necesita— y es el nivel que clientes y auditores esperan.

Se deja la puerta abierta a elevar puntualmente ciertos módulos (por ejemplo, el subsistema de pagos) a exigencias de L3, sin llevar toda la aplicación a ese nivel. Esta idea de "L2 general con refuerzos selectivos" es una estrategia madura y realista.

• Elegir el nivel por ambición y no por riesgo. "Vamos a por L3" sin justificarlo dispara el coste y ralentiza sin aportar seguridad proporcional.
• Creer que L1 se verifica igual que L2. L1 admite caja negra; L2 y L3 exigen acceso a código y diseño. Prometer L2 con solo un pentest de caja negra es incumplir el método.
• Olvidar que los niveles son acumulativos. L2 incluye todos los requisitos L1; no se "salta" el nivel inferior.
• Aplicar un único nivel a un sistema muy heterogéneo. Es válido fijar L2 general y reforzar a L3 los componentes más críticos (como pagos).
• Consejo: documenta por qué eliges el nivel (datos, impacto, obligaciones). Esa justificación es la primera evidencia que pedirá un auditor.

Ejercicio 1. Una startup lanza una web informativa sin cuentas de usuario ni datos personales, solo contenido público. ¿Qué nivel ASVS le recomendarías y por qué? ¿Qué método de verificación bastaría?

Ejercicio 2. Justifica en 3–4 frases, como si lo escribieras en el backlog de BazarNube, por qué L2 es más adecuado que L3 para el marketplace pese a manejar pagos.

Ejercicio 3. El equipo de pagos de BazarNube propone: "todo el marketplace a L3 para estar seguros". Rebate o matiza la propuesta proponiendo una alternativa más eficiente.

Solución 1. Nivel 1 (L1). No maneja datos personales ni sensibles y el impacto de un compromiso es bajo (a lo sumo defacement del contenido público). El suelo básico frente a atacantes oportunistas es proporcional al riesgo. Al ser L1, bastaría una verificación de caja negra / pentest sin necesidad de acceso al código, aunque revisarlo siempre es deseable.

Solución 2. "BazarNube maneja datos personales y de pago, así que L1 no cubre sus riesgos ni satisface al cliente enterprise. Sin embargo, no es banca core ni infraestructura crítica con impacto sobre vidas, por lo que L3 —con su coste de threat modeling exhaustivo y verificación de arquitectura— está sobredimensionado. L2 exige defensa en profundidad, control de acceso por objeto, criptografía y logging robustos verificados con código y diseño, que es justo el nivel de rigor que un marketplace con pagos necesita y que auditores y clientes esperan."

Solución 3. Llevar todo el marketplace a L3 dispara enormemente el coste de verificación (revisión exhaustiva de arquitectura, threat modeling documentado de cada componente) sin que la mayoría de módulos (catálogo, reseñas, perfil) lo justifiquen por su riesgo. Alternativa más eficiente: fijar L2 como objetivo general y reforzar selectivamente a exigencias de L3 solo el subsistema de pagos, que es donde el impacto de un fallo es mayor. Se obtiene el blindaje donde importa sin pagar el coste L3 en toda la aplicación.

El ASVS gradúa su exigencia en tres niveles acumulativos: L1 (básico, frente a atacantes oportunistas, verificable en caja negra), L2 (estándar, para la mayoría de apps con datos, verificable con código y diseño) y L3 (avanzado, para sistemas críticos, con threat modeling y revisión de arquitectura). El nivel se elige por riesgo: qué datos se manejan y qué impacto tendría su compromiso. BazarNube adopta L2 por manejar pagos y datos personales sin ser un sistema crítico, con la opción de reforzar puntualmente el módulo de pagos.

Ya sabemos qué estándar usamos y a qué nivel aspiramos. Toca ahora abrir el catálogo y ver los requisitos concretos. En la siguiente lección, 04-03 Requisitos de Seguridad, recorreremos los capítulos más relevantes (autenticación, sesiones, control de acceso, validación, criptografía, logging...), aprenderemos a leer un requisito verificable y mapearemos los hallazgos del Top Ten de BazarNube a requisitos ASVS concretos.