OWASP ASVS

Enfoques: caja negra, caja gris y caja blanca

El nivel ASVS dice hasta qué profundidad hay que verificar. El enfoque dice con qué información trabajamos. Son dos decisiones distintas, se toman juntas en el alcance y se combinan sin problema dentro de un mismo proyecto.

Caja negra (black box)

Partimos de lo que tiene quien ataca desde fuera: una URL y nada más. Sin cuentas, sin documentación, sin código. Es la simulación más fiel de un ataque oportunista y, a la vez, la menos rentable en cobertura, porque el tiempo que se va en adivinar qué hay no se dedica a probar. Tiene sentido para un nivel 1, o para medir la superficie realmente expuesta antes de un proyecto más profundo. Frente a un catálogo de requisitos su límite es estructural: todo lo que vive detrás de la autenticación queda sin verificar, y con ello la mayor parte de los capítulos de control de acceso.

Caja gris (grey box)

Trabajamos con una cuenta por rol y con una presentación funcional de la aplicación. Es el enfoque por defecto de una verificación ASVS de nivel 2 y la única manera seria de comprobar la autorización: sin dos cuentas de roles distintos nadie puede demostrar que una persona no llega a los datos de otra. Con el mismo presupuesto cubre bastante más superficie que la caja negra, y da la mejor relación entre cobertura y coste en la gran mayoría de los casos.

Caja blanca (white box)

Añadimos el código fuente, los esquemas de arquitectura, la configuración y, cuando ayuda, conversación directa con tu equipo de desarrollo. Una parte de los requisitos de nivel 3 —calidad del aleatorio, custodia de claves, comprobaciones que de verdad se hacen en el servidor— no se puede dar por cumplida más que leyendo el código. Es el enfoque que impone el nivel 3.

Circula una idea falsa: que la caja negra es más realista y, por tanto, mejor. Es más realista, en efecto, y bastante menos útil. Quien ataca de verdad dispone de semanas; tu proveedor dispone de jornadas. Cada dato que nos das al principio es presupuesto devuelto al test.

Qué obliga realmente en España

Nadie está obligado en España a verificar sus aplicaciones «según el ASVS». Lo que sí obligan varios instrumentos ya en vigor es a probar con regularidad y a documentar con qué metodología se ha probado. Ahí es donde un estándar público de requisitos numerados deja de ser una preferencia técnica y pasa a ser la forma más barata de cumplir.

Conviene decir antes otra cosa con claridad, porque buena parte del mercado lleva dos años vendiendo pentesting con el argumento contrario: NIS2 no está transpuesta en España. El Anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad solo ha pasado una primera lectura en Consejo de Ministros, el 14 de enero de 2025, y no ha llegado a las Cortes. La Comisión Europea llevó a España ante el Tribunal de Justicia de la Unión Europea el 9 de julio de 2026 precisamente por esa falta de transposición, en el procedimiento INFR(2024)0270. Nadie puede sancionarte hoy al amparo de una ley de transposición que todavía no existe.

Lo que sí está en vigor, y sí obliga, es esto:

• Reglamento de Ejecución (UE) 2024/2690. Es de aplicación directa: no necesita transposición y ya rige para las categorías de entidades que cubre. Su Anexo, en el punto 6.5 «Pruebas de seguridad», exige una política de pruebas documentada, un alcance y una periodicidad determinados por riesgo, una metodología y unos resultados documentados, y la corrección de los hallazgos críticos. Un nivel ASVS fijado por escrito y una matriz de cobertura requisito a requisito son, literalmente, esa metodología y esos resultados.
• RGPD, art. 32.1.d). Exige «un proceso de verificación, evaluación y valoración regulares de la eficacia de las medidas técnicas y organizativas para garantizar la seguridad del tratamiento». Un proceso se demuestra con repetición y con una referencia estable; verificar cada año contra el mismo nivel ASVS produce justo esa prueba, cosa que un test suelto sin estándar no consigue.
• ENS, RD 311/2022. El art. 31 impone una auditoría regular ordinaria al menos cada dos años, y el art. 38 separa la autoevaluación de la categoría BÁSICA de la certificación exigida en MEDIA y ALTA. En el Anexo II, el refuerzo [op.mon.3] R6 incluye el subrequisito [op.mon.3.r6.3], titulado literalmente «Pruebas de penetración», exigible en categoría ALTA. Y ya desde BÁSICA, op.nub.1.2 a) pide la «Auditoría de pruebas de penetración (pentesting)» de los servicios cloud de terceros que no sean conformes con el ENS. Una verificación ASVS de la aplicación es la evidencia técnica que se aporta a esa auditoría.
• RDL 12/2018 y RD 43/2021. Trasponen la directiva NIS original y siguen siendo el marco aplicable a operadores de servicios esenciales y proveedores de servicios digitales, con sus obligaciones de auditoría y de análisis de riesgos periódicos.
• DORA, Reglamento (UE) 2022/2554. Se aplica en el sector financiero desde el 17 de enero de 2025. El art. 24 obliga a mantener un programa de pruebas de resiliencia operativa digital —donde encaja una verificación ASVS anual de las aplicaciones de cara al cliente— y el art. 26 añade, para las entidades designadas, ejercicios TLPT al menos cada tres años. Ese segundo ejercicio es otra cosa, con otros requisitos de proveedor; lo aclaramos más abajo.

