AWS propone un arnés de IA para priorizar vulnerabilidades con evidencia verificable

AWS ha descrito un arnés de análisis de vulnerabilidades que utiliza modelos de IA para filtrar hallazgos, pero sitúa la evidencia técnica por encima de la confianza declarada por el modelo. La propuesta responde a un problema práctico: los escáneres generan más resultados de los que los equipos pueden revisar, y una lista extensa de falsos positivos termina debilitando la confianza en toda la cadena de seguridad.

El diseño se organiza en capas con evidencias progresivas. La primera busca acuerdo entre varios escáneres que analizan el mismo código. Si herramientas independientes encuentran el mismo problema, aumenta la plausibilidad; si solo una lo detecta, el caso necesita más escrutinio. Esta fase es relativamente barata porque reutiliza herramientas existentes y no intenta resolver todavía toda la explotabilidad.

La segunda capa verifica la estructura real del programa. El sistema debe comprobar que existen los archivos y funciones mencionados, que el flujo de datos descrito coincide con el código y que hay un camino de llamadas desde la entrada hasta el destino sensible. La idea es importante porque un modelo puede construir una cadena de ataque convincente basada en nombres antiguos, paquetes equivocados o sanitización que no ha tenido en cuenta. En la arquitectura propuesta, una afirmación que no supera esas comprobaciones no debe convertirse en un hallazgo prioritario.

La tercera dimensión añade contexto de despliegue. El código por sí solo no indica siempre la urgencia. Para priorizar mejor, el arnés incorpora plantillas de infraestructura y controles como autenticación, autorización, reglas de AWS WAF o aislamiento de red. AWS insiste en que no deben tratarse igual: la autenticación reduce quién puede intentar un ataque, pero no necesariamente reduce el impacto de una inyección de comandos una vez que el atacante llega a ella. Los controles de bloqueo se aplican a clases concretas de vulnerabilidad, no como una rebaja general.

El artículo complementario sobre el archivo de instrucciones convierte esta metodología en reglas persistentes. Entre ellas incluye una fórmula de confianza basada en señales observables, como flujo confirmado por taint analysis, ausencia de sanitización, exposición pública y existencia de un camino de llamadas. También separa severidad de urgencia: una vulnerabilidad mediana con explotación activa puede requerir atención antes que una crítica difícil de explotar.

En una aplicación vulnerable de prueba con diez vulnerabilidades conocidas, AWS afirma que el archivo de instrucciones permitió identificar nueve, rebajar correctamente dos casos mitigados por controles de infraestructura y documentar el cálculo de confianza. El modelo sin guía encontró las diez, pero no verificó estructuralmente sus afirmaciones.

La propuesta tiene límites claros. No sustituye un analizador de flujo determinista, la verificación de infraestructura desplegada, las fuentes de inteligencia actuales, las pruebas de concepto ni la revisión humana. Su valor está en ordenar esas comprobaciones y detener afirmaciones no verificadas antes de que consuman tiempo de ingeniería. Para equipos que ya usan SAST, DAST o CodeQL, es una arquitectura incremental: primero mejorar la evidencia, después añadir contexto y solo al final automatizar pruebas activas en entornos controlados.