Llegamos a la lección que cierra el módulo. Ya tenemos el estándar (ASVS), el nivel objetivo (L2) y una checklist mapeada desde los hallazgos del Top Ten de BazarNube. Nada de eso sirve si se queda en un documento. En esta lección veremos cómo integrar el ASVS en el ciclo de vida real de un proyecto: usar la checklist como criterios de aceptación y definición de hecho, decidir qué se verifica manual y qué automáticamente, dejar evidencias trazables, y llevar el ASVS a contratos y pentests. Terminaremos con un plan práctico paso a paso para el backlog de BazarNube y con la conexión hacia el módulo 5.

1. De la checklist al proceso: dónde encaja ASVS en el SDLC
2. ASVS como criterios de aceptación y definición de hecho
3. Verificación manual vs. automatizada
4. Evidencias y trazabilidad
5. ASVS en contratos y pentests
6. Plan práctico paso a paso para BazarNube
7. Del proyecto a la organización: puente hacia SAMM

El error más común es tratar el ASVS como una auditoría de última hora. Su valor real aparece cuando se distribuye a lo largo del ciclo de desarrollo: los requisitos guían el diseño, condicionan la implementación y se verifican de forma continua, no solo al final.

La idea: cada requisito ASVS relevante para una funcionalidad se selecciona en diseño, se implementa como control, se verifica antes de dar la tarea por terminada y deja una evidencia. El cumplimiento se acumula release a release hasta alcanzar el nivel objetivo (L2).

La forma más efectiva de "meter" el ASVS en el día a día de un equipo ágil es convertir los requisitos en criterios de aceptación de las historias de usuario y en parte de la Definición de Hecho (DoD).

Ejemplo aplicado a una historia de BazarNube:

Y una Definición de Hecho reforzada con ASVS para todo el equipo:

• El código pasa los tests, incluidos los de seguridad de los requisitos ASVS asociados.
• Los requisitos L2 aplicables a la funcionalidad están verificados y con evidencia.
• No se introducen secretos en el repositorio (V6.4.1) — comprobado por el escáner de CI.

Así, la seguridad deja de ser una fase separada y se convierte en una condición para dar por terminada cualquier tarea.

No todos los requisitos se comprueban igual. Una estrategia madura combina ambos enfoques y sabe cuál toca a cada requisito.

Reglas prácticas:

• Automatiza lo mecánico: dependencias vulnerables (SCA), secretos en el repo (secret scanning), configuración TLS y cabeceras, patrones de inyección (SAST). Se ejecuta en cada commit/CI.
• Reserva la verificación manual para lo que exige juicio: autorización a nivel de objeto en flujos complejos, modelado de amenazas, abuso de lógica de negocio. Aquí la revisión de código y las pruebas dirigidas son insustituibles.
• La herramienta ZAP (que veremos en el módulo 6) ayuda a automatizar parte de la verificación dinámica; aquí basta con saber que existe y que se integra en este flujo. No la usamos todavía.

Un antipatrón: creer que un escáner "verifica el ASVS". Los escáneres cubren un subconjunto de requisitos objetivos; el resto exige criterio humano. El ASVS L2 no se alcanza solo con herramientas.

Un requisito "verificado" sin evidencia no vale ante un auditor. Cada resultado debe ser trazable: quién lo verificó, cómo, cuándo y con qué prueba. Un formato sencillo y suficiente:

Esta tabla, mantenida por requisito, es el artefacto de conformidad: muestra el porcentaje de cumplimiento por nivel y sirve directamente como entregable de auditoría. Conviene versionarla junto al código para que evolucione con el producto y refleje siempre el estado real.

El ASVS brilla como lenguaje común entre partes:

