Codex Security es un agente de seguridad de aplicaciones de OpenAI que revisa el código en busca de vulnerabilidades, valida los hallazgos con evidencia y propone el parche correspondiente. Funciona dentro de GitHub, en el propio pull request, y también como plugin local, CLI o SDK. La idea central es sencilla: detectar el problema antes de que ese código llegue a producción.
La revisión de seguridad suele ser el cuello de botella del desarrollo moderno. Los agentes de IA escriben código cada vez más rápido, pero revisar ese código con criterio de seguridad no corre a la misma velocidad. Según OpenAI, en el anuncio de Codex Security del 6 de marzo de 2026, la mayoría de las herramientas de seguridad con IA se limitan a marcar hallazgos de bajo impacto y falsos positivos, y eso obliga a los equipos a dedicar tiempo valioso al triaje. La propuesta de este agente es distinta: construir contexto del proyecto y usarlo para priorizar lo que realmente importa.
En este artículo te explico cómo funciona el flujo completo, desde pedir una revisión manual en un pull request hasta configurar el escaneo automático en todo el repositorio, y qué límites conviene tener claros antes de confiarle la seguridad de tu producto.
¿Qué hace exactamente Codex Security en un pull request?
El flujo que muestra Dan Shanahan, del equipo de ingeniería de despliegue ciber de OpenAI, es directo. Primero se instala el conector de Codex en el repositorio desde GitHub. Luego, dentro de un pull request, se crea un comentario mencionando a Codex y se le pide una revisión de seguridad. El agente analiza el cambio, publica un resumen en la conversación del PR y deja los hallazgos ahí mismo, donde el desarrollador ya está trabajando.
El segundo paso es la corrección. En el video, el presentador toma el enlace del pull request, lo lleva a Codex y le pide reparar el hallazgo. El agente revisa el código, genera un arreglo para el problema de cross-site scripting detectado y publica el commit directamente en la rama del PR. Después se le pide una nueva revisión y esta vez no encuentra incidencias.
Ese ciclo corto es lo más valioso del enfoque. No hay que abrir otra herramienta, ni copiar resultados a un ticket, ni esperar una reunión de seguridad. El hallazgo, el arreglo y la verificación ocurren en el mismo lugar donde el equipo ya revisa código.
¿Cómo se automatiza el escaneo en todo el repositorio?
Pedir la revisión a mano funciona, pero no escala. Por eso Codex Security permite configurar revisiones automáticas. En la configuración de la app existe una sección de revisión de código donde se define cuándo se disparan los escaneos: al abrir un pull request o en cada push dentro de ese PR.
Hay un detalle importante que el video remarca: la preferencia personal solo cubre los pull requests que uno mismo abre. Para que la cobertura sea real, hay que activar la revisión a nivel de repositorio, de modo que cualquier PR, sin importar quién lo cree, pase por el escaneo automático. También se puede ajustar el umbral de severidad para las notificaciones, y así evitar que el equipo se ahogue en avisos menores.
Otro elemento útil son los archivos de instrucciones en markdown que se agregan al repositorio. Sirven para explicarle al agente las particularidades del proyecto: qué componentes son críticos, qué convenciones sigue el equipo, qué zonas del sistema nunca deberían tocarse sin cuidado. Es la forma de que la herramienta no analice el código en abstracto, sino con el contexto real de tu producto.
Aquí conviene una advertencia. El propio material de OpenAI describe Codex Security como una research preview, es decir, una versión en fase de investigación, no un producto terminado. Eso significa que puede cambiar, que la cobertura no está garantizada y que no reemplaza una auditoría formal. Además, la validación profunda de hallazgos depende de que exista un entorno configurado a medida para el proyecto; sin ese entorno, la validación es más limitada. En otras palabras: el escaneo ayuda, pero no demuestra por sí solo que el sistema sea seguro.
¿Qué significa esto para una empresa en Perú o Latinoamérica?
En la mayoría de las empresas medianas de la región, el equipo de desarrollo tiene entre tres y quince personas, y casi nunca incluye un especialista dedicado a seguridad de aplicaciones. La revisión de código existe, pero se concentra en que la funcionalidad esté bien, no en que sea segura. Nadie revisa a fondo un formulario que arma una consulta a la base de datos, ni la forma en que se manejan los permisos de un endpoint.
Ese vacío se paga caro y tarde. Un problema de seguridad típico no se nota en el sprint en que se escribió: aparece meses después, cuando ya hay datos de clientes en juego y la corrección implica frenar el roadmap. La factura de la deuda técnica de seguridad siempre llega con intereses.
Un agente que revisa cada pull request cambia el momento en que se descubre el problema. Ya no se descubre en producción, se descubre en la revisión, cuando el costo de arreglarlo es de minutos y no de semanas. Para un equipo pequeño, eso es la diferencia entre tener un proceso de seguridad y tener la esperanza de que todo salga bien.
También hay una consideración práctica: la herramienta vive dentro de GitHub, que es donde ya trabajan la mayoría de los equipos de la región. No exige montar infraestructura nueva ni contratar una plataforma adicional. Esa baja fricción es, probablemente, lo que más va a influir en si un equipo la adopta o no.
¿Cómo aplica esto en tu empresa?
Si tienes equipo de desarrollo propio, el primer paso no es comprar nada: es medir. Toma los últimos veinte pull requests y pregúntate cuántos pasaron por una revisión de seguridad real. Si la respuesta es ninguno, ya sabes dónde está el hueco.
El segundo paso es definir qué es crítico en tu sistema. No todo el código merece el mismo nivel de escrutinio. Autenticación, manejo de pagos, datos personales de clientes y cualquier integración con sistemas externos deberían estar en la lista alta. Esa lista es la que después se traduce en instrucciones para el agente.
El tercero es empezar con revisión manual en los PR más sensibles antes de activar el escaneo automático en todo el repositorio. Así el equipo se familiariza con el tipo de hallazgos que recibe y con la calidad de los arreglos propuestos, sin que la primera experiencia sea una avalancha de alertas.
Y el cuarto, el más importante: define quién es responsable de cerrar cada hallazgo. Una herramienta que reporta sin que nadie sea dueño del cierre solo genera ruido. Si quieres revisar cómo se ve este flujo en tu caso particular, puedes conversar con nosotros sobre tu caso y lo aterrizamos juntos.
Preguntas Frecuentes
¿Codex Security reemplaza a un especialista en seguridad?
No. Es un primer filtro que corre en cada cambio de código y reduce el trabajo manual de detección, pero OpenAI lo presenta como una research preview. La validación profunda depende de que exista un entorno configurado para el proyecto, y la decisión final sobre qué riesgo se acepta sigue siendo humana. Un especialista aporta criterio de negocio que ninguna herramienta tiene.
¿Funciona si mi equipo no usa GitHub?
El flujo que muestra OpenAI en su video se apoya en GitHub, con el conector instalado en el repositorio. Sin embargo, Codex Security también ofrece plugin local, CLI y SDK, pensados para escanear un repositorio local o integrarse en un pipeline de CI. Si tu equipo usa otro proveedor de repositorios, conviene evaluar esas alternativas antes de asumir que el flujo es idéntico.
¿Qué tipo de vulnerabilidades puede detectar?
En la demostración pública se ve un caso de cross-site scripting, y el material de OpenAI menciona que el agente busca vulnerabilidades complejas usando un modelo de amenazas construido a partir del propio repositorio. No conviene asumir una lista cerrada de categorías: la cobertura depende del contexto del proyecto y de la configuración del escaneo. Trata los resultados como señales a investigar, no como un certificado de seguridad.
Conclusión: ¿vale la pena revisar la seguridad en cada pull request?
La lógica de fondo es difícil de discutir. Mover la detección de vulnerabilidades del momento en que el código ya está en producción al momento en que se está revisando reduce el costo de corrección y el riesgo para el negocio. Herramientas como Codex Security hacen que ese cambio sea viable incluso para equipos pequeños, sin montar un área de seguridad completa.
Mi lectura es que el valor no está en la herramienta aislada, sino en el hábito que obliga a construir: revisar seguridad como parte del flujo normal de desarrollo y no como una auditoría anual. Si quieres empezar por entender qué tan expuesto está tu proceso actual, puedes contactar a Consultoría TI y revisamos juntos por dónde conviene empezar. También puedes revisar más contenido técnico en el blog de Consultoría TI.
Por Edgar Vásquez, Consultoría TI · actualizado el 12 de noviembre de 2026
Fuentes y Referencias
- OpenAI — How to enable PR security reviews with Codex Security (YouTube)
- OpenAI — Codex Security: now in research preview
- OpenAI — Codex Security (documentación)
✨ Contenido generado con ContentFlow — Consultoría-Ti