Cuando lees que una herramienta de seguridad no empieza con un informe SAST puede sonar raro: ¿no es SAST la forma clásica de escalar revisiones de código? Codex Security tomó esa decisión a propósito porque la realidad de las vulnerabilidades prácticas suele ser más sutil que un simple flujo de datos.
La raíz del problema: validar la intención, no solo el flujo
SAST hace una cosa muy útil: traza una entrada no confiable hasta un punto sensible y marca el camino. Es elegante y cubre muchos errores. ¿Pero alcanza para decidir si el sistema es realmente seguro?
El punto clave es que muchas fallas no son solo problemas de flujo de datos. Son problemas de intención y de cómo las comprobaciones se mantienen después de transformaciones, decodificaciones o normalizaciones. En otras palabras: no basta con ver que el código llama a sanitize_html(); hay que demostrar que esa llamada mantiene la invariante que el sistema necesita.
¿Te suena familiar? Un caso común: recibes un redirect_url, aplicas una regex para permitir solo ciertos destinos, haces un URL decode y luego rediriges. Un informe fuente-a-sumidero puede mostrar la ruta: entrada → regex → decode → redirect. Pero la pregunta real es otra: ¿la validación se aplica al valor que finalmente interpreta el handler de redirección? Si la regex corre antes del decode, quizá la comprobación no restringe lo que realmente se interpreta después.
Por qué empezar desde el repositorio cambia la jugada
Codex Security parte del código y del diseño del sistema: arquitectura, límites de confianza y comportamiento esperado. No se queda en una lista de hallazgos; busca validar. Eso significa más trabajo automatizado, pero con evidencia más fuerte antes de interrumpir a un humano.
En la práctica eso implica varias estrategias:
- Leer la ruta relevante con todo el contexto del repo, tal como lo haría un investigador. Los comentarios ayudan, pero no bastan para convencer al modelo si el código falla.
- Aislar el slice mínimo que importa (por ejemplo, la cadena de transformaciones sobre una entrada) y generar micro-fuzzers para probar hipótesis.
- Razonar sobre cómo las restricciones se propagan entre transformaciones, y formalizar el problema cuando conviene (por ejemplo, usando un solver) para casos complejos como desbordes en arquitecturas no estándar.
- Ejecutar pruebas en un entorno sandbox para verificar que una hipótesis falla end-to-end; un PoC ejecutable suele ser la mejor evidencia.
La idea no es despreciar SAST. Es que, para un agente que debe descubrir y validar vulnerabilidades en contexto, empezar con un informe SAST puede anclar su razonamiento en suposiciones equivocadas.
Tres fallas previsibles si empiezas por SAST
Si arrancas con un listado de hallazgos externos, aparecen tres modos de fallo habituales:
- Prematura focalización: el informe es un mapa de lo que la herramienta ya miró. Si lo tomas como punto de partida, el agente puede gastar esfuerzo confirmando lo obvio y perder otras áreas.
- Juicios implícitos difíciles de revertir: muchos hallazgos llevan supuestos sobre sanitización o límites de confianza. Si el agente hereda esos supuestos, pasa de investigar a confirmar o descartar sin cuestionar la base.
- Evaluación opaca del razonamiento: si el pipeline comienza con salida SAST, se vuelve difícil medir qué descubrió el agente por sí mismo y qué heredó, lo que complica mejorar el sistema.
¿Qué aporta esto a los equipos de seguridad?
SAST sigue siendo valioso: aplicar normas de código seguro, detectar patrones conocidos y cubrir casos simples a escala. El enfoque de Codex Security no pretende sustituir esas herramientas, sino complementar con una capa que explique por qué algo es realmente problemático y cómo probarlo.
Para equipos con poco tiempo, la diferencia es práctica: pasar de "esto parece sospechoso" a "esto falla así, aquí tienes un PoC y una corrección que respeta la intención del sistema". Eso es lo que más consume recursos humanos en revisiones reales.
Reflexión final
La lección es que seguridad no es solo trazar valores. Es entender intenciones, transformaciones y su impacto real en el comportamiento del sistema. Codex Security apuesta por elevar la confianza antes de notificar a una persona, construyendo evidencia reproducible en lugar de depender de una lista de advertencias precomputadas.
Fuente original
https://openai.com/index/why-codex-security-doesnt-include-sast