OWASP
El Top 10 es la puerta de entrada, y el ASVS, el estándar de verificación de seguridad de aplicaciones, es lo que convierte el pedido genérico de hacer una prueba de seguridad en un requisito verificable, con veredicto por ítem. Quien contrata pruebas sin citar esa regla en el contrato recibe informes que no se comparan entre proveedores, y queda sin saber cuál de los dos probó más.
OWASP, Open Worldwide Application Security Project, es una fundación sin fines de lucro, y todo su material es abierto y gratuito. DM11 usa ese material como base metodológica de las pruebas de aplicación, escribe contigo el requisito de seguridad que va al contrato con el proveedor de software, y mide el proceso de desarrollo contra el SAMM. Cuando el destino es una certificación, la evidencia producida aquí entra entera en ese proyecto, y la página de la norma elegida explica el resto del camino.
Quién conduce las pruebas
CEH, Certified Ethical Hacker por EC-Council
CPTE, Certified Penetration Testing Expert por AcadiTI
SYCP y SYES, pentest y evasión por Solyd
17 años de gobernanza, riesgos y cumplimiento
QUÉ ES
OWASP publica las referencias de seguridad de aplicaciones más usadas del mundo, todas gratuitas. La más conocida es el Top 10 de aplicación web, hoy en la edición 2025, la primera revisión desde 2021. Junto a él están el ASVS, que es la lista de requisitos verificables, el Top 10 de seguridad de API, la interfaz por la que tus sistemas conversan entre sí, el MAS, de seguridad de aplicación móvil, el Top 10 para aplicaciones con modelo de lenguaje y el SAMM, que mide la madurez del proceso de desarrollo. El Top 10 es por donde entra casi todo el mundo, y por sí solo no responde si una aplicación pasó.
La ruptura del control de acceso sigue en primer lugar, como en 2021. La configuración incorrecta de seguridad subió del quinto al segundo puesto. Dos categorías son nuevas: fallas en la cadena de suministro de software, que amplía lo que en 2021 trataba solo de componente vulnerable y desactualizado, y manejo inadecuado de condiciones excepcionales, que cubre el error mal tratado y el control que falla abriendo en vez de cerrando. La edición analizó 589 CWEs, el catálogo público de categorías de debilidad de software, sobre datos de más de 2,8 millones de aplicaciones y con trece organizaciones contribuyentes: ocho categorías salieron del dato y dos de la encuesta a la comunidad.
El Application Security Verification Standard llegó a la versión 5.0 en mayo de 2025, con cerca de 350 requisitos en 17 capítulos y tres niveles de verificación, del L1 al L3. La diferencia práctica está en la forma: cada requisito termina en cumple o no cumple, y por eso cabe dentro de un contrato, de un criterio de aceptación y de un informe de prueba. Responde la pregunta que el Top 10 deja abierta, que es qué exactamente debe cumplir tu aplicación para que alguien afirme que fue verificada.
Conviene alinear la expectativa temprano, porque cambia la planificación. Lo que el trabajo produce es un informe de verificación con alcance declarado, nivel de ASVS pretendido, veredicto requisito por requisito y evidencia adjunta, incluidos los requisitos que no se aplican a tu caso y el motivo. La propia fundación es explícita al respecto en el texto del ASVS: no certifica proveedores, verificadores ni software, y recomienda cautela con sellos de terceros presentados como certificación OWASP oficial. Cuando tu cliente necesita un documento emitido por un organismo acreditado, quien responde es ISO 27001 o SOC 2, y la prueba hecha aquí entra como evidencia técnica en ese proyecto.
El Top 10 de API, en la edición 2023, trata de lo que la lista web no alcanza, como autorización a nivel de objeto y de propiedad, consumo irrestricto de recursos e inventario de endpoints. El MAS, Mobile Application Security, cubre la aplicación móvil con dos documentos que trabajan juntos: el MASVS en la versión 2.1.0, con ocho dominios que van de almacenamiento y criptografía a privacidad y resistencia a la ingeniería inversa, y el MASTG en la versión 2.0.0, con las pruebas correspondientes a cada dominio. El Top 10 para aplicaciones con modelo de lenguaje, edición 2025, es hoy la referencia de seguridad en IA generativa, con la inyección de prompt en primer lugar. Y el SAMM, Software Assurance Maturity Model, en la versión 2, mide el proceso en cinco funciones de negocio y quince prácticas, con tres niveles de madurez en cada una.
QUIÉN SUELE NECESITARLO
En ninguna de ellas hay alguien exigiendo un certificado. Lo que está en juego es poder comparar proveedores, responder a un cliente con método, o probar una superficie que la prueba tradicional no alcanza.
La empresa terceriza el desarrollo, el contrato habla de plazo, alcance funcional y garantía, y la palabra seguridad aparece una vez, en un párrafo genérico. Sin requisito escrito, reclamar una corrección después se vuelve una negociación comercial en lugar de la ejecución de un contrato. El ASVS resuelve eso porque cada requisito tiene veredicto, y un anexo con nivel declarado es exigible.
Quien vende software recibe due diligence con preguntas directas sobre el Top 10, sobre pruebas de aplicación y sobre la corrección de hallazgos. Responder de memoria cuesta credibilidad apenas alguien pide evidencia. Un informe de verificación con alcance y nivel declarados responde la mayor parte del cuestionario, y responde igual para el próximo cliente que pregunte.
La empresa puso un asistente con modelo de lenguaje a conversar con clientes o con una base interna, y la prueba tradicional sigue mirando la aplicación a su alrededor. Inyección de prompt, filtración del prompt de sistema y agencia excesiva de herramientas quedan fuera de ese alcance, y son exactamente los ítems que organiza el Top 10 para aplicaciones con modelo de lenguaje.
HISTORIAS
Cambiamos los nombres de los clientes con el mismo sigilo que protegerá a tu empresa después. Los nombres cambian, el patrón de los problemas se repite. Cuando el cliente lo autoriza, damos referencias con nombre en una conversación.
Software como servicio
Había una prueba anual de aplicación web, con informe limpio, y el equipo confiaba en él. La aplicación móvil conversaba con una API que nunca figuró en ningún alcance, porque el pedido histórico decía solamente prueba del sitio. El producto había crecido por el celular, y la mayor parte del tráfico ya pasaba por ahí.
Rehicimos el alcance a partir del inventario de aplicaciones, dejando de lado el texto del pedido histórico, e incluimos la API y la aplicación móvil. Probamos la API contra el Top 10 de API y verificamos los requisitos de autorización del ASVS con credenciales de dos clientes distintos, que es lo que revela un problema de autorización a nivel de objeto.
Cambiar el identificador de un recurso devolvía datos de otro cliente, sin verificación alguna de pertenencia. La corrección fue barata porque la autorización ya existía en la capa web y faltaba en la API. El cambio que quedó fue de proceso: el alcance pasó a salir del inventario de aplicaciones, revisado cada trimestre.
Comercio minorista y electrónico
El desarrollo estaba todo tercerizado y el contrato no traía requisitos de seguridad. Cada hallazgo de prueba abría una discusión sobre quién pagaba la corrección, y el equipo interno perdía más tiempo negociando que corrigiendo. Ninguna entrega tenía criterio de aceptación ligado a seguridad.
Elegimos el nivel 2 del ASVS como objetivo, seleccionamos los requisitos aplicables a ese tipo de aplicación y los escribimos en un anexo contractual, incluida la exigencia de evidencia por requisito. Definimos con el área legal qué pasa cuando un requisito no cumple, y con el equipo técnico qué entra en el reensayo.
La discusión sobre quién paga terminó, porque el requisito pasó a ser parte de lo contratado. El efecto colateral fue mayor de lo esperado: el proveedor empezó a entregar ya corregido antes de la homologación, porque no cumplir pasó a costarle retrabajo.
Seguros
Un asistente con modelo de lenguaje atendía asegurados y tenía acceso a una base interna de documentos, además de permiso para consultar sistemas mediante herramientas. La evaluación de seguridad anterior había mirado el servidor y la autenticación, y no el comportamiento del modelo.
Probamos contra el Top 10 para aplicaciones con modelo de lenguaje, empezando por la inyección de prompt directa y por la indirecta, que llega escondida dentro de un documento que el propio sistema lee. Revisamos los permisos de las herramientas disponibles para el asistente y el tratamiento de la salida antes de que llegara al asegurado.
Un documento cargado en la base lograba alterar el comportamiento del asistente para conversaciones siguientes, y una de las herramientas tenía permiso de escritura sin necesitarlo. Redujimos el permiso al mínimo, separamos contenido de instrucción y pasamos a validar la salida, lo que cerró los dos caminos.
CÓMO LO CONDUCIMOS
La regla se elige antes de la prueba, y por escrito. Sin nivel de ASVS declarado y sin alcance cerrado, el informe se vuelve una lista de hallazgos sueltos, que luce en la presentación y no permite decir si la aplicación cumple.
Relevamos lo que existe de aplicaciones, API, aplicaciones móviles y componentes de IA generativa, con dueño definido para cada ítem. A partir de ahí elegimos las listas aplicables a cada activo y el nivel de ASVS objetivo, junto con quien responde por el producto.
Inventario de aplicaciones, API y apps móviles, con dueño por ítem
Referencia aplicable definida por activo, del Top 10 web al de modelo de lenguaje
Nivel de ASVS objetivo acordado con el equipo de producto
Reglas de participación, ambiente y ventana de prueba por escrito
Hito de entregaAlcance y nivel de ASVS aprobados antes de que empiece cualquier prueba.
Las dos actividades conviven y cumplen papeles distintos. El Top 10 orienta la búsqueda de lo que suele romperse primero, y el ASVS entrega el veredicto requisito por requisito. Trabajamos con acceso a documentación y a código siempre que es posible, porque es la forma recomendada por el propio estándar y la única que alcanza la autorización y la regla de negocio.
Veredicto por requisito, con evidencia adjunta
Hallazgos priorizados por riesgo real, con el camino de explotación descrito
Requisitos no aplicables identificados, cada uno con su justificación
Informe ejecutivo separado del informe técnico
Hito de entregaInforme entregado con alcance, nivel y todos los requisitos verificados declarados.
Nos sentamos con quien desarrolla para convertir el hallazgo en tarea con responsable y fecha. Donde el desarrollo está tercerizado, el mismo contenido se vuelve texto de requisito para el contrato, con el nivel de ASVS declarado y la evidencia exigida por ítem, para que la próxima entrega nazca ya dentro de la regla.
Plan de corrección con responsable y fecha por hallazgo
Texto de requisito de seguridad para el contrato con el proveedor
Criterio de aceptación ligado a requisito verificable
Reensayo de los ítems cerrados, con evidencia del antes y del después
Hito de entregaHallazgos de mayor riesgo corregidos y confirmados en reensayo.
La prueba mide el producto en un instante, y el SAMM mide el proceso que produce ese producto. Evaluamos las quince prácticas en las cinco funciones de negocio, definimos el nivel objetivo de cada una con el liderazgo de tecnología y acordamos la cadencia de verificación que sostiene el resultado a lo largo del tiempo.
Medición SAMM por práctica, con nivel actual y nivel objetivo
Plan de evolución del proceso, priorizado por lo que más traba la entrega
Verificación integrada al pipeline, en lo que corresponda automatizar
Rutina de reensayo y de revisión de alcance definida, con quién lo hace y cuándo
Hito de entregaNivel actual y objetivo definidos por práctica, con plan aprobado por el liderazgo de tecnología.
CUÁNTO TIEMPO LLEVA
No publicamos plazo estándar, porque plazo publicado se convierte en promesa. Lo que mueve el reloj aquí es casi siempre el alcance real, que suele ser mayor de lo que describe el pedido inicial. Estos son los tres factores que más pesan, y la primera conversación ya muestra en cuál está tu empresa.
Una aplicación web con una API y una app móvil suman tres superficies distintas de prueba. La integración con terceros, un área autenticada con perfiles diferentes y un componente de IA generativa agregan caminos que hay que recorrer con credenciales distintas para que aparezca un problema de autorización.
El nivel 1 es el primer paso y cierra la capa más básica de defensa. El nivel 2 es lo que la mayoría de las aplicaciones de negocio debería buscar, y el nivel 3 es para lo que carga riesgo alto. Cuanto más alto el nivel, más depende el trabajo del acceso al código, a la documentación y a las personas que lo desarrollaron.
Con equipo interno, la corrección y el reensayo avanzan al ritmo de su agenda. Con fábrica de software, la corrección depende del contrato, y a veces el cambio contractual es el paso más lento de todo el proyecto. Esa conversación empieza temprano, junto con la definición del nivel objetivo.
PREGUNTAS FRECUENTES
Las dudas que aparecen en casi toda primera reunión, respondidas sin rodeos.
La pregunta aparece bastante y la respuesta ahorra dinero. La fundación no certifica proveedores, verificadores ni software, y lo dice en el propio texto del ASVS, su estándar de verificación de seguridad de aplicaciones. Va más allá y recomienda cautela con sellos de terceros que se presenten como certificación OWASP oficial, porque existen en el mercado y no tienen respaldo. Lo que el material de OWASP entrega sirve mejor a tu caso que un sello: una vara pública que tu cliente y tu pentester reconocen, con veredicto requisito por requisito. Y cuando la exigencia sea de verdad un documento emitido por un organismo acreditado, quien responde es la ISO 27001 o el SOC 2.
Con alcance y nivel de ASVS declarados, el informe pasa a decir si la aplicación cumple, y las propuestas de proveedores distintos pasan a ser comparables. Sirve tanto para quien necesita responder a un cliente como para quien va a poner el requisito en el contrato de la próxima entrega.
Comparativas sobre este tema
Ver las 13 comparativas