¡Descubre GoogleTest, con certificación TÜV y la tecnología Agentic AI para pruebas de C/C++!
Obtenga los detalles »
Saltar a la sección
Blog de Parasoft
Deja de perseguir vulnerabilidades aguas abajo. Descubre por qué la prevención es mejor que la detección y por qué SAST mejora IAST.
Saltar a la sección
Si dedicas suficiente tiempo a hablar de herramientas de seguridad, tarde o temprano oirás hablar de IAST (pruebas interactivas de seguridad de aplicaciones). El argumento es, a grandes rasgos, el siguiente: las herramientas SAST generan demasiado ruido, los desarrolladores ignoran los hallazgos y, cuando estos salen a la luz, su corrección ya es costosa. Es mejor instrumentar la aplicación en ejecución y detectar vulnerabilidades reales durante su ejecución, con menos ruido y un mejor contexto.
Esa crítica no es del todo errónea. He visto SAST implementado precisamente de esa manera, en una fase avanzada del ciclo de desarrollo, como un detector de vulnerabilidades de seguridad en lugar de una herramienta para reforzar el código. Y, efectivamente, falla precisamente así. Pero la conclusión de que IAST sortea los problemas fundamentales de SAST es donde discrepo rotundamente.
La cuestión es la siguiente: el modo de fallo que se describe es un problema de flujo de trabajo, no un problema de la herramienta. Y IAST tiene sus propios problemas estructurales.
Se requiere algún mecanismo para su funcionamiento: un conjunto de pruebas, un escáner DAST que genere tráfico de ataque o usuarios reales en producción. Alguien debe instrumentar la aplicación. El análisis solo abarca el código que se ejecuta realmente, independientemente del origen de dicho tráfico. Para cuando detecta alguna vulnerabilidad, el código ya está compilado, integrado y desplegado.
Y, más fundamentalmente, No puedes detectar tu forma de acceder a un software seguro.La detección es importante. No es suficiente.
La famosa directiva de W. Edwards Deming, «dejar de depender de la inspección para lograr la calidad», no sugería dejar de realizar pruebas. Era un desafío para las organizaciones que habían sustituido la ingeniería de calidad real por la inspección al final de la línea de producción. Si se detectan defectos al final, el fallo ya se produjo en una etapa anterior. La inspección simplemente hace visible el fallo.
El enfoque tradicional para la garantía de calidad del software
Toda disciplina que produce bienes y servicios funcionales ha interiorizado este principio. No se inspecciona la calidad de un puente después de haber vertido el hormigón. Se utilizan los materiales adecuados, se siguen los procedimientos correctos y se verifica cada etapa antes de pasar a la siguiente. La seguridad del software no es diferente. O al menos, no debería serlo.
Integrar la seguridad desde el principio es una disciplina. Descubrir código inseguro a posteriori no lo es. Son actividades de ingeniería completamente distintas, y SAST facilita la primera. Considerarlas intercambiables da como resultado un programa de seguridad que se mantiene permanentemente en modo reactivo, apagando incendios sin abordar jamás la causa original de los mismos.
IAST instrumenta una aplicación en ejecución e informa sobre las vulnerabilidades a medida que se prueba el código durante las pruebas o la producción. Su atractivo es innegable: la confirmación de que una vulnerabilidad es realmente accesible, con un contexto de ejecución que las herramientas estáticas no pueden igualar. Sin embargo, su limitación estructural es igualmente real: IAST solo ve el código que se ejecuta.
La mayoría de las aplicaciones tienen entre un 40 % y un 70 % de cobertura de código en sus conjuntos de pruebas. Estas cubren las rutas de código que manejan casos límite, condiciones de error, funcionalidades heredadas e interfaces de administración poco utilizadas. Precisamente el terreno que los atacantes exploran sistemáticamente puede que nunca se toque durante las pruebas.
Detrás de todo esto hay un problema más profundo. Quienes escriben conjuntos de pruebas no suelen ser probadores de seguridad, y los probadores de seguridad no suelen escribir pruebas unitarias.
El control de calidad estándar no modela el comportamiento de los atacantes. Y quienes sí lo hacen no suelen dedicarse a crear el entorno de pruebas del que depende IAST.
IAST te ofrece una imagen precisa de las vulnerabilidades en el código que prueba. No te da ninguna información sobre el código que no prueba. Reduces los falsos positivos, pero aumentas los falsos negativos. Lo bueno de los falsos negativos es que no generan ruido. Lo malo es que no sabes cuándo ocurren.
También existe una sobrecarga práctica que a menudo no se menciona. Todas las herramientas IAST necesitan algo que impulse la ejecución:
Algunas herramientas pueden utilizar cualquiera de estas opciones. Ninguna de ellas puede analizar código que no se haya probado.
Alguien debe instrumentar la aplicación, mantener dicha instrumentación tras los cambios de código y garantizar que el mecanismo que induce el análisis cubra una superficie de ataque suficiente para que los resultados sean significativos. Cuanto más sofisticado sea el mecanismo, mayor será la inversión operativa necesaria. La cobertura siempre es proporcional a su origen.
Y luego está la dimensión del coste. Para cuando IAST está en funcionamiento, el código ya está escrito, integrado y desplegado al menos en un entorno de prueba, y a menudo también en un entorno de preproducción o producción.
La mayoría de las implementaciones de IAST se realizan en entornos de control de calidad o preproducción, que es donde las ubica nuestro gráfico. Algunos proveedores promocionan explícitamente la implementación en producción. Independientemente de dónde se ejecute, el código ya existe y el contexto de desarrollo que lo creó está desapareciendo. El informe de IBM/Ponemon Institute de 2024 sobre el costo de una filtración de datos sitúa el costo promedio global de una filtración en 4.88 millones de dólares, una cifra récord.
Pero los costos se acumulan mucho antes de la producción. Corregir el mismo defecto cuesta mucho más en control de calidad que en el entorno de desarrollo integrado (IDE), y mucho más en entornos de prueba o producción que en control de calidad.
El coste relativo de corregir un fallo de seguridad aumenta drásticamente en cada etapa del ciclo de vida del desarrollo de software (SDLC). IAST suele operar en la fase de pruebas, donde los costes ya superan considerablemente el nivel base de la fase de codificación.
Algunas implementaciones de IAST no se limitan al entorno de pruebas. Algunos proveedores comercializan explícitamente IAST listo para producción, con agentes que se ejecutan continuamente en sistemas en vivo e informan sobre vulnerabilidades a medida que el código es sometido a pruebas con tráfico real.
El atractivo es obvio: superficie de ataque real, patrones de uso reales, entorno real.
Pero consideremos qué implica realmente el descubrimiento de una vulnerabilidad en producción para su corrección. El código está desplegado y los usuarios dependen de él. Una solución requiere revertir el proceso de desarrollo, pruebas, preproducción y redistribución en un software que puede haber cambiado sustancialmente desde que se lanzó la versión vulnerable.
Es posible que el desarrollador que escribió el código haya pasado a otro sprint, a otro proyecto o incluso a otra empresa. Reconstruir el contexto necesario para corregirlo correctamente es costoso. Y, en la práctica, a menudo no se hace.
Es ridículamente común que una vulnerabilidad descubierta tardíamente se cierre con un comentario del tipo "el código ha cambiado significativamente desde que se reportó" o "no se puede reproducir en mi entorno". Eso no son soluciones. Son aplazamientos disfrazados de resoluciones. El tiempo corre en contra de la explotación durante todo el proceso.
El Violación de seguridad de Uber en 2022 Esto ilustra un problema relacionado. Los atacantes que obtuvieron acceso a la red descubrieron un script de PowerShell que contenía credenciales de administrador codificadas para el sistema de administración de acceso privilegiado de Uber. Dichas credenciales desbloquearon AWS, GCP, Google Drive, Slack y SentinelOne.
La causa principal era una práctica de codificación, secretos codificados directamente en el código fuente, que ninguna herramienta de ejecución detectaría. IAST instrumenta las aplicaciones en ejecución. Una credencial en un script no se ejecuta en una prueba. SAST, al leer el código fuente, la detectaría en el momento en que se escribió.
IAST en producción es una red de seguridad. Es útil. Pero el objetivo es necesitarla lo menos posible, y la forma de lograrlo es evitar que la vulnerabilidad se produzca en primer lugar.
Para una parte importante del software que se desarrolla hoy en día, la cuestión no se limita a encontrar vulnerabilidades, sino que implica demostrar el cumplimiento de estándares que exigen prácticas de codificación específicas.
Todo esto requiere el cumplimiento de las reglas de codificación que rigen el propio código fuente.
IAST no puede indicar si su código fuente en C evita las construcciones de lenguaje prohibidas por MISRA. No puede aplicar los estándares de codificación CERT. No puede generar los artefactos de evidencia que requieren los auditores y los organismos de certificación. Estas propiedades existen en el código fuente o no existen. Solo el análisis estático del código fuente puede verificarlas. Esta no es una brecha que se pueda solucionar con una mejor instrumentación.
También existe una barrera lingüística más fundamental.
IAST funciona integrando agentes en entornos de ejecución gestionados, como la JVM para Java, el CLR para .NET y plataformas similares.
C, C++, Rust y Ada, los lenguajes que dominan el desarrollo de sistemas embebidos críticos para la seguridad, no cuentan con ese tipo de modelo de instrumentación.
No existe ningún agente IAST para C sin sistema operativo que se ejecute en una ECU automotriz, ni un entorno de ejecución instrumentado para Ada en un sistema de aviónica, ni una cobertura IAST significativa para las bases de código Rust que las agencias gubernamentales estadounidenses están fomentando activamente para el desarrollo de sistemas seguros para la memoria.
Para estos lenguajes y dominios, IAST no es una opción subóptima. Simplemente no es una opción viable.
También cabe destacar una dimensión práctica del rendimiento. La instrumentación IAST introduce una sobrecarga de tiempo de ejecución cuantificable en términos de CPU, memoria y latencia. La magnitud de esta sobrecarga varía enormemente según la herramienta, la aplicación, la carga de trabajo y lo que la instrumentación esté monitorizando.
Los resultados pueden variar, e incluso en algunos casos, en un orden de magnitud. Para sistemas en tiempo real o entornos embebidos con limitaciones de rendimiento, esta variabilidad por sí sola descarta la instrumentación en tiempo de ejecución como estrategia de seguridad principal, independientemente de cualquier argumento sobre la cobertura.
En los sistemas críticos para la seguridad, el problema de los falsos negativos no es un inconveniente, sino un requisito de diseño.
Cuando un fallo de software tiene consecuencias físicas, la cuestión no es solo si tu herramienta de seguridad encuentra vulnerabilidades, sino si puedes demostrar con certeza que no ha pasado por alto ninguna.
Estructuralmente, IAST no puede ofrecer esa garantía. Solo cubre el código que fue probado por evaluadores que no simularon el comportamiento de un atacante durante una ejecución de prueba que no alcanzó los casos límite donde realmente se ocultan los fallos.
No se trata de un problema de configuración de la herramienta, sino de una limitación arquitectónica. El único enfoque que puede proporcionar una cobertura sistemática de todo el código fuente, con conjuntos de reglas documentadas y evidencia auditable, es el análisis estático del código fuente.
El software crítico para la seguridad no se prueba hasta que sea correcto. Se construye en función de ello, con análisis que se ejecutan desde la primera línea de código. Las herramientas de análisis estático de Parasoft, Prueba C / C ++Jtest y dotTEST cubren los estándares importantes en C, C++, Java, C# y VB.NET, incluidos MISRA, AUTOSAR, CERT, CWE, OWASP Top 10, OWASP API Top 10 y DISA ASD STIG.
Para los equipos de sectores regulados, "utilizar IAST en su lugar" no es una alternativa. Es una respuesta evasiva.
Explora Más
Explora nuestra solución Guía de análisis de código estático »
Nada de esto constituye un argumento en contra de IAST. Si estás desarrollando aplicaciones donde las pruebas en tiempo de ejecución son prácticas, se trata de una capa realmente útil. Confirma las predicciones del análisis estático y detecta problemas que este último pasa por alto, en particular vulnerabilidades que solo se manifiestan a través de interacciones específicas en tiempo de ejecución con servidores, bases de datos o servicios de terceros.
Cuando IAST detecta un problema, la respuesta adecuada no consiste simplemente en corregir la instancia específica. ¿Corregir la instancia? Sí. Pero luego hay que rastrear la causa original del problema y eliminarla. Son dos pasos distintos.
El parche soluciona la vulnerabilidad inmediata. El análisis de la causa raíz y cualquier estándar de codificación, patrón de validación o análisis estático que se derive de él cierran la puerta a toda la clase de problemas.
Ese segundo paso es donde reside la verdadera ventaja. Cuando surge una vulnerabilidad, la pregunta de ingeniería correcta no es "¿cómo soluciono esto?", sino "¿en qué otra parte del código fuente se oculta esta misma condición?".
Esa es una pregunta que escuchamos constantemente de desarrolladores y equipos de seguridad que están analizando el problema correctamente. Un único hallazgo de IAST, bien gestionado, justifica la activación de un verificador que no se había ejecutado previamente, o la creación de un verificador personalizado dirigido específicamente al patrón recién descubierto.
Parasoft admite ambos:
El hallazgo que surge durante la ejecución se convierte en la información de entrada que refuerza la configuración del análisis estático en adelante. Ese es el ciclo de retroalimentación que realmente marca la diferencia.
Cuando SAST funciona correctamente, se introducen menos vulnerabilidades en las compilaciones, menos llegan a la integración y menos alcanzan los entornos donde se ejecuta IAST.
Los resultados de IAST se convierten en una señal más significativa y un ruido menos abundante.
El equipo dedica menos tiempo a la priorización y más tiempo al lanzamiento. Las herramientas no compiten entre sí. Son secuenciales: prevención en la fase inicial, confirmación en la fase final.
Hay una cuestión que merece la pena plantear, pero que aún no recibe suficiente atención.
¿Qué sucede con los desafíos estructurales de IAST cuando los agentes de codificación de IA comienzan a generar partes significativas de las bases de código?
Los agentes de IA producen código rápidamente y en grandes cantidades. También producen modos de fallo característicos:
No se trata de errores tipográficos. Son el tipo de problemas estructurales que surgen cuando un agente ha aprendido a producir código que compila y pasa pruebas básicas sin haber interiorizado el razonamiento detrás de las restricciones de seguridad.
IAST necesita que el código se implemente, se instrumente y se pruebe antes de poder encontrar algo.
A medida que aumenta el volumen de código generado por IA, las limitaciones estructurales ya existentes se vuelven más importantes.
El análisis estático, por el contrario, puede integrarse directamente en el ciclo de codificación de la IA, analizando cada archivo generado en el momento de su creación, antes de que se confirme.
A medida que los agentes de codificación de IA se convierten en algo habitual, la necesidad del análisis estático como filtro en ese proceso se fortalece, no se debilita. El principio fundamental es sencillo: al análisis estático no le importa quién escribió el código.
En un mundo ideal, el código generado por IA sería limpio, estaría bien estructurado y libre de problemas de seguridad. Todavía no hemos llegado a ese punto. Los agentes de codificación de IA actuales producen violaciones reales.
A veces se trata de los mismos tipos de infracciones que producen los desarrolladores humanos. Otras veces, de infracciones nuevas, características de cómo los modelos generan código.
La respuesta es la misma independientemente de la fuente. Realiza un análisis estático de todo, de cada commit, de cada persona o máquina.
Lo que hace que esto sea particularmente poderoso en el contexto de Parasoft es que la remediación puede tener en cuenta el cumplimiento, no solo ser genéricamente correcta. No basta con corregir una infracción de una manera que, por casualidad, compile.
Para bases de código que operan bajo los estándares MISRA, AUTOSAR u otros, una corrección que introduce una infracción diferente del mismo estándar, o que simplemente cambia un problema por otro, no se considera una corrección. El agente de corrección de código de Parasoft aborda esto directamente. Corrige los hallazgos en el contexto del estándar específico que se está aplicando y luego vuelve a ejecutar el análisis para verificar que la corrección realmente cumpla con el estándar, en lugar de simplemente eliminar la línea marcada. El objetivo es un código que no solo cambie, sino que cumpla con el estándar de manera demostrable.
Parasoft ha publicado investigaciones al respecto. Un informe técnico que compara Parasoft C/C++test con GitHub Copilot evaluó las correcciones automatizadas para las violaciones de CWE en 1,856 proyectos de código abierto de C/C++.
Las indicaciones de Parasoft, que tienen en cuenta el cumplimiento normativo e incluyen documentación de reglas y razonamiento lógico, superaron al comando genérico Fix de GitHub Copilot en el 64 % de los casos cuando se aplicó el razonamiento y en el 57 % sin él.
La revisión manual confirmó que las correcciones de Parasoft eran más completas, más robustas y se ajustaban de forma más consistente a los estándares de codificación. La diferencia no radica solo en qué herramienta detecta más infracciones, sino en cuál comprende cómo debe ser una corrección correcta en un contexto de cumplimiento específico.
La industria del software ha pasado décadas tratando de probar la calidad al final. Lista de errores de software importantes Es lo suficientemente largo como para dejar claro el punto por sí solo. La seguridad sigue el mismo patrón:
Eso no es un programa de seguridad. Eso es una cinta de correr.
Los equipos que realmente mejoran su seguridad no son los que cuentan con las mejores herramientas de detección. Son los que invierten en escribir mejor código desde el principio, con la aplicación de estándares y el análisis estático integrados donde pueden influir en el código mientras el desarrollador aún tiene el contexto para corregirlo correctamente. El argumento de Deming no era que la inspección fuera inútil, sino que si la inspección es tu principal estrategia de calidad, ya has fracasado.
IAST es una herramienta útil en la cinta de correr. El objetivo es bajarse de la cinta.
Integra la calidad desde el principio. Verifícala durante la ejecución. Y no permitas que nadie te diga que detectar problemas al final sustituye a prevenirlos desde el principio.
SAST (pruebas estáticas de seguridad de aplicaciones) analiza el código fuente sin ejecutarlo, detectando vulnerabilidades en la fase de codificación. IAST (pruebas interactivas de seguridad de aplicaciones) instrumenta una aplicación en ejecución y detecta vulnerabilidades a medida que el código se ejecuta durante las pruebas o la producción. SAST detecta problemas antes de que se implementen. IAST detecta problemas en el código que ya está en ejecución. Ambos métodos detectan problemas reales. Solo SAST puede evitar que se escriban en primer lugar.
No. IAST solo analiza el código que se ejecuta, lo que deja gran parte de la mayoría de los códigos sin examinar. Requiere un conjunto de pruebas para el análisis y un esfuerzo operativo para su instrumentación y mantenimiento. No puede verificar el cumplimiento de estándares de codificación como MISRA, CERT u OWASP. Además, no detecta vulnerabilidades hasta que el código ya está escrito, compilado e implementado, momento en el que la corrección resulta mucho más costosa.
IAST resulta más valioso como capa complementaria sobre SAST en programas de seguridad de aplicaciones donde las pruebas en tiempo de ejecución son viables y ya existe un conjunto de pruebas consolidado. Proporciona una confirmación útil de la explotabilidad real y detecta vulnerabilidades que se manifiestan únicamente a través de interacciones con el servidor en tiempo de ejecución. No es apropiado como estrategia principal o única, y no aporta valor a bases de código orientadas al cumplimiento normativo que requieren evidencia de conformidad del código fuente con estándares como MISRA o CERT.
Parasoft se centra en SAST y las pruebas, no en IAST. Herramientas de análisis estático de Parasoft Cubre C, C++, Java, C# y VB.NET con conjuntos de reglas exhaustivas para estándares de seguridad y cumplimiento.
¿Qué solución SAST es la adecuada para su equipo?
Contenido recomendado
