La revolución silenciosa en los sistemas integrados acaba de hacerse ruidosa. Según un nuevo y apasionante informe de 2025 de RunSafe Security, 80,5% de los ingenieros integrados ahora utilizan herramientas de IA para escribir código, y un asombroso 83,5% ha implementado ese código generado por IA directamente en entornos de producción.
En cualquier otra industria, esto sería una victoria para la productividad. Pero en el mundo de los sistemas integrados (donde el código controla bombas de insulina, armaduras industriales y sistemas de frenado de automóviles) representa una aterradora desvinculación entre la velocidad y la validez.
El informe, titulado “IA en sistemas integrados: la IA está aquí. La seguridad no”, presenta una imagen de una industria en un peligroso punto de inflexión. Los ingenieros escriben código más rápido que nunca, utilizan lenguajes que nunca fueron diseñados para ser seguros y lo implementan en hardware que no se puede parchear fácilmente.
Análisis técnico profundo: por qué se rompe el código “bueno”
La calidad del código no es la principal preocupación. Los LLM generan una sintaxis válida.
El problema es que C y C++ son lenguajes inherentemente inseguros que requieren una perfecta vigilancia de los desarrolladores, algo que los modelos de IA, que son predictores probabilísticos de tokens, no pueden garantizar estructuralmente.
La brecha de seguridad de la memoria
En una aplicación moderna de alto nivel (escrita en Python, Rust o Go), Language Runner maneja la asignación de memoria. Creas un objeto; el sistema encuentra espacio. Dejas de usarlo; el recolector de basura lo libera.
En C/C++ integrado, usted es el recolector de basura. Asigna memoria manualmente (malloc) y la libera manualmente (free). Si comete un error, no sólo obtendrá un error; creas una vulnerabilidad.
El informe RunSafe destaca que este enfoque de “transmisión manual” está chocando con la velocidad de la IA. Cuando una IA genera un analizador de 50 líneas para una secuencia JSON, a menudo utiliza patrones C estándar y eficientes. Pero rara vez considera el contexto del diseño de la memoria.
- Desbordamientos de búfer: la IA escribe datos en un búfer sin verificar rigurosamente si los datos encajan. En una aplicación de escritorio, esto bloquea el programa. En un controlador integrado sin una MMU (Unidad de gestión de memoria), esto sobrescribe el puntero de instrucción y le da al atacante el control del dispositivo.
- Use-After-Free (UAF): la IA libera correctamente un puntero pero deja una referencia pendiente en otra parte del código. Posteriormente, la lógica intenta acceder a esa memoria liberada. Si un atacante ha rociado el montón con datos maliciosos, ahora es dueño de la ejecución.
El multiplicador de superficie de ataque
Las estadísticas del informe son alarmantes debido a la superficie. El 53% de los encuestados citó la seguridad como su principal preocupación, pero el 91% está aumentando la inversión en seguridad integrada. Saben que la ola se acerca.
El desarrollo tradicional actúa como un acelerador natural del volumen de código. Un ingeniero humano solo puede escribir un número determinado de líneas de C++ por día, y buenos equipos revisan ese código. La IA quita el acelerador. La industria ahora está inundando bases de código heredadas con grandes cantidades de lógica nueva y no verificada.
Si 1 de cada 10.000 líneas de código humano tiene un defecto crítico de memoria y la IA permite a los ingenieros escribir 100.000 líneas en el tiempo que llevó escribir 10.000, la industria no sólo ha aumentado la productividad; ha aumentado la densidad de vulnerabilidades latentes en un orden de magnitud.
Historia contextual: el patrón de negligencia
La industria ha visto esta película antes, sólo que en pantallas diferentes.
A principios de la década de 2000, la fase “Conectar todo” del auge de IoT condujo a la botnet Mirai. Los fabricantes se apresuraron a colocar pilas de IP en cámaras y DVR sin pensar en contraseñas predeterminadas o puertos telnet abiertos. El resultado fue una infraestructura DDoS masiva construida a partir de tostadoras y cámaras web comprometidas.
En la década de 2010, la industria automotriz se apresuró a agregar infoentretenimiento y conectividad a los automóviles. El resultado fue el hack del Jeep Cherokee, donde los investigadores cortaron de forma remota la transmisión de un vehículo en una carretera porque el sistema de entretenimiento podía comunicarse con el bus CAN.
Ahora, en 2025, volverá a suceder con la generación de código. El informe RunSafe señala que el 73 % de los ingenieros califican el riesgo del código de IA como “moderado o superior”, sin embargo, las cifras de implementación (83,5 %) muestran que están procediendo de todos modos.
La presión económica para ofrecer funciones “inteligentes” (mantenimiento predictivo, procesamiento de IA en el borde, interfaces de voz) está anulando la disciplina de ingeniería necesaria para protegerlas.
La contramedida: aleatorización de funciones de tiempo de carga (LFR)
Si confiar en el código es imposible (porque hay demasiado) y reescribir 30 años de C++ en Rust de la noche a la mañana es inviable, ¿cuál es la defensa?
El informe apunta hacia la Resiliencia en tiempo de ejecución. Si asume que el error existe, debe hacerlo inexplotable.
Una de las técnicas más efectivas para esto en el espacio integrado es Aleatorización de funciones en tiempo de carga (LFR).
Cómo funciona
En una compilación de firmware estándar, cada función reside en una dirección estática y conocida. calculate_voltage() siempre puede estar en 0x08001234.
A los atacantes les encanta esto. Para crear un exploit (como la programación orientada al retorno o ROP), necesitan saber exactamente dónde saltar para ejecutar el código que desean. Encadenan pequeños fragmentos de código existente (gadgets) para crear un programa malicioso.
LFR rompe esta cadena.
- Tiempo de compilación: el compilador emite código que no salta a direcciones absolutas. En lugar de ello, salta a un “código auxiliar” o a una tabla de búsqueda.
- Tiempo de carga: cuando el dispositivo arranca, el cargador seguro baraja el mazo. Asigna aleatoriamente direcciones de memoria reales a todas las funciones.
- Parches: el cargador actualiza la tabla de búsqueda o parchea el binario en la memoria para que las llamadas sigan funcionando.
¿El resultado? Cada vez que el dispositivo se reinicia (o cada vez que se actualiza el firmware, según la implementación), el mapa de memoria cambia. Un exploit que funciona en el Dispositivo A bloqueará el Dispositivo B. Un exploit que funcionó ayer no funcionará después de reiniciar.
La implementación patentada de esta tecnología por parte de RunSafe está ganando terreno porque no requiere reescribir el código fuente. Lo aplicas a nivel binario. Esto es crucial para el 60% de los encuestados que ya están intentando utilizar protecciones en tiempo de ejecución.
Análisis prospectivo: perspectivas a cinco años
El informe de 2025 es una instantánea de un período de transición. El sector se encuentra actualmente en la fase del “salvaje oeste” de generación de códigos de IA.
En los próximos cinco años se esperan tres cambios importantes:
- El auge de la seguridad basada en silicio: Las mitigaciones de software como LFR serán efectivamente obligatorias. Las regulaciones (similares a la Ley de Resiliencia Cibernética de la UE) probablemente exigirán que los dispositivos de infraestructura crítica posean capacidades de aleatorización binaria.
- La transición a Rust: Si bien la IA escribe C++ fácilmente, también escribe Rust fácilmente. La fricción para cambiar a lenguajes seguros para la memoria disminuirá a medida que la IA maneje el texto estándar. Sin embargo, esto sólo protege el código nuevo. Los miles de millones de líneas del legado C/C++ permanecen.
- Cambio de responsabilidad: a medida que el código generado por IA causa fallas físicas (por ejemplo, un brazo robótico que se mueve demasiado rápido, un sistema de administración de batería falla), la conversación legal pasará de “errores de software” a “responsabilidad del producto”. Si un fabricante utilizó IA para generar código crítico para la seguridad sin revisión humana o protección del tiempo de ejecución, eso es negligencia.
El resultado final
El informe RunSafe Security 2025 no es sólo una colección de encuestas; es una señal de advertencia. La industria ha descorchado la botella de la productividad de la IA y ya no hay vuelta atrás.
El gran volumen de código que se produce significa que la revisión manual es matemáticamente imposible a escala. Ya no es posible pretender que se puedan detectar todos los errores. El único camino viable a seguir es asumir que el código está roto y construir sistemas que se nieguen a permitir que rompa la máquina.
Para el ingeniero integrado en 2025, el trabajo ya no es solo escribir C. Es diseñar los campos de contención que evitan que C dañe a nadie.
Apéndice matemático: la probabilidad de explotación
Modelar el valor de LFR requiere calcular la probabilidad P de un exploit exitoso de la cadena ROP. Una cadena estándar requiere k gadgets. En un mapa de memoria estática, la probabilidad de encontrar el dispositivo i en una ubicación conocida es 1.
La probabilidad de un exploit estático es efectivamente del 100%.
Con LFR, si hay N posibles ubicaciones (ranuras) para una función y el atacante tiene una probabilidad de 1 en N de adivinar el desplazamiento correcto para cada dispositivo independiente (modelo simplificado), la probabilidad cae aproximadamente a 1 dividido por N elevado a k.
La probabilidad es efectivamente cero.
Incluso con una entropía modesta (N=256) y una cadena corta (k=3), la dificultad se dispara desde la certeza a una entre 16 millones.
Fuentes (6)
- runsafesecurity.com RunSafe Security Blog
- themanufacturingconnection.com The Manufacturing Connection
- vmblog.com VMblog 2025 Predictions
- runsafesecurity.com Medical Device Cybersecurity Index 2025
- news.mit.edu MIT News: Memory Safety Tipping Point
- appsecengineer.com Defending Memory Corruption
🦋 Discusión en Bluesky
Discutir en Bluesky