La seguridad de memoria ahora es un problema de seguridad nacional: por qué Estados Unidos y la UE quieren que los desarrolladores dejen de escribir en C
En febrero de 2024, la Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. publicó un informe de 19 páginas titulado "El caso de las hojas de ruta para la seguridad de la memoria". La Oficina del Director Cibernético Nacional de la Casa Blanca lo siguió con un informe técnico instando a los fabricantes de software a eliminar las vulnerabilidades de seguridad de la memoria. El Centro Nacional de Seguridad Cibernética del Reino Unido, la BSI de Alemania y la Dirección de Señales de Australia lo cofirmaron. El mensaje de las cinco agencias fue idéntico: dejen de escribir software crítico para la seguridad en C y C++.
No se trata de una posición marginal entre académicos que prefieren Haskell. Es la política de seguridad coordinada de las principales agencias de inteligencia y ciberseguridad del mundo, respaldada por dos décadas de datos de vulnerabilidades, y está empezando a cambiar lo que realmente se envía de software.
Qué significa seguridad de memoria
La seguridad de memoria es la propiedad de que un programa no puede leer ni escribir memoria fuera de los límites previstos, acceder a memoria liberada ni usar valores no inicializados. Los lenguajes aplican la seguridad de memoria ya sea mediante recolección de basura (Java, Python, Go) o mediante reglas de propiedad estática aplicadas en tiempo de compilación (Rust). C y C++ no proporcionan ninguna de las dos: el programador es responsable de gestionar la memoria correctamente y el compilador no verifica la corrección.
La consecuencia es una clase de errores que persiste desde la creación de C en 1972: desbordamientos de búfer, vulnerabilidades de use-after-free, desreferencias de puntero nulo, corrupción del heap y confusión de tipos. No son casos extremos exóticos: son la clase de vulnerabilidad más explotada en la naturaleza, representando constantemente el 60-70% de los CVEs críticos en proyectos de software importantes.
El Centro de Respuesta de Seguridad de Microsoft informó en 2019 que aproximadamente el 70% de todos los CVEs en productos de Microsoft en los últimos 12 años eran problemas de seguridad de memoria. Project Zero de Google informó en 2020 que el 67% de los errores de alta gravedad de Chrome estaban relacionados con la seguridad de memoria. Ambas cifras se han mantenido obstinadamente consistentes hasta 2026 a pesar de una inversión significativa en herramientas (fuzzing, sanitizadores, análisis estático) porque el problema subyacente es el propio modelo del lenguaje, no la calidad insuficiente de los programadores que lo utilizan.
La escala del problema heredado
La gravedad de la situación actual depende de cuánta infraestructura crítica se ejecuta en código C. El kernel de Linux (la base de la mayoría de servidores, dispositivos Android, hardware IoT y sistemas embebidos) es aproximadamente 97% C. La biblioteca OpenSSL que asegura la mayor parte del tráfico HTTPS es C. SQLite, la base de datos más implementada del mundo, es C. El motor JavaScript V8 que ejecuta la mitad de la navegación web mundial es C++. Los kernels de Windows, macOS e iOS contienen decenas de millones de líneas de C y C++.
Reescribir cualquiera de estos no es un proyecto de varios meses. El kernel de Linux tiene aproximadamente 30 millones de líneas de código, con contribuyentes de miles de organizaciones y un proceso de cambios que se mueve a una velocidad geológica por diseño. La base de código de Google Chrome es de 40 millones de líneas. Preguntar "¿por qué no simplemente reescribirlo en Rust?" malinterpreta la escala: a una tasa de reescritura de 1 millón de líneas por año por equipo, una reescritura completa de la base de código lleva décadas e introduce nuevos errores en cada paso.
El enfoque práctico es el reemplazo incremental: reescribir primero los componentes de mayor riesgo (análisis sintáctico, manejo de entrada de red, criptografía), usar interoperabilidad de lenguajes para ejecutar módulos Rust junto a C, y aceptar que el sustrato heredado de C existirá durante 20-30 años mientras se aísla progresivamente.
La trayectoria de Rust
Rust, lanzado por primera vez en 2015 por Mozilla, es el lenguaje de sistemas seguro en memoria principal que se está adoptando para esta transición. Su sistema de tipos de propiedad y préstamo previene toda la clase de errores de seguridad de memoria en tiempo de compilación, sin sobrecarga de recolección de basura y con rendimiento cercano a C. La desventaja es una curva de aprendizaje pronunciada: el compilador de Rust rechaza código que un compilador de C aceptaría, porque el compilador de Rust demuestra una corrección que C deja al programador.
La curva de adopción es ahora lo suficientemente pronunciada como para representar un cambio estructural. Google ha reescrito partes significativas de las pilas de Bluetooth y WiFi de Android en Rust; el equipo de Android informó en 2024 que el código nuevo en lenguajes seguros en memoria redujo la tasa de CVE de seguridad de memoria para esos componentes a casi cero, mientras que los componentes heredados de C mantuvieron su tasa histórica de vulnerabilidades. El kernel de Linux aceptó formalmente Rust como segundo lenguaje de implementación en 2022, y los primeros controladores Rust se fusionaron en el kernel principal.
El equipo de Windows de Microsoft está reescribiendo componentes del kernel de Windows en Rust, con el objetivo a largo plazo de evitar que nuevos errores de seguridad de memoria entren en la base de código del kernel. La guía de la NSA de 2022 nombró específicamente Rust, Swift, Go, Kotlin y Java como lenguajes preferidos para nuevo desarrollo en contextos de seguridad nacional. La Ley de Ciberresiliencia de la UE, que entró en vigor en 2025, exige que los fabricantes de productos con elementos digitales demuestren prácticas "seguras por diseño", un lenguaje legal que implícitamente penaliza los lenguajes inseguros en memoria en contextos críticos de seguridad.
Lo que "seguro en memoria" no resuelve
El impulso político hacia lenguajes seguros en memoria está bien fundamentado pero a veces se vende en exceso. La seguridad de memoria previene una clase específica de errores, pero no previene errores lógicos, fallos de autenticación, vulnerabilidades de inyección o errores de implementación de criptografía. Un programa Rust puede tener una vulnerabilidad de inyección SQL tan fácilmente como un programa C. Un programa Go puede tener un error de lógica de negocio que permita escalada de privilegios. La seguridad de memoria es una condición necesaria para la seguridad, no suficiente.
También hay una distinción significativa entre Rust "seguro" e "inseguro". La biblioteca estándar de Rust contiene bloques unsafe (inseguros), secciones donde el programador desactiva explícitamente las comprobaciones de propiedad para código crítico de rendimiento. Estas regiones inseguras deben verificarse manualmente y son posibles vulnerabilidades en ellas. Por ejemplo, la condición de carrera CVE-2022-21658 en la biblioteca estándar de Rust existía en una implementación de std::fs revisada cuidadosamente. Rust hace que el código inseguro sea raro y altamente visible, pero no lo elimina.
El argumento de rendimiento contra los lenguajes seguros en memoria se ha resuelto en gran medida empíricamente. En la mayoría de las cargas de trabajo, Rust rinde dentro del 5-15% del código C equivalente, y en algunos benchmarks supera a C porque el compilador puede hacer optimizaciones más agresivas cuando ha demostrado garantías de alias y duración. La sobrecarga restante se da principalmente en casos patológicos, no en el tipo de código de sistema que maneja paquetes de red, operaciones del sistema de archivos o análisis de protocolos.
Los próximos diez años
La presión gubernamental está teniendo efectos medibles. La iniciativa Secure by Design de CISA, lanzada en 2023, ha recogido compromisos de más de 200 grandes proveedores de software para crear hojas de ruta de seguridad de memoria, planes concretos para migrar bases de código específicas fuera de C y C++ en un cronograma publicado. Los primeros informes anuales de progreso de esos proveedores mostraron un movimiento modesto pero real: nuevos módulos en Rust, APIs inseguras obsoletas, migración de componentes de análisis de alto riesgo.
El cronograma realista para reducir significativamente las vulnerabilidades de seguridad de memoria en la infraestructura crítica es de 15 a 20 años. El código que se escribe hoy en Rust estará en producción durante décadas; el C heredado que aún se ejecuta será la fuente de vulnerabilidades críticas durante un período equivalente. La pregunta de política no es si hacer esta transición (la evidencia es abrumadora de que C y C++ crean un riesgo de seguridad inaceptable a escala), sino con qué agresividad impulsar la velocidad de transición dados los costos de ingeniería y los riesgos de introducir nuevos defectos durante la migración.
Lo que ha cambiado es que ahora es una cuestión de política, no académica. Cuando CISA llama a algo un problema de seguridad nacional y la Casa Blanca firma un informe técnico, siguen los requisitos de adquisición y las regulaciones. El impulso detrás de la adopción de lenguajes seguros en memoria ya no está impulsado solo por la preferencia del desarrollador: se está codificando en contratos gubernamentales, reglas de responsabilidad de productos de la UE y requisitos de seguros. C y C++ seguirán en uso durante décadas, pero su posición como opción predeterminada para nuevos sistemas críticos de seguridad ha terminado.