Hay algo que ningún instrumento español resuelve y el ASVS sí: la unidad de medida. Quien audita puede leer «se han corregido las vulnerabilidades críticas» en veinte informes distintos sin poder compararlos entre sí. Una frase del tipo «cumple todos los requisitos aplicables del nivel 2 salvo tres, documentados y con plazo de corrección» sí se compara con el informe del año pasado y con el de otro proveedor. Esa comparabilidad es la mitad del valor de trabajar contra un estándar.

Nuestro papel es el técnico: ejecutamos las pruebas y documentamos los resultados para que sirvan de evidencia ante quien tenga que valorarlos. Lo que no hacemos está escrito más abajo, con el mismo detalle. Si quieres el desarrollo completo, está en qué exige realmente el ENS sobre pentesting y en NIS2 en España: qué obliga hoy y qué no.

Última verificación: 12 de septiembre de 2026.

Alcance y planificación: qué se acuerda antes de empezar

Una verificación contra un estándar pide un alcance más explícito que un pentest libre, porque al final hay que poder decir, requisito a requisito, qué se ha comprobado y qué no. Antes de enviar el primer paquete dejamos por escrito estas siete cosas, y ninguna de ellas se decide sobre la marcha.

• Nivel ASVS y versión del estándar. Nivel 1, 2 o 3, y la versión contra la que se prueba —por defecto, la última en vigor—. Va en la primera página del informe: un informe que no dice contra qué nivel se ha medido no demuestra nada.
• Objetivos. Qué aplicaciones, qué dominios y subdominios, qué endpoints de API y qué entornos entran, con su URL, su versión y la persona responsable de cada uno.
• Roles y cuentas. Una cuenta por rol, con datos de prueba, para poder comparar permisos entre perfiles. Sin eso, los capítulos de control de acceso —una parte importante de los niveles 2 y 3— no se pueden verificar y hay que declararlos no cubiertos.
• Requisitos no aplicables. Si la aplicación no tiene pagos, ni ficheros subidos por quien la usa, ni federación de identidad, los requisitos correspondientes se descartan de forma explícita y con motivo escrito. Esa decisión se toma al principio y figura en la matriz: nadie descubre al final que un capítulo entero no se miró.
• Exclusiones. Lo que queda fuera se escribe con el mismo detalle que lo que entra: sistemas de terceros, pasarelas de pago, integraciones que no controlas, ataques de denegación de servicio y cualquier prueba capaz de destruir datos.
• Ventana y reglas de actuación (rules of engagement). Fechas y franjas horarias —de 9:00 a 18:00 salvo que pidas otra cosa—, aviso previo a quien opera la plataforma, hasta dónde llegamos si conseguimos acceso, qué hacemos con los datos reales que veamos y a quién llamamos. Un hallazgo crítico se comunica en el momento, no al final.
• Entorno. Producción o preproducción. Si hay un entorno de preproducción representativo, trabajamos ahí; si solo hay producción, las pruebas capaces de degradar el servicio se excluyen o se llevan a una ventana pactada contigo.

En el alcance se fijan también las jornadas, porque el esfuerzo es la variable que decide la cobertura. Una aplicación sencilla con dos roles, en nivel 1, cabe en 5 a 8 jornadas; una aplicación de negocio de tamaño medio, en nivel 2, se mueve entre 8 y 15; un nivel 3 con lectura de código arranca en 15 y sube. La cifra queda escrita en el presupuesto a precio cerrado; si durante el proyecto vemos que se queda corta, te lo decimos antes de consumirla, no después.

