Codex Security es un agente de seguridad de aplicaciones impulsado por IA que analiza un proyecto de software en función del contexto, prioriza vulnerabilidades, las valida en la medida de lo posible y propone correcciones concretas. En la Research Preview, el acceso se despliega a través de Codex Web para ChatGPT Enterprise, Business y Edu, con uso gratuito durante el primer mes. El valor principal: menos falsos positivos, menos trabajo de triaje y un despliegue más rápido de código seguro, pese al aumento de la velocidad de desarrollo gracias a los agentes.
Visión general:
Por qué importa el contexto en lugar de un sinfín de hallazgos
Codex Security pretende no informar de lo máximo posible, sino encontrar problemas de seguridad lo más sólidos posible, incluidos parches aplicables. Esto reduce la típica avalancha de hallazgos de bajo impacto y falsos positivos que, si no, atrapan a los equipos de seguridad en bucles de triaje. A la vez, la revisión no debería convertirse en un cuello de botella cuando el desarrollo se acelera por la automatización.
Muchos escáneres con IA evalúan el código de forma aislada y saben poco sobre modelos de roles, límites de confianza (trust boundaries) o rutas reales de despliegue. Sin conocimiento del sistema, muchas cosas parecen críticas, pero en la práctica son difícilmente explotables; o, al contrario, se infravaloran riesgos reales porque falta el contexto. Por eso, Codex Security apuesta primero por comprender el proyecto antes de derivar severidades y propuestas de corrección.
Regla de decisión para su uso
Un equipo se beneficia especialmente cuando el triaje cuesta más tiempo que la corrección en sí, o cuando las tasas de merge son tan altas que ya no se puede revisar manualmente cada delta relevante para la seguridad. Como regla general: si las revisiones de seguridad retrasan lanzamientos con regularidad o si los hallazgos se cierran con demasiada frecuencia a posteriori como «no relevante», merece la pena un agente basado en contexto. Quien además pueda proporcionar un entorno cercano a pruebas obtiene la mayor reducción de falsos positivos, porque la validación sobre el sistema en ejecución pasa a ser posible.
Mini-modelo para situarlo en el mercado
En los agentes de AppSec, por lo general, tres ejes deciden la utilidad práctica:
- Profundidad de contexto: ¿conoce la herramienta la arquitectura, las zonas de confianza y los flujos de datos típicos del proyecto?
- Grado de validación: ¿se comprueban los hallazgos en un sandbox o contra un entorno cercano al proyecto, en lugar de limitarse a hacer match de patrones?
- Cercanía a la corrección: ¿entrega el sistema parches que encajan con la base de código y ayudan a evitar regresiones?
Así funciona Codex Security, del escaneo al parche
Codex Security combina, según la empresa, una configuración basada en agentes con modelos frontier y verificación automatizada. El flujo está diseñado para hacer explícito el contexto de seguridad, sustentar los hallazgos y proponer cambios de forma que se mantengan estables en revisión y en producción. Antes, el servicio era conocido con el nombre Aardvark y se siguió desarrollando en una beta privada.
1) Construir contexto del sistema y hacer editable el modelo de amenazas
Tras la configuración, el agente analiza el repositorio con la vista puesta en la estructura relevante para la seguridad, por ejemplo, rutas de autenticación, interfaces, dependencias y límites entre componentes. De ahí surge un modelo de amenazas específico del proyecto que describe qué hace el sistema, en qué componentes confía y dónde son plausibles las superficies de ataque. Este modelo sigue siendo editable para que los equipos puedan corregir suposiciones y alinear el agente con la arquitectura real.
2) Priorizar hallazgos y, cuando sea posible, verificarlos
Con el modelo de amenazas como guía, Codex Security busca vulnerabilidades y las evalúa según el impacto esperable en el sistema concreto. Cuando hay disponible un entorno de pruebas seguro, los hallazgos se «contrastan» en entornos de validación aislados para separar señal de ruido. Si se conecta un entorno específico del proyecto, la comprobación puede acercarse más al sistema en ejecución, incluidas pruebas de concepto fiables, lo que acelera las decisiones de seguridad.
Terminología, brevemente: SSRF significa que un servidor realiza peticiones no deseadas hacia redes internas, a menudo a través de parámetros de URL aparentemente inocuos; más detalles en OWASP. Este tipo de temas dependen mucho del contexto, porque los servicios internos, las reglas de red y los destinos de salida (egress) permitidos determinan la explotabilidad real.
3) Proponer correcciones que encajen con la intención del sistema
En el último paso se proponen parches que se orientan por el comportamiento circundante y la lógica prevista. El objetivo es lograr mejoras de seguridad sin provocar efectos secundarios, de modo que las revisiones se aprueben más rápido y los cambios se reviertan con menos frecuencia. Los hallazgos pueden filtrarse para que los equipos se centren en las clases de riesgo más importantes para ellos.
El feedback forma parte del bucle: si los equipos corrigen la criticidad de un hallazgo hacia abajo o hacia arriba, el modelo debería usar esas señales para afinar el modelo de amenazas y la precisión en ejecuciones posteriores.
Ejemplo práctico de un entorno SaaS típico
Imaginaos que una aplicación multi-tenant tiene un endpoint que procesa webhooks y, para ello, recupera URLs externas. Un escáner clásico informa de «posible SSRF» en varios caminos de código, sin saber si la salida (egress) está restringida o si endpoints internos de metadatos son accesibles. Un enfoque basado en contexto puede dejar asentado en el modelo de amenazas qué redes cuentan como internas, qué servicios son especialmente sensibles y qué peticiones están permitidas, y a continuación priorizar hallazgos que realmente tengan impacto entre tenants, incluida una corrección propuesta, por ejemplo, allowlisting de URLs más comprobaciones estrictas de DNS e IP.
Datos de la beta y qué dicen
En los primeros usos internos, Codex Security encontró, según la empresa, entre otras cosas una SSRF real y una vulnerabilidad crítica de autenticación que afectaba a varios tenants, además de otros problemas que el equipo de seguridad corrigió en cuestión de pocas horas. Un foco de la beta no fue «más aciertos», sino mejor precisión y severidades más realistas.
- Menos ruido: en escaneos repetidos de los mismos repositorios aumentó la precisión; en un caso documentado, el ruido bajó un 84% desde el despliegue inicial.
- Severidad más realista: la tasa de hallazgos sobreclasificados se redujo en más de un 90%.
- Menos falsos positivos: la tasa de falsos positivos bajó en más de un 50% en el conjunto de repositorios.
Para la escalabilidad, la empresa cita métricas de los últimos 30 días de la cohorte beta: más de 1,2 millones de commits escaneados en repositorios externos, con 792 hallazgos críticos y 10.561 de severidad alta. Los problemas críticos aparecieron en menos del 0,1% de los commits escaneados, lo que se interpreta como indicio de que incluso con grandes volúmenes de código se puede buscar de forma selectiva issues altamente relevantes sin arrollar a los equipos de revisión con volumen.
Un tester externo, NETGEAR, describe el valor aproximadamente así: la integración en los workflows de seguridad existentes habría sido sencilla, los resultados parecían claros y completos, similar a contar con apoyo adicional de product security researchers con experiencia.
Soporte para Open Source y ejemplos concretos de CVE
Los componentes de Open Source sostienen gran parte del panorama del software moderno, también en sistemas comerciales. En conversaciones con maintainers, según la empresa, se repitió un problema: no faltan informes; faltan informes utilizables, porque demasiados avisos son imprecisos y generan triaje adicional. Por eso, Codex Security debería entregar preferentemente hallazgos que puedan verificarse rápido y corregirse directamente.
La empresa informa de que comunicó vulnerabilidades críticas a varios proyectos muy extendidos, entre ellos OpenSSH, GnuTLS, Gogs, libssh, PHP y Chromium. En total se asignaron 14 CVE; en dos casos hubo un informe duplicado.
Programa Codex for OSS
En paralelo, se está poniendo en marcha un programa para maintainers: «Codex for OSS» pretende agrupar, entre otras cosas, cuentas gratuitas de ChatGPT Pro y Plus, apoyo en revisión de código y acceso a Codex Security. Proyectos como vLLM ya habrían usado Codex Security para encontrar vulnerabilidades y parchearlas en el workflow habitual de maintainer; se ha anunciado una ampliación del programa.
Anexo con hallazgos OSS de la visión general
- GnuTLS: heap-buffer-overflow off-by-one en certtool, CVE-2025-32990
- GnuTLS: heap-buffer-overread al parsear la extensión SCT, CVE-2025-32989
- GnuTLS: double-free al exportar otherName SAN, CVE-2025-32988
- GOGS: bypass de 2FA, CVE-2025-64175
- GOGS: bypass no autorizado, CVE-2026-25242
- download_ephemeral y download_children: path traversal con escritura arbitraria, CVE-2025-35430
- LdapUserMap: inyección LDAP a través de filtro y DN, CVE-2025-35431
- resend_email_verification: DoS no autenticado y abuso de correo, CVE-2025-35432 y CVE-2025-35436
- User::update_user: falta rotación de sesión al cambiar la contraseña, CVE-2025-35433
- Elasticsearch Client: verificación TLS desactivada, CVE-2025-35434
- /api/streams/depth: DoS por división entre cero, CVE-2025-35435
- gpg-agent: stack-buffer-overflow vía PKDECRYPT con ECC KEM, CVE-2026-24881
- TPM2: buffer-overflow en la pila en PKDECRYPT para RSA y ECC por falta de comprobación de longitud del ciphertext, CVE-2026-24882
- CMS/PKCS7: stack-buffer-overflow en parámetros ASN.1 de AES-GCM, CVE-2025-15467
- PKCS#12: overflow de keyLength en PBMAC1 PBKDF2 más bypass de MAC, CVE-2025-11187
Así empieza un equipo con Codex Security
El despliegue se realizará durante los próximos días para ChatGPT Enterprise, Business y Edu. El uso es gratuito durante el primer mes, ofrecido a través de Codex Web.
- Conectar el repositorio: configurad el escaneo y aseguraos de que el agente recibe suficiente contexto, por ejemplo, mediante notas de arquitectura o supuestos de seguridad.
- Revisar el modelo de amenazas: editad el modelo generado hasta que los límites de confianza, los datos críticos y los flujos de autenticación sean correctos.
- Habilitar la validación: si es viable, proporcionad un entorno en sandbox o cercano a pruebas para hacer los hallazgos más fiables.
- Estandarizar la revisión de correcciones: tratad las propuestas de parche como PRs normales, con tests, code owners y criterios claros de merge.
- Dar feedback con disciplina: ajustad la criticidad solo con justificación, para que el sistema sea más preciso en la siguiente ejecución.
Para indicaciones de setup y detalles actuales del producto, es recomendable la documentación del proveedor, por ejemplo en help.openai.com y la documentación para desarrolladores en platform.openai.com/docs.