• En contratos: en lugar de exigir "una aplicación segura", se especifica "conformidad verificada con OWASP ASVS Nivel 2 (v4.0.3), con evidencias por requisito y verificación por un tercero". Es medible, exigible y auditable —justo lo que el cliente enterprise de BazarNube pide.
• En pentests: en lugar de un pentest de alcance difuso, se encarga "verificación de conformidad ASVS L2". El pentester usa la lista de requisitos como guion; el informe se estructura por requisito (cumple/no cumple) en vez de por hallazgos sueltos. Los resultados se pueden comparar entre auditorías y en el tiempo.
• Como criterio de aceptación de proveedores: si BazarNube integra un servicio de terceros, puede exigirle un nivel ASVS y pedir su tabla de evidencias.

Esto cierra el círculo del módulo: el ASVS no solo mejora la app, también profesionaliza cómo se contrata, audita y demuestra la seguridad.

Reunamos todo en un plan accionable que BazarNube puede ejecutar sobre su backlog:

1. Fijar el objetivo: ASVS L2 para toda la aplicación; considerar exigencias de L3 solo para el subsistema de pagos (decidido en 04-02).
2. Partir del mapeo: tomar la tabla "hallazgos Top Ten → requisitos ASVS" de la lección 04-03 como checklist inicial por capítulos.
3. Priorizar: ordenar por riesgo y por esfuerzo. Primero los requisitos que cubren hallazgos ya explotables (IDOR V4.2.1, inyección V5.3.4, secretos V6.4.1).
4. Convertir en trabajo: cada requisito pendiente entra como criterio de aceptación de una historia y forma parte de la Definición de Hecho.
5. Automatizar lo mecánico: montar en CI el SCA (V14.2.1), el escáner de secretos (V6.4.1) y las comprobaciones de TLS/cabeceras (V9.1.1, V14.4.1).
6. Verificar manualmente lo que exige juicio: revisión de código para autorización (V4), threat modeling del checkout (V1), abuso de lógica de negocio (V11).
7. Registrar evidencias: mantener la tabla de trazabilidad por requisito, versionada con el repo.
8. Medir el avance: calcular el porcentaje de cumplimiento L2 en cada release; el objetivo del gate de despliegue es no regresar.
9. Preparar la auditoría externa: entregar la tabla de evidencias al pentester/cliente como base de la verificación L2 contratada.

Con este plan, el backlog de BazarNube deja de ser una lista de miedos y pasa a ser un programa de verificación medible, con estado conocido y demostrable en cada release.

Hemos conseguido algo importante: BazarNube ya sabe verificar su aplicación contra un catálogo completo de requisitos, por niveles, con evidencias. Pero fijémonos en una limitación de fondo. Todo lo que hemos hecho responde a la pregunta "¿es segura esta aplicación?". Queda una pregunta más grande sin responder:

"¿Es capaz nuestra organización de producir aplicaciones seguras de forma repetible, y de mejorar esa capacidad con el tiempo?"

El ASVS verifica el producto; no mide si el equipo tiene buenos procesos de formación, de gestión de proveedores, de respuesta a incidentes o de mejora continua. Una empresa podría pasar una auditoría L2 hoy y, sin madurez de proceso detrás, volver a acumular deuda de seguridad en el siguiente proyecto. Verificar la app es necesario pero no suficiente: hace falta madurar el programa de seguridad de la organización.

Ese es exactamente el salto del próximo módulo. En el módulo 5, OWASP SAMM (Software Assurance Maturity Model), dejaremos de mirar la aplicación para mirar la organización: cómo evaluar la madurez de las prácticas de seguridad por dominios, cómo situarse en una escala y cómo diseñar un plan de mejora continua. Pasamos de "sé verificar mi app por niveles" (ASVS) a "sé medir y hacer crecer la capacidad de seguridad de mi equipo" (SAMM).

