Mundo, 25 de feb 2026 (ATB Digital).- Durante años, gran parte del análisis de vulnerabilidades ha funcionado como un perro rastreador: excelente siguiendo olores ya identificados, menos útil cuando el rastro es nuevo. Herramientas como CodeQL (y lo que se apoya en ella, incluido GitHub Advanced Security) son potentes detectando clases de fallos bien descritas: patrones de código, flujos de datos típicos, llamadas peligrosas y reglas que se van refinando con el tiempo. El giro que plantea Anthropic con Claude Code Security es otro: pasar de un enfoque “catálogo de reglas” a uno de análisis por razonamiento, donde el sistema intenta entender la intención del código, sus precondiciones y sus consecuencias, como lo haría un investigador humano.
Según lo publicado por VentureBeat, Anthropic tomó su modelo más avanzado, Claude Opus 4.6, lo puso frente a bases de código open source en producción y detectó más de 500 vulnerabilidades de alta severidad que habían sobrevivido décadas de revisión experta y millones de horas de fuzzing. Quince días después, esa capacidad se convirtió en producto: Claude Code Security, lanzado el 20 de febrero en una vista previa limitada para clientes Enterprise y Team.
La cifra impresiona, sí, pero lo realmente incómodo para los responsables de seguridad es la idea que subyace: si “apuntar” un modelo razonador a un repositorio puede destapar fallos profundos, un atacante con acceso a herramientas equivalentes podría recorrer esa misma ruta. La conversación que hoy se abre en comités y consejos no es solo “¿cuántas vulnerabilidades encontramos?”, sino “¿qué tipo de vulnerabilidades estamos dejando fuera por diseño?”.
Qué cambia frente a CodeQL y el SAST clásico
El SAST tradicional y motores basados en reglas han sido la columna vertebral del “shift left” porque automatizan el hallazgo de lo repetible. En términos sencillos, trabajan como un detector de humo: si hay señales conocidas, pitan rápido. El problema es que hay incendios que no huelen a humo, al menos no en la fase inicial. Los fallos de lógica de negocio, controles de acceso mal modelados, precondiciones raras o errores algorítmicos suelen caer en esa zona gris.
VentureBeat describe el contraste así: CodeQL destaca analizando flujo de datos dentro de consultas predefinidas; te dice si una entrada contaminada (“tainted”) llega a una función peligrosa, siempre que la consulta cubra el caso. Claude Code Security, en cambio, intenta generar hipótesis, seguirlas y probarlas. No se limita a preguntar “¿encaja este patrón?”, sino “¿qué asunciones está haciendo el programa y dónde se rompen?”.
Esa diferencia se vuelve tangible cuando el análisis exige comportamientos que rara vez caben en una regla: revisar el historial de commits, inferir parches incompletos, saltar entre archivos, reconstruir rutas de ejecución, y llegar a un proof-of-concept funcional. Como si, en lugar de comprobar puertas con una llave maestra, el sistema aprendiera a mirar el plano del edificio, detectar un pasillo olvidado y comprobar si hay una puerta tras una cortina.
Tres ejemplos que ilustran la “generación de hipótesis”
La metodología publicada por Anthropic incluye casos concretos que muestran dónde acaba el patrón y empieza el razonamiento.
En GhostScript, una utilidad muy extendida para procesar PostScript y PDF, ni el fuzzing ni la revisión manual habían dado con el fallo. El modelo revisó el historial de cambios y encontró un parche que añadía comprobaciones de límites en un archivo concreto. La hipótesis fue simple y muy humana: si esa protección era necesaria ahí, quizá en otras llamadas al mismo componente faltaba. Al buscar usos equivalentes en otro archivo, localizó una llamada sin la comprobación y construyó un PoC de caída. El matiz importante es que aquí la “pista” no está en el código actual, sino en la historia del código: una regla típica no “razona” sobre por qué se hizo un parche, ni extrapola su necesidad a otros puntos.
En OpenSC, centrado en el procesamiento de datos de tarjetas inteligentes, el hallazgo dependía de un camino de ejecución con demasiadas precondiciones, difícil de alcanzar con entradas aleatorias. El modelo buscó patrones de llamadas que suelen ser delicadas, identificó concatenaciones sucesivas con strcat sin verificación de longitud, y razonó sobre cómo forzar el desbordamiento construyendo el contexto que el fuzzer rara vez “acierta” por casualidad. Es el equivalente a encontrar una fuga detrás de un mueble: el detector general recorre el suelo; el investigador mueve el mueble porque sospecha que ahí se suele acumular humedad.
En CGIF, la vulnerabilidad exigía comprender un borde algorítmico: la compresión LZW suele reducir el tamaño, y el código asumía que el resultado comprimido nunca superaría al original. Casi siempre es cierto, hasta que una secuencia concreta hace crecer el diccionario, provoca resets y altera el tamaño esperado. El modelo detectó el caso improbable, explicó por qué era posible y lo llevó a una condición de overflow. Aquí la cobertura de ramas puede ser del 100% y, aun así, no reproducir la secuencia exacta. No basta con “recorrer” el código; hay que entender el comportamiento del algoritmo.
Validación, sandbox y el foco en memoria: por qué importa el método
Una afirmación de “500 vulnerabilidades” se vuelve seria cuando hay disciplina de verificación. Según VentureBeat, Anthropic ejecutó el modelo en una máquina virtual aislada, con utilidades estándar y herramientas de análisis. El equipo rojo no aportó prompts sofisticados ni arneses a medida; la idea era medir qué logra el modelo con condiciones realistas. Se priorizaron fallos de corrupción de memoria porque son más fáciles de confirmar de forma objetiva: monitores de crash y sanitizers reducen la discusión sobre falsos positivos. El propio sistema deduplicó y reordenó hallazgos antes de que intervinieran humanos, y se incorporaron revisores externos para validar y parchear cuando el volumen lo exigió.
El detalle que suele preocupar a un CISO aparece entre líneas: muchas de esas bases open source sostienen infraestructura crítica y software empresarial, con equipos de mantenimiento pequeños, a veces voluntarios. Un fallo que vive una década en una librería no se queda “en la librería”; se hereda como si fuera una grieta en los cimientos de un edificio.
El dilema de doble uso y el punto ciego de la gobernanza
La misma habilidad que encuentra un fallo puede ayudar a explotarlo. En entrevistas citadas por VentureBeat, Fortune y Axios, responsables de Anthropic reconocen el riesgo: modelos que exploran bases de código de forma autónoma, siguiendo pistas, avanzan más rápido que un analista junior. La frase que mejor encapsula el problema no es “la IA es peligrosa”, sino “la agencia lo es”: cuando un sistema propone hipótesis y las persigue, su comportamiento deja de ser lineal y es más difícil acotarlo.
Merritt Baer (CSO en Enkrypt AI y ex Deputy CISO en AWS) lo plantea con crudeza: el reto no es solo precisión; es supervisión. Si no puedes auditar y limitar cómo se usa la herramienta, has creado otro riesgo. También alerta de dos frentes que a menudo se subestiman: el riesgo de acceso y rutas de ataque internas, y el riesgo de propiedad intelectual no solo por exfiltración, también por “transformación”, cuando el modelo reexpresa conocimiento sensible de formas difíciles de rastrear.
Aquí emerge una tensión práctica. Muchos líderes repiten que “la mayoría de intrusiones vienen de configuraciones y credenciales”, no de zero-days. Es cierto, pero no tranquiliza: un sistema que acelera el hallazgo de fallos profundos aumenta la presión sobre procesos que ya iban al límite. El tablero cambia porque el tiempo entre descubrimiento, parche y despliegue se vuelve aún más crítico.
Salvaguardas: señales dentro del modelo y controles fuera del modelo
Anthropic encauza el lanzamiento como “research preview” para Enterprise y Team; ofrece acceso acelerado a mantenedores open source. Según lo descrito, los hallazgos pasan por varias capas de auto-verificación y se entregan con severidad y confianza. Los parches exigen aprobación humana. En el plano técnico, la compañía dice incorporar detección dentro del propio modelo, con “probes” que miden activaciones durante la generación y se amplían con señales específicas de ciberseguridad para rastrear posibles abusos. En el plano operativo, habla de intervención en tiempo real, incluyendo bloqueo de tráfico identificado como malicioso.
No deja de ser llamativo que, ante preguntas sobre tasa de falsos positivos o mecanismos exactos de detección de uso ofensivo, la empresa haya evitado detalles para no ofrecer pistas a actores maliciosos. Es una postura comprensible, aunque complica a compradores que quieren comparar “promesas” con métricas.
Un patrón que se repite: OpenAI, Linux y OpenSSL como aviso
VentureBeat también encadena señales externas: el investigador Sean Heelan habría usado el modelo o3 de OpenAI para descubrir una vulnerabilidad use-after-free en el kernel de Linux (SMB) que herramientas clásicas no captaban porque exigía entender interacciones concurrentes. Por otro lado, la startup AISLE afirma haber encontrado las 12 vulnerabilidades zero-day del parche de seguridad de OpenSSL de enero de 2026, incluyendo un caso de alta severidad en parsing CMS. El mensaje no es que “todo lo anterior no sirve”, sino que el listón sube: cuando el razonamiento entra en el flujo, la “superficie detectable” crece.
Qué deberían preparar los equipos: presupuesto, procesos y límites claros
Si hoy tu programa de seguridad de código se parece a una línea de producción, el razonamiento introduce un inspector que no solo mira defectos conocidos: se pone a hacer preguntas incómodas sobre cómo funciona la fábrica. Eso obliga a replantear reparto de trabajo entre SAST basado en reglas y análisis razonador. Ambos tienen sitio: lo repetible debe seguir automatizado con rapidez; lo incierto necesita un motor que explore. La diferencia es que ese motor también exige límites: políticas de datos, aislamiento, logging, trazabilidad, criterios de éxito, y una definición explícita de qué repositorios y qué tipos de hallazgos se permiten en cada fase.
El consejo que se desprende de la propia narrativa de VentureBeat es casi táctico: empezar en un entorno controlado, con reglas de manejo de información claras y auditoría desde el primer día. Porque si estas herramientas aceleran algo, no es solo la detección: también aceleran la forma en que tus suposiciones quedan expuestas.
Fuente: Whatsnew.com