Cuando OpenAI anunció que los sistemas de análisis de seguridad con IA no iban a basarse en reportes SAST tradicionales, la reacción del mercado fue de confusión. ¿Cómo vas a revisar código sin análisis estático? La respuesta de OpenAI en su post técnico sobre Codex Security revela una distinción arquitectónica que cualquier persona que construya o evalúe herramientas de seguridad debería entender.
SAST (Static Application Security Testing) lleva décadas siendo el caballo de batalla del análisis de código. El modelo conceptual es elegante: identifica una fuente de input no confiable, rastrea el flujo de datos a través del programa y marca los casos donde ese dato llega a un sink sensible sin sanitización. Funciona bien para muchos bugs reales y escala bien en bases de código grandes.
¿Por qué el análisis de flujo de datos no es suficiente?
El problema no es que SAST sea incorrecto — es que responde la pregunta equivocada. Trazar fuente a sink te dice si existe un camino de datos. Pero la vulnerabilidad real vive en si los controles a lo largo de ese camino realmente hacen lo que el sistema asume que hacen.
Claude Desbloqueado
Mi curso avanzado para aprender a sacarle mucho más provecho a Claude en el trabajo y en el día a día, con funciones y usos más potentes. Comienza el 23 de marzo.
→ Inscríbete hoy 🚀Un ejemplo concreto del post técnico de OpenAI lo ilustra perfectamente: imagine una aplicación web que recibe un payload JSON, extrae un redirect_url, lo valida contra una expresión regular de allowlist, aplica URL decode y pasa el resultado al handler de redirección. El análisis estático puede describir el flujo completo: input no confiable → regex check → URL decode → redirect. Tick correcto en todos los boxes.
Pero la pregunta que determina si hay vulnerabilidad no es si existe el check. Es si ese regex todavía constraña el valor después de las transformaciones que siguen. ¿El regex corre antes del decode? Si es así, ¿todavía controla la URL decodificada tal como la interpreta el handler de redirección? Responder eso requiere razonar sobre toda la cadena de transformación: qué permite el regex, cómo se comporta decoding y normalización, cómo el parser de URL trata los edge cases, y cómo resuelve la lógica de redirección schemes y authorities.
Eso es razonamiento sobre invariantes del sistema, no tracking de dataflow. Y es exactamente donde SAST tiene que hacer aproximaciones para mantenerse tratable a escala — con dynamic dispatch, callbacks, reflection y control flow de frameworks. Las aproximaciones son inevitables. No son un fallo de SAST; son la realidad de razonar sobre código sin ejecutarlo.
El enfoque diferente de Codex Security
Codex Security fue diseñado para empezar desde el repositorio en sí — su arquitectura, trust boundaries y comportamiento esperado — y validar lo que encuentra antes de pedirle al equipo humano que invierta tiempo en ello. En lugar de importar un reporte estático y pedirle a un agente que haga triage, el sistema construye primero un modelo del qué se supone que hace el sistema y desde dónde viene la confianza.
Esta distinción importa porque las vulnerabilidades más difíciles — las que persisten durante años en bases de código revisadas por expertos — generalmente no son fallos simples de dataflow. Son casos donde el código parece aplicar un control de seguridad, pero ese control no garantiza la propiedad que el sistema asume. El sanitizador existe. El regex está ahí. Pero el invariante se rompe.
Para el desarrollador o tech lead que evalúa herramientas: esto no significa que SAST sea obsoleto. Significa que hay una clase diferente de razonamiento — sobre lógica de sistema, contratos implícitos y propiedades que el código asume pero no verifica — que requiere una aproximación distinta. El costo oculto de verificación en IA que documentamos antes sigue aplicando: el modelo puede identificar el bug, pero alguien tiene que entender si la corrección propuesta preserva los invariantes que importan.
Por qué importa para quienes construyen con IA
El principio arquitectónico aquí va más allá de Codex Security. Si estás construyendo agentes de IA que interactúan con código — ya sea para review, para generación, o para análisis de seguridad — la lección es que las herramientas de razonamiento más valiosas no son las que siguen más caminos de datos. Son las que modelan las intenciones del sistema y los contratos entre componentes.
La Regla de Dos de Meta para seguridad de agentes apunta en la misma dirección: el problema no es trazar qué datos llegan a dónde. Es determinar qué inputs merecen confianza y bajo qué condiciones. Eso requiere razonamiento sobre el sistema completo, no solo sobre los paths.
Para los equipos que hoy confían exclusivamente en SAST, la reflexión práctica es esta: ¿qué bugs en tu base de código actual pasarían un análisis de flujo completo porque parece que el check existe? Esa es la clase de pregunta que la próxima generación de herramientas de seguridad con IA está empezando a poder responder.
