Codex Security: CLI abierta alimenta a OpenAI
El código del cliente de la CLI de Codex Security se publica bajo licencia Apache-2.0 de código abierto, mientras que el backend de escaneo permanece en fase beta limitada integrando infraestructura de OpenAI. Los responsables de AppSec y DevSecOps deben aclarar antes del despliegue el flujo de datos, el contrato y la gestión de claves.
Lo más importante en resumen
- Cliente abierto, backend cerrado. El código Apache-2.0 está disponible públicamente en GitHub. Cada escaneo se ejecuta contra la infraestructura de OpenAI en fase beta limitada.
- CLI y SDK de TypeScript. Los escaneos, la revisión de cambios, el seguimiento de ejecuciones y la verificación de correcciones pueden integrarse en entornos CI.
- Clave API en contexto de build. En entornos CI se utiliza la variable OPENAI_API_KEY. El ámbito, la rotación y la auditoría deben incluirse en el proceso de aprobación.
- Lanzamiento temprano. OpenAI menciona explícitamente que se trata de una versión temprana. La interfaz y los hallazgos no incluyen garantía de completitud.
Artículos relacionados: Detección activa, pero la priorización dejó la alarma en standby · CI/CD publicó el cargador de botnet AsyncAPI
¿Qué es la Codex Security CLI?
¿Qué es la Codex Security CLI? La Codex Security CLI es un cliente para detectar vulnerabilidades en el código, publicado por OpenAI. La herramienta cubre la identificación, validación y corrección de fallos, disponible tanto como línea de comandos como SDK de TypeScript bajo licencia Apache-2.0.
Su lanzamiento se produjo el 29 de julio de 2026 sin aviso previo. Hacker News descubrió el repositorio antes de que OpenAI hiciera referencia al mismo.
En poco tiempo acumuló alrededor de 1.500 estrellas. OpenAI califica explícitamente esta versión como un lanzamiento temprano.
La CLI debe distinguirse claramente de la antigua Codex CLI. Este último es el agente de codificación con un propósito diferente.
Codex Security se centra en la detección y verificación de vulnerabilidades en el código existente. Aunque los nombres de los productos son similares, sus usos prácticos difieren claramente en el día a día de los equipos.
Codex Security funcionó desde marzo de 2026 como vista previa de investigación. El 22 de junio de 2026 se lanzó la iniciativa «Patch the Planet» (Parchear el planeta).
El 17 de julio de 2026 se incorporó el complemento Codex Security en la interfaz de Codex. La CLI como código abierto cierra esta secuencia el 29 de julio de 2026.
Escaner, seguimiento e integración en el pipeline de CI
La funcionalidad cubre el ciclo habitual de AppSec en el pipeline. Los repositorios pueden escanearse por completo y los cambios pueden verificarse de forma selectiva.
Los hallazgos pueden rastrearse a lo largo de múltiples ejecuciones. Las correcciones pueden verificarse e integrarse como comprobación de seguridad en el CI.
Para los equipos de pipeline, la repetibilidad de las ejecuciones es clave. Un escaneo en todo el repositorio y la verificación del cambio actual proporcionan una imagen comprensible. La comparación con ejecuciones anteriores respalda la revisión en el merge.
La CLI y el SDK de TypeScript cumplen el mismo propósito. La elección depende de las herramientas existentes en el equipo.
La instalación se realiza mediante npm en el entorno Node habitual. El paquete se denomina arroba openai barra codex-security.
Para un escaneo de repositorio, basta con ejecutar npx codex-security scan punto en el directorio del proyecto. Los requisitos previos son Node.js 22 o posterior, así como Python 3.10 o posterior.
La autenticación puede realizarse mediante el inicio de sesión en ChatGPT o la variable de entorno OPENAI_API_KEY. En el entorno CI se prefiere la clave de API.
Si ambas opciones están disponibles, la interfaz selecciona de forma interactiva. Las opciones --auth chatgpt y --auth api-key controlan la elección.
Por defecto, el historial de escaneos se almacena en el directorio de Workbench. Alternativamente, la variable de entorno CODEX_SECURITY_STATE_DIR controla la ubicación del historial.
La documentación está disponible en learn.chatgpt.com/docs/security/cli. Para los equipos, la integración como comprobación repetible junto a Lint y Tests es fundamental.
El seguimiento a través de múltiples ejecuciones es relevante para los sistemas de tickets. Un hallazgo sin estado a lo largo de las compilaciones genera trabajo duplicado en la cola.
El historial en el directorio de estado respalda la priorización y la justificación en la revisión. Esto aplica tanto para las puertas de merge como para los escaneos completos nocturnos.
La verificación de las correcciones cierra el ciclo en la solicitud de extracción. Una deficiencia reportada y una ejecución posterior muestran si el cambio surte efecto.
Esto alivia las muestras manuales en el día a día. La evaluación técnica por parte de los revisores de seguridad sigue siendo paralela.
Código y backend de cliente abiertos bajo control de OpenAI
El núcleo editorial reside en la separación entre cliente y servicio. El código bajo licencia Apache 2.0 está disponible públicamente en GitHub.
El backend de escaneo permanece en fase beta limitada para clientes autorizados. Cada escaneo se ejecuta contra la infraestructura de OpenAI.
Aquí, el código abierto implica lógica de cliente legible y libre redistribución bajo licencia. Sin embargo, el análisis en sí sigue vinculado al proveedor. Por ello, para los equipos de seguridad, el flujo de datos y el contrato son prioritarios frente a la lista de funciones.
Durante el escaneo, el código fuente o contextos derivados abandonan la red propia. Qué fragmentos se ven afectados debe definirse antes del despliegue.
Asimismo, contrato y almacenamiento deben aclararse antes del primer uso en producción. La CLI por sí sola no responde estas cuestiones operativas en el proceso de liberación.
Liberar significa aquí acceso a la beta y al backend. El código abierto del cliente no sustituye esta liberación en entorno operativo.
Los repositorios con secretos internos requieren una evaluación independiente del origen. Lo mismo aplica para datos personales y normativas estrictas de exportación.
Legal y Compras revisan la ruta contractual en paralelo a la pilotación técnica. Plazos de retención, subprocesamiento y ubicación deben incluirse en el mismo expediente. Sin esta aclaración, el trabajo en CI seguirá siendo una operación en la sombra sin liberación fiable.
Tras el incidente de Hugging Face, los proveedores despliegan herramientas defensivas. Codex Security se integra en esta línea como cliente auditables con servicio centralizado. No se ha establecido una relación causal entre el incidente y el lanzamiento.
Antes del despliegue
- ✓Se ha aclarado qué código abandona la red propia, bajo qué contrato y con qué políticas de almacenamiento.
- ✓Se han definido el alcance y la rotación de la clave OPENAI_API_KEY en el entorno de CI.
- ✓La separación entre código abierto del cliente y backend en beta limitada es verificable.
- ✓Se ha evaluado la idoneidad para entornos regulados o air-gapped antes de su implementación.
- ✓El equipo es consciente de que el lanzamiento inicial no incluye garantías de exhaustividad en los hallazgos.
Entornos regulados y la clave API en el proceso de construcción
Las redes air-gapped, los operadores de infraestructuras críticas (KRITIS) y las entidades financieras reguladas no pueden optar por la vía cloud. Sin una salida autorizada al backend, el escaneo queda completamente descartado. El código cliente local no altera esta premisa en una red aislada.
Donde sí está permitida la utilización de cloud, el manejo de claves adquiere protagonismo. Una OPENAI_API_KEY en la CI es un secreto de larga duración en el contexto de construcción. El ámbito, la rotación y la auditoría deben integrarse en el mismo proceso de aprobación que otros secretos de las pipelines.
El contexto de construcción almacena secretos durante más tiempo del esperado. Los registros (logs), los artefactos y las pipelines bifurcadas amplían notablemente la superficie de ataque.
La máscara en la CI reduce el riesgo en el día a día. Los permisos estrictos y la corta vida útil de la clave hacen lo mismo. Una clave propia por pipeline o equipo facilita el seguimiento en auditorías.
El inicio de sesión en ChatGPT es adecuado para el trabajo interactivo en el equipo de desarrollo. En las construcciones automatizadas (unattended builds), la clave API sigue siendo el método práctico.
Ambas vías terminan en el mismo backend de OpenAI. La elección solo modifica la ruta de datos hacia el proveedor en lo que respecta a la autenticación.
El estado temprano del lanzamiento limita las expectativas sobre la estabilidad en el día a día. Los hallazgos no incluyen una garantía de exhaustividad para todo el código existente.
Las interfaces pueden cambiar en versiones posteriores. Los equipos deben documentar la versión, el alcance de la aprobación y los límites conocidos en el manual de operaciones.
Para el despliegue, es adecuado un piloto restringido con límites claros. Un repositorio autorizado, una ruta contractual documentada y una clave rotativa constituyen la base mínima.
Paralelamente, los controles SAST y de dependencias existentes en el gate permanecen activos. Codex Security añade esta capa adicional una vez que se aprueban el acceso beta y el cumplimiento normativo.
Las métricas en el piloto se mantienen deliberadamente simples y comprensibles. El número de ejecuciones, los hallazgos procesados y los abortos por errores de autenticación o red son suficientes para la primera evaluación.
En esta fase inicial no se ofrecen benchmarks. La operación se centra en la estabilidad y la liberación de datos.
La herramienta es viable para clientes beta autorizados una vez que se aclaran el flujo de datos, el contrato y el manejo de claves. El cliente abierto facilita la revisión y la integración en pipelines existentes. El requisito operativo sigue siendo el punto central de aprobación antes del despliegue en pipelines productivas.
Preguntas frecuentes
Cada pregunta está bloqueada. Un toque desbloquea la respuesta.
¿La CLI de Codex Security es completamente usable como código abierto?
El código del cliente está disponible bajo licencia Apache-2.0 en GitHub. El backend de escaneo permanece en fase beta limitada para clientes seleccionados. Cada escaneo se ejecuta contra la infraestructura de OpenAI. El código público y el funcionamiento offline sin backend son escenarios distintos.
¿En qué se diferencia Codex Security de la antigua Codex CLI?
El antiguo Codex CLI es el agente de codificación. Codex Security sirve para detectar, validar y corregir vulnerabilidades. Ambos productos comparten nombres similares, pero sus usos y interfaces deben evaluarse por separado.
¿Qué requisitos son necesarios para la instalación y el escaneo?
Se requiere Node.js 22 o posterior y Python 3.10 o posterior. La instalación se realiza mediante npm con el paquete @openai/codex-security. Un escaneo se inicia con npx codex-security scan. La autenticación se lleva a cabo a través de inicio de sesión en ChatGPT o mediante OPENAI_API_KEY.
¿Qué implica el estado de lanzamiento anticipado para las operaciones?
OpenAI especifica explícitamente que esta liberación es una versión preliminar. Los hallazgos no garantizan exhaustividad. La interfaz aún se considera inestable. Los equipos documentan la versión y sus limitaciones conocidas en el manual de operaciones.
¿Qué aspectos deben aclararse antes de implementar el CI?
El flujo de datos hacia el backend, el marco contractual y el almacenamiento son prioritarios. La clave API en el entorno de compilación requiere alcance definido, rotación y auditoría. En entornos aislados (air-gapped) y altamente regulados, verificar si se permite el uso de escaneos en la nube.
Selección de la redacción
RecomendadoUn paquete npm que robó las claves privadasRecomendado¿Qué es una SBOM? La lista de materiales de softwareRecomendado622 CVE: priorizar en lugar de parchear con pánico
Más de la red MBF Media
MyBusinessFutureIA barata de China: qué debe revisar el departamento de comprasDigital ChiefsWashington decide qué inteligencia artificial puede operar aquí
