AWS presentó hoy Deception Benchmark, una prueba pública creada para comprobar si los sistemas automatizados de revisión de código saben distinguir de verdad entre una pieza de software vulnerable y otra que solo lo parece. El punto, según explica la compañía, no es simplemente detectar fallos, sino juzgar bien si ese riesgo puede explotarse en la práctica. También ha puesto a disposición pública tanto el conjunto de datos como el proceso de evaluación. Y, por lo que muestran sus primeras pruebas, el panorama está lejos de ser tranquilizador.
La publicación abierta de los datos y del método de evaluación responde a una idea muy concreta: que investigadores y empresas no tengan que volver a asumir el coste, nada pequeño, de crear y depurar este tipo de muestras desde cero.
Los primeros resultados no invitan al optimismo.
En las pruebas de AWS, los modelos marcaron por error como vulnerable entre el 41 % y el 99 % del código que en realidad era seguro, incluso cuando ese código estaba construido para parecer arriesgado. Más en detalle, ninguno de los 12 modelos evaluados, procedentes de cinco proveedores, alcanzó el mínimo que AWS fija para considerar viable un uso en producción: mantener tanto los falsos positivos como los falsos negativos por debajo del 10 %.
La compañía plantea este benchmark como una forma de comparar capacidades reales de análisis, sin quedarse en demos llamativas o en pruebas demasiado simples.
El conjunto reúne 14.822 muestras, distribuidas en 16 lenguajes de programación y en más de 70 categorías de Common Weakness Enumeration, o CWE. De ese total, 9.695 son puntuables: 6.988 retos a nivel de código y 2.707 retos condicionados por el entorno.
Ahí está una de las piezas centrales de Deception Benchmark: las muestras seguras están hechas para engañar.
Incluyen patrones reales de vulnerabilidad, pero también protecciones o mitigaciones que bloquean la explotación. Por eso no alcanza con reconocer una función sospechosa o una llamada que suene mal; hace falta entender el contexto. AWS añade otro matiz importante: cada muestra debe evaluarse en una sola pasada, sin apoyarse en procesos complejos de varias etapas, para ver si el modelo entiende por sí mismo el código y las defensas que lo rodean.
También hay pruebas en las que el mismo código puede ser vulnerable o no, dependiendo de cómo esté desplegado.
En los retos condicionados por el entorno, cambios pequeños en la configuración alteran el resultado final. Un ejemplo sería una ruta vulnerable a Server-Side Request Forgery, o SSRF, que al leer el código parece explotable, pero queda bloqueada por una política de red en Kubernetes.
Para los equipos de seguridad, una lluvia de alertas erróneas no es una molestia menor.
Significa más horas de investigación, más fatiga operativa, peor priorización y menos confianza en los hallazgos legítimos. Y eso pesa todavía más ahora que estas herramientas ya se usan para clasificación de vulnerabilidades, pruebas ofensivas, modelado de amenazas, respuesta a incidentes y revisión de código.
El contexto general tampoco acompaña. La automatización avanzada está acelerando el descubrimiento de fallos y apretando todavía más la gestión de parches, al mismo tiempo que sistemas como la National Vulnerability Database, la NVD, ya vienen arrastrando problemas de capacidad.
Hay otra preocupación sobre la mesa: el código generado por asistentes automáticos puede traer una densidad mayor de errores de seguridad.
Por ahora, la conclusión práctica sigue siendo prudente. Un piloto de la Cybersecurity and Infrastructure Security Agency, CISA, ya apuntaba que estas herramientas rinden mejor como apoyo para analistas y soluciones ya existentes, no como reemplazo.
AWS sí deja una señal algo más positiva: en sus experimentos, usar un segundo modelo como evaluador para revisar los hallazgos del primero redujo los falsos positivos en un 67 % sin empeorar la tasa de aciertos.
Author: Manuel Bosque
{
"social": {
"email": "",
"facebook": "",
"twitter": "",
"linkedin": ""
},
"ja-JP": "",
"de-DE": "Manuel Bosque schreibt bei Softonic über Software: Desktop-Programme, Produktivitätswerkzeuge und kleine Tools, die ein Problem wirklich lösen. Sein Maßstab ist praktisch — was ein Programm tatsächlich leistet, was es dafür verlangt und für wen es sich lohnt —, deshalb misstraut er Funktionslisten und testet lieber selbst. Er gehört zum Team, das festlegt, wie Software auf der Seite behandelt wird, und arbeitet täglich mit KI-Werkzeugen in der redaktionellen Produktion.",
"en-US": "Manuel Bosque covers software at Softonic: desktop programs, productivity tools and the small utilities that solve one problem well. His approach is practical — what a program actually does, what it asks in return and who it is for — which is why he distrusts feature lists and prefers to test. He is part of the team that decides how software gets covered on the site, and works daily with AI tools applied to editorial production.",
"es-ES": "Manuel Bosque se ocupa de la cobertura de software en Softonic: programas de escritorio, herramientas de productividad y utilidades pequeñas que resuelven bien un solo problema. Su criterio es práctico —qué hace realmente un programa, qué pide a cambio y a quién le sirve—, y por eso desconfía de las listas de funciones y prefiere probar. Forma parte del equipo que decide cómo se cuenta el software en la web y trabaja a diario con herramientas de IA aplicadas a la producción editorial.",
"fr-FR": "Manuel Bosque couvre les logiciels chez Softonic : programmes de bureau, outils de productivité et petits utilitaires qui résolvent bien un seul problème. Son approche est pratique — ce qu'un logiciel fait vraiment, ce qu'il demande en échange et à qui il s'adresse —, d'où sa méfiance envers les listes de fonctionnalités et sa préférence pour l'essai. Il fait partie de l'équipe qui définit la manière de traiter le logiciel sur le site et travaille au quotidien avec des outils d'IA appliqués à la production éditoriale.",
"it-IT": "Manuel Bosque si occupa di software su Softonic: programmi per il desktop, strumenti di produttività e piccole utility che risolvono bene un solo problema. Il suo criterio è pratico — cosa fa davvero un programma, cosa chiede in cambio e a chi serve — e per questo diffida degli elenchi di funzioni e preferisce provare. Fa parte del team che decide come si racconta il software sul sito e lavora ogni giorno con strumenti di IA applicati alla produzione editoriale.",
"nl-NL": "Manuel Bosque schrijft bij Softonic over software: desktopprogramma's, productiviteitstools en kleine hulpprogramma's die één probleem echt oplossen. Zijn maatstaf is praktisch — wat een programma werkelijk doet, wat het daarvoor vraagt en voor wie het nuttig is — en daarom wantrouwt hij functielijstjes en test hij liever zelf. Hij maakt deel uit van het team dat bepaalt hoe software op de site wordt behandeld en werkt dagelijks met AI-tools in de redactionele productie.",
"pl-PL": "Manuel Bosque zajmuje się oprogramowaniem w Softonicu: programami na komputer, narzędziami do pracy i niewielkimi aplikacjami, które dobrze rozwiązują jeden problem. Jego kryterium jest praktyczne — co program naprawdę robi, czego wymaga w zamian i komu się przyda — dlatego nie ufa listom funkcji i woli sprawdzić sam. Należy do zespołu, który decyduje, jak pisać o oprogramowaniu w serwisie, i codziennie korzysta z narzędzi AI w produkcji redakcyjnej.",
"pt-BR": "Manuel Bosque cobre software na Softonic: programas para desktop, ferramentas de produtividade e pequenos utilitários que resolvem bem um problema só. Seu critério é prático — o que um programa realmente faz, o que pede em troca e para quem serve — e por isso desconfia de listas de recursos e prefere testar. Faz parte da equipe que define como o software é abordado no site e trabalha diariamente com ferramentas de IA aplicadas à produção editorial."
}
View all posts by Manuel Bosque