Y una regla que aplicamos aunque cueste una venta: entre un nivel 2 cubierto entero y un nivel 3 cubierto a medias, preferimos el primero. Un estándar recorrido a medias no demuestra nada, ni ante un cliente ni ante quien te audita.

El documento de alcance se firma junto con la autorización de pruebas. Sin esa autorización no empezamos: sin ella, el mismo trabajo sería la conducta que describen los arts. 197 bis y 264 del Código Penal.

Tratamiento de datos y soberanía

Una verificación ASVS genera material sensible: capturas, credenciales de prueba, extractos de datos reales, la matriz de cobertura y un informe que describe, paso a paso, cómo entrar en tu aplicación. En nivel 3, además, nos confías el código fuente. Dónde vive ese material y bajo qué jurisdicción es una pregunta legítima del departamento de compras, y merece una respuesta concreta en lugar de una frase de marketing.

Haxoris es una empresa establecida en la Unión Europea, con oficinas en Bratislava y en Praga. Eso tiene tres consecuencias prácticas, y las tres se pueden comprobar en el contrato antes de firmarlo:

• El RGPD se aplica de forma directa, con el mismo texto y bajo autoridades de control europeas. No hace falta una capa contractual que replique garantías: el reglamento ya rige el tratamiento, y actuamos como encargado del tratamiento en el sentido de su art. 28.
• No hay transferencia internacional de datos en el sentido del capítulo V del RGPD, porque el tratamiento no sale del Espacio Económico Europeo. No hacen falta cláusulas contractuales tipo, ni evaluación de impacto de la transferencia, ni el análisis de derecho extranjero que sí exige contratar a un proveedor de fuera de la Unión.
• Ninguna autoridad de un tercer país puede reclamar el material por la vía de su propio derecho interno. La discusión sobre acceso extraterritorial —la CLOUD Act estadounidense es el caso conocido— sencillamente no se plantea.

En el plano operativo: el material del proyecto se cifra en reposo y en tránsito, se conserva el tiempo pactado y se destruye a petición tuya con constancia escrita. El código fuente que nos entregas se trata como información confidencial, con acceso limitado a las personas asignadas al proyecto y acuerdo de confidencialidad firmado a título individual. Esas personas aparecen nombradas en el presupuesto, con sus certificaciones. El informe se entrega cifrado y en español.

Si tu comité de compras nunca ha contratado seguridad ofensiva fuera de España, lo tratamos punto por punto en contratar una empresa de pentesting no española.

Qué no hacemos

Decir dónde está el límite es lo que hace creíble todo lo anterior. Estas seis cosas quedan fuera, y preferimos que lo sepas antes de pedirnos un presupuesto.

• No expedimos ningún «certificado ASVS», porque no existe. El ASVS es un estándar abierto de la OWASP, no un esquema de certificación: no hay organismo que lo certifique ni sello que comprar. Lo que te entregamos es un informe firmado que dice, requisito a requisito, si tu aplicación alcanza el nivel verificado. Si alguien te ofrece «la certificación ASVS», te está ofreciendo algo que no existe.
• No certificamos, en general. Haxoris no es entidad de certificación ni cuenta con acreditación de ENAC, así que no emitimos certificados de conformidad con el ENS, ni el distintivo que los acompaña, ni certificados ISO 27001. Eso lo firma un organismo de certificación acreditado. Lo nuestro es la parte técnica: el informe de pruebas que ese organismo, o quien te audite, te va a pedir como evidencia.
• No somos auditores del ENS. La auditoría del art. 31 y la certificación del art. 38 del RD 311/2022 tienen su propio circuito de entidades habilitadas. Nuestro trabajo alimenta esa auditoría con evidencia técnica; no la sustituye. En quién puede auditar el ENS explicamos quién firma qué.
• No hacemos TLPT. Los ejercicios basados en amenazas del art. 26 de DORA exigen proveedores que cumplan el art. 27 del Reglamento (UE) 2022/2554 y un proceso dirigido por la autoridad competente. Un ejercicio de Red Team nuestro puede servir de preparación previa, pero no lo sustituye y no nos presentamos a ese encargo.
• No trabajamos con información clasificada. El acceso a materia clasificada requiere habilitación de la Oficina Nacional de Seguridad, que no tenemos.
• No tenemos establecimiento en España. Somos un proveedor europeo: firmamos, facturamos y respondemos desde la Unión Europea, y trabajamos en español. Si tu pliego exige un proveedor establecido en España, dínoslo en la primera llamada y te lo diremos claro en lugar de hacerte perder el proceso.