{"id":428386,"date":"2026-09-14T12:12:00","date_gmt":"2026-09-14T10:12:00","guid":{"rendered":"https:\/\/cms-articles.softonic.io\/es\/?p=428386"},"modified":"2026-09-14T12:12:03","modified_gmt":"2026-09-14T10:12:03","slug":"aws-presenta-deception-benchmark-12-modelos-no-llegan-al-minimo","status":"publish","type":"post","link":"https:\/\/cms-articles.softonic.io\/es\/aws-presenta-deception-benchmark-12-modelos-no-llegan-al-minimo\/","title":{"rendered":"AWS presenta Deception Benchmark: 12 modelos no llegan al m\u00ednimo"},"content":{"rendered":"

AWS present\u00f3 hoy Deception Benchmark<\/strong>, una prueba p\u00fablica creada para comprobar si los sistemas automatizados de revisi\u00f3n de c\u00f3digo saben distinguir de verdad entre una pieza de software vulnerable y otra que solo lo parece. El punto, seg\u00fan explica la compa\u00f1\u00eda, no es simplemente detectar fallos, sino juzgar bien si ese riesgo puede explotarse en la pr\u00e1ctica. Tambi\u00e9n ha puesto a disposici\u00f3n p\u00fablica tanto el conjunto de datos como el proceso de evaluaci\u00f3n. Y, por lo que muestran sus primeras pruebas, el panorama est\u00e1 lejos de ser tranquilizador.<\/p>\n\n

La publicaci\u00f3n abierta de los datos y del m\u00e9todo de evaluaci\u00f3n responde a una idea muy concreta: que investigadores y empresas no tengan que volver a asumir el coste<\/a><\/strong>, nada peque\u00f1o, de crear y depurar este tipo de muestras desde cero.<\/p>\n\n

Los primeros resultados no invitan al optimismo<\/strong>.<\/p>\n\n

En las pruebas de AWS, los modelos marcaron por error como vulnerable entre el 41 % y el 99 %<\/strong> del c\u00f3digo que en realidad era seguro, incluso cuando ese c\u00f3digo estaba construido para parecer arriesgado. M\u00e1s en detalle, ninguno de los 12 modelos evaluados, procedentes de cinco proveedores, alcanz\u00f3 el m\u00ednimo que AWS fija para considerar viable un uso en producci\u00f3n: mantener tanto los falsos positivos<\/a> como los falsos negativos por debajo del 10 %.<\/p>\n\n

La compa\u00f1\u00eda plantea este benchmark como una forma de comparar capacidades reales de an\u00e1lisis, sin quedarse en demos llamativas o en pruebas demasiado simples.<\/p>\n\n

El conjunto re\u00fane 14.822 muestras<\/strong>, distribuidas en 16 lenguajes de programaci\u00f3n y en m\u00e1s de 70 categor\u00edas de Common Weakness Enumeration, o CWE. De ese total, 9.695 son puntuables: 6.988 retos a nivel de c\u00f3digo y 2.707 retos condicionados por el entorno.<\/p>\n\n

Ah\u00ed est\u00e1 una de las piezas centrales de Deception Benchmark: las muestras seguras est\u00e1n hechas para enga\u00f1ar<\/strong>.<\/p>\n\n

Incluyen patrones reales de vulnerabilidad, pero tambi\u00e9n protecciones o mitigaciones que bloquean la explotaci\u00f3n. Por eso no alcanza con reconocer una funci\u00f3n sospechosa o una llamada que suene mal; hace falta entender el contexto. AWS a\u00f1ade otro matiz importante: cada muestra debe evaluarse en una sola pasada, sin apoyarse en procesos complejos de varias etapas<\/strong>, para ver si el modelo entiende por s\u00ed mismo el c\u00f3digo y las defensas que lo rodean.<\/p>\n\n

Tambi\u00e9n hay pruebas en las que el mismo c\u00f3digo puede ser vulnerable o no, dependiendo de c\u00f3mo est\u00e9 desplegado.<\/p>\n\n

En los retos condicionados por el entorno, cambios peque\u00f1os<\/strong> en la configuraci\u00f3n alteran el resultado final. Un ejemplo ser\u00eda una ruta vulnerable a Server-Side Request Forgery, o SSRF, que al leer el c\u00f3digo parece explotable, pero queda bloqueada por una pol\u00edtica de red en Kubernetes<\/a>.<\/p>\n\n

Para los equipos de seguridad, una lluvia de alertas err\u00f3neas<\/strong> no es una molestia menor.<\/p>\n\n

Significa m\u00e1s horas de investigaci\u00f3n, m\u00e1s fatiga operativa, peor priorizaci\u00f3n y menos confianza en los hallazgos leg\u00edtimos. Y eso pesa todav\u00eda m\u00e1s ahora que estas herramientas ya se usan para clasificaci\u00f3n de vulnerabilidades, pruebas ofensivas, modelado de amenazas, respuesta a incidentes y revisi\u00f3n de c\u00f3digo.<\/p>\n\n

El contexto general tampoco acompa\u00f1a. La automatizaci\u00f3n avanzada est\u00e1 acelerando el descubrimiento de fallos y apretando todav\u00eda m\u00e1s la gesti\u00f3n de parches, al mismo tiempo que sistemas como la National Vulnerability Database, la NVD, ya vienen arrastrando problemas de capacidad<\/strong>.<\/p>\n\n

Hay otra preocupaci\u00f3n sobre la mesa: el c\u00f3digo generado por asistentes autom\u00e1ticos puede traer una densidad mayor<\/strong> de errores de seguridad.<\/p>\n\n

Por ahora, la conclusi\u00f3n pr\u00e1ctica 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.<\/p>\n\n

AWS s\u00ed deja una se\u00f1al algo m\u00e1s positiva: en sus experimentos, usar un segundo modelo como evaluador para revisar los hallazgos del primero redujo los falsos positivos<\/strong> en un 67 % sin empeorar la tasa de aciertos.<\/p>","protected":false},"excerpt":{"rendered":"

AWS present\u00f3 hoy Deception Benchmark, una prueba p\u00fablica creada para comprobar si los sistemas automatizados de revisi\u00f3n de c\u00f3digo saben distinguir de verdad entre una pieza de software vulnerable y otra que solo lo parece. El punto, seg\u00fan explica la compa\u00f1\u00eda, no es simplemente detectar fallos, sino juzgar bien si ese riesgo puede explotarse en … Continue reading “AWS presenta Deception Benchmark: 12 modelos no llegan al m\u00ednimo”<\/span><\/a><\/p>\n","protected":false},"author":9349,"featured_media":428385,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","wpcf-pageviews":0},"categories":[9317],"tags":[],"usertag":[],"vertical":[],"content-category":[14053],"class_list":["post-428386","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-news","content-category-ia"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/cms-articles.softonic.io\/es\/wp-json\/wp\/v2\/posts\/428386","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cms-articles.softonic.io\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cms-articles.softonic.io\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cms-articles.softonic.io\/es\/wp-json\/wp\/v2\/users\/9349"}],"replies":[{"embeddable":true,"href":"https:\/\/cms-articles.softonic.io\/es\/wp-json\/wp\/v2\/comments?post=428386"}],"version-history":[{"count":1,"href":"https:\/\/cms-articles.softonic.io\/es\/wp-json\/wp\/v2\/posts\/428386\/revisions"}],"predecessor-version":[{"id":428387,"href":"https:\/\/cms-articles.softonic.io\/es\/wp-json\/wp\/v2\/posts\/428386\/revisions\/428387"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cms-articles.softonic.io\/es\/wp-json\/wp\/v2\/media\/428385"}],"wp:attachment":[{"href":"https:\/\/cms-articles.softonic.io\/es\/wp-json\/wp\/v2\/media?parent=428386"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cms-articles.softonic.io\/es\/wp-json\/wp\/v2\/categories?post=428386"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cms-articles.softonic.io\/es\/wp-json\/wp\/v2\/tags?post=428386"},{"taxonomy":"usertag","embeddable":true,"href":"https:\/\/cms-articles.softonic.io\/es\/wp-json\/wp\/v2\/usertag?post=428386"},{"taxonomy":"vertical","embeddable":true,"href":"https:\/\/cms-articles.softonic.io\/es\/wp-json\/wp\/v2\/vertical?post=428386"},{"taxonomy":"content-category","embeddable":true,"href":"https:\/\/cms-articles.softonic.io\/es\/wp-json\/wp\/v2\/content-category?post=428386"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}