Los mandatos de código seguro en memoria están transformando cómo Google, Microsoft y el kernel de Linux escriben software de sistemas

En febrero de 2024, la Oficina del Director Nacional Cibernético de la Casa Blanca publicó un informe de título poco glamoroso y argumento contundente: aproximadamente el 70 por ciento de las vulnerabilidades que Microsoft y Google corrigen cada año tienen su origen en errores de seguridad de memoria — desbordamientos de búfer (buffer overflow), uso después de liberación (use-after-free) y lecturas fuera de límites — exactamente la clase de error que C y C++ facilitan escribir y dificultan detectar. Dos años después, ese argumento dejó de ser un punto de discurso y se convirtió en una partida concreta en cómo los mayores proveedores de software planifican el trabajo nuevo.

Los propios informes de transparencia de Google sobre Android son la evidencia más clara de que esto no es solo retórica. En 2019, los errores de seguridad de memoria representaban alrededor del 76 por ciento de las vulnerabilidades graves de Android. Según los informes más recientes, esa proporción ha caído a poco más del 20 por ciento — no porque se haya reescrito el código antiguo en C y C++, sino porque la política cambió: el código nuevo añadido a Android desde 2019 utiliza por defecto lenguajes seguros en memoria, principalmente Rust y Kotlin, y la tasa de vulnerabilidades en ese código nuevo se ha mantenido cerca de cero. La conclusión de Google, expresada claramente en su propio blog de seguridad, es que el riesgo de una base de código es proporcional a la cantidad de código nuevo inseguro que se sigue escribiendo, no al tamaño total de la base de código.

Dónde están ocurriendo realmente las reescrituras

El kernel de Linux es el caso de prueba más relevante, porque los errores del kernel son el objetivo de mayor valor en la industria — un solo fallo de seguridad de memoria en un controlador puede convertirse en un escape de sandbox o en un compromiso total del sistema. El soporte de Rust se integró en la rama principal del kernel a finales de 2022, y para 2026 ya no es una infraestructura experimental. Hoy existen controladores de producción en Rust para controladores de almacenamiento NVMe, para el mecanismo Binder IPC de Android — una de las superficies del kernel más atacadas en cualquier teléfono Android — y para las GPU de Apple Silicon a través del controlador AGX del proyecto Asahi Linux. Ninguno de estos sustituye por completo el código C existente; son subsistemas nuevos o reescrituras de componentes específicos propensos a ataques, elegidos porque están directamente en la ruta de entradas no confiables.

Microsoft ha sido más discreta en su comunicación pública, pero igual de activa internamente. El CTO de Azure, Mark Russinovich, ha declarado públicamente que los nuevos proyectos de sistemas en Microsoft utilizan Rust por defecto salvo que haya una razón específica para no hacerlo, y partes de la pila de renderizado de texto y fuentes de Windows — históricamente una fuente rica de errores de ejecución remota de código porque las fuentes son entradas no confiables controladas por el atacante y analizadas en lo profundo del kernel — se han reescrito en Rust bajo el nombre DWriteCore. El análisis de fuentes es un ejemplo de manual de por qué esto importa: es exactamente el tipo de código que toma bytes enviados por un atacante y realiza aritmética de punteros sobre ellos.

Chrome ha adoptado un enfoque más acotado pero igualmente revelador. En lugar de una reescritura total, Google ha introducido Rust en analizadores de alto riesgo específicos — códecs de imagen, JSON, cierto manejo de protocolos de red — mientras mantiene la mayor parte del C++ de Chromium intacto y lo refuerza con técnicas como MiraclePtr, que convierte los errores use-after-free en fallos seguros en lugar de corrupción de memoria explotable. Ese es el camino intermedio realista para una base de código de treinta millones de líneas: analizadores nuevos en Rust, código antiguo reforzado en vez de reescrito.

Por qué C y C++ no van a desaparecer

Nada de esto equivale al fin de C y C++. La economía de una reescritura total no funciona: décadas de código probado y optimizado en rendimiento, enormes reservas de ingenieros contratables en C/C++ y cadenas de herramientas construidas alrededor de esos lenguajes para todo, desde firmware embebido hasta motores de videojuegos. Lo que ha cambiado es más acotado y más duradero que una guerra de lenguajes — es una política sobre dónde se escribe el código nuevo, aplicada selectivamente a los componentes que enfrentan directamente entradas no confiables: analizadores, controladores, pilas de red, cualquier cosa que toque un flujo de bytes desde fuera del límite de confianza.

El riesgo nuevo que esto crea está en las costuras. Cada componente en Rust incrustado dentro de una base de código C/C++ más grande necesita un límite FFI (interfaz de función externa), y los límites FFI son precisamente donde las garantías de seguridad de Rust dejan de aplicarse — un bloque unsafe en el lado de Rust, o una función que llama desde C pasando un puntero incorrecto, reintroduce exactamente la clase de error que la reescritura debía eliminar. Los equipos de seguridad tanto de Google como de Microsoft han señalado la revisión de los límites FFI como el próximo problema difícil, no como uno resuelto.

Qué significa esto si no estás construyendo un kernel

La mayoría de los equipos de ingeniería no mantienen un sistema operativo ni un navegador, pero la lección subyacente se generaliza directamente:

• El código nuevo que analiza entradas no confiables es donde esta política debería aplicarse primero. Si en 2026 estás escribiendo un analizador, un deserializador o un manejador de protocolo nuevo, optar por defecto por Rust, Go u otro lenguaje seguro en memoria es mucho más fácil de justificar ante un revisor de seguridad que hace cinco años — las herramientas, el ecosistema de bibliotecas y el mercado de contratación han madurado.
• El código C/C++ heredado que no puedes reescribir debería obtener cobertura de sanitizers y fuzzing, no un proyecto de reescritura. AddressSanitizer, MemorySanitizer y el fuzzing continuo (libFuzzer, OSS-Fuzz) detectan las mismas clases de errores que eliminaría una reescritura, a una fracción del costo de ingeniería, y funcionan hoy mismo sobre código que no planeas tocar.
• Si vendes software al gobierno federal de Estados Unidos, revisa el estado de tu compromiso con Secure by Design de CISA. Más de 300 proveedores lo han firmado, y el compromiso incluye publicar una hoja de ruta de seguridad de memoria — no cumplimiento total desde el primer día, sino un plan público con un cronograma. Si tu empresa es firmante y no ha publicado esa hoja de ruta, es una brecha que un auditor o el equipo de seguridad de un cliente eventualmente preguntará.
• Trata cada límite FFI nuevo como un artefacto de seguridad revisable, no como un detalle de implementación. Si un módulo en Rust y un módulo en C se comunican entre sí, ese límite merece el mismo escrutinio que recibiría un analizador nuevo, porque es exactamente donde terminan las garantías de seguridad.