• Verificar el ASVS solo al final. Aplicarlo como auditoría tardía dispara el coste de las correcciones; su valor está en distribuirlo por el SDLC como criterios de aceptación.
• Creer que un escáner "cumple el ASVS". Las herramientas cubren un subconjunto objetivo; los requisitos de diseño, autorización compleja y lógica de negocio exigen verificación manual.
• Marcar requisitos como "cumple" sin evidencia. Sin trazabilidad (método, prueba, fecha, responsable) no hay conformidad demostrable ante un auditor.
• Tratar el ASVS como un examen puntual. Es un estado que se mantiene release a release; sin un gate que evite regresiones, el cumplimiento se erosiona.
• Confundir verificar la app con madurar la organización. El ASVS mide el producto; la madurez de proceso es territorio de SAMM (módulo 5).
• Consejo: empieza pequeño y visible. Automatiza tres o cuatro requisitos mecánicos en CI y muestra la tabla de evidencias; el impulso inicial facilita adoptar el resto.

Ejercicio 1. Clasifica estos requisitos en "verificación automatizable en CI" o "verificación manual" y justifica: (a) V14.2.1 dependencias con CVE, (b) V4.2.1 propiedad del recurso en un flujo de reembolsos complejo, (c) V6.4.1 secretos en el repositorio, (d) V1.1.x existencia de threat modeling.

Ejercicio 2. Escribe un criterio de aceptación de seguridad, estilo ASVS L2, para la historia de BazarNube "Como usuario quiero cambiar mi contraseña". Incluye al menos dos requisitos con su identificador.

Ejercicio 3. El cliente enterprise pide "pruebas de que BazarNube es conforme a ASVS L2". Enumera tres artefactos concretos que entregarías y explica qué demuestra cada uno.

Solución 1. (a) Automatizable: un SCA en CI detecta dependencias con CVE de forma objetiva y repetible. (b) Manual: aunque la comprobación de propiedad es objetiva, un flujo de reembolsos complejo tiene ramas y estados que exigen revisión de código y pruebas dirigidas; un escáner no entiende la lógica de negocio. (c) Automatizable: un secret scanner en CI encuentra secretos por patrón sin intervención humana. (d) Manual: la existencia y calidad de un threat model es un artefacto de diseño que se revisa a mano; no hay herramienta que lo "detecte".

Solución 2. "Criterios de aceptación (seguridad, ASVS L2): [V2.1.1] la nueva contraseña tiene al menos 12 caracteres; [V2.1.7] se rechaza si aparece en listas de contraseñas filtradas; [V3.3.1] tras el cambio se invalidan las demás sesiones activas del usuario. Verificado con tests que cubren contraseña corta, contraseña filtrada y continuidad de sesión antigua." (Basta con incluir dos; aquí se muestran tres para ilustrar.)

Solución 3. (1) Tabla de evidencias por requisito (estado, método, prueba, fecha, responsable): demuestra el porcentaje de cumplimiento L2 y cómo se verificó cada requisito. (2) Informe de un pentest/verificación externa estructurado por requisitos ASVS L2: aporta validación independiente de que los controles funcionan. (3) Salidas de CI de las verificaciones automatizadas (SCA sin CVE, secret scanning a cero, checks de TLS y cabeceras): demuestran que los requisitos mecánicos se comprueban de forma continua y no puntual. Juntos cubren evidencia interna, validación externa y control continuo.

Implementar el ASVS es integrarlo en el ciclo de vida, no auditarlo al final: los requisitos se convierten en criterios de aceptación y en la Definición de Hecho, se verifican combinando automatización (dependencias, secretos, TLS, cabeceras) y revisión manual (autorización compleja, threat modeling, lógica de negocio), y cada resultado deja una evidencia trazable. Ese conjunto de evidencias es lo que permite llevar el ASVS a contratos y pentests con un lenguaje medible. Con el plan paso a paso, el backlog de BazarNube se transforma en un programa de verificación L2 demostrable release a release.

Con esto cerramos el módulo 4: BazarNube ya sabe verificar su aplicación contra un catálogo completo de requisitos, por niveles y con evidencias. Pero verificar el producto no garantiza que la organización sepa producir software seguro de forma repetible y mejorar con el tiempo. Ese es el salto del módulo 5, OWASP SAMM: pasar de verificar la aplicación a medir y madurar el programa de seguridad de la organización por dominios y niveles de madurez. Nos vemos allí.