Mejoras pendientes en nuevas aplicaciones: el software de creación reciente con seguridad de memoria
Un desbordamiento de búfer, un puntero que apunta a memoria ya liberada, una lectura fuera de los lÃmites de un arreglo, son errores que los programadores llevan más de cuatro décadas cometiendo y que siguen abriendo la puerta a ataques capaces de ejecutar código ajeno en nuestros dispositivos. Después de tantos años de parches, auditorÃas y herramientas de análisis, creo que el problema ya no es de disciplina, sino de herramientas. Mi postura es clara: el software nuevo, sobre todo el crÃtico, deberÃa escribirse por defecto en lenguajes con seguridad de memoria, como Rust, Go, Swift, Java o C#, y no en C o C++.
El primer argumento es que una sola clase de errores domina el panorama. Tanto Microsoft como Google han reportado que alrededor del 70 % de sus vulnerabilidades graves proviene de fallos de seguridad de memoria, una cifra que se repite en proyectos tan distintos como Windows, Chrome y Android. Cuando una misma causa explica la mayorÃa de los problemas durante décadas, seguir pidiéndole más cuidado a los humanos es como pedirles a los conductores que nunca se distraigan en lugar de instalar cinturones de seguridad. Los lenguajes con seguridad de memoria no dependen de la atención del programador: el propio lenguaje impide, al compilar o al ejecutar que el código lea o escriba donde no debe. Eliminan la categorÃa de errores en lugar de cazarlos uno por uno.
El segundo argumento es que la evidencia ya demuestra que funciona. El equipo de Android, en Google, empezó a usar Rust en 2019 y, en lugar de reescribir todo lo anterior, se concentró en el código nuevo. Según su propio reporte, la proporción de vulnerabilidades causadas por fallos de memoria bajó de 76 % en 2019 a 24 % en 2024, muy por debajo del 70 % que se considera habitual en la industria. La lección es que no hace falta tirar décadas de código: basta con dejar de agregar código nuevo que nazca inseguro.
El tercer argumento es de responsabilidad y economÃa. Las vulnerabilidades en routers, equipos médicos, vehÃculos e infraestructura pública suelen descubrirse después del despliegue, y corregirlas implica parches, interrupciones y usuarios que nunca actualizan. Prevenir desde el diseño es mucho más barato que remediar en producción. También es más justo: nadie puede auditar el código de su marcapasos ni el del servidor de su banco, asà que la carga de la seguridad deberÃa recaer en quien construye el software, no en quien lo usa.
Los defensores de C y C++ tienen razones: son rápidos, dan control fino del hardware, existe una cantidad enorme de código y de programadores con experiencia, y Rust exige una curva de aprendizaje difÃcil. Además, Rust permite bloques unsafe que reabren parte del riesgo. Son objeciones válidas, pero no cambian la conclusión. Primero, nadie propone reescribirlo todo, solo el código nuevo, con interoperabilidad entre lenguajes para convivir con lo existente. Segundo, en muchos casos el rendimiento es comparable, y cuando no lo es, el costo de una vulnerabilidad explotable suele superar el de unos milisegundos. Tercero, los bloques unsafe son pequeños y localizados, lo que permite auditar unas pocas lÃneas en lugar de millones. Y la idea de que "los buenos programadores no cometen esos errores" la desmienten los equipos más expertos del mundo, que siguen cometiéndolos. Aprender un lenguaje nuevo es un costo único; las vulnerabilidades son un costo recurrente.
Propongo, Que los proyectos nuevos expuestos a internet o que manejen datos sensibles elijan un lenguaje con seguridad de memoria como opción predeterminada y justifiquen por escrito cuando no lo hagan. Que las empresas publiquen hojas de ruta de migración progresiva. Y que las universidades enseñen estos lenguajes y los conceptos de propiedad y gestión de memoria desde los primeros cursos, no como una curiosidad de último año.
No se trata, en definitiva, de elegir un lenguaje favorito ni de militar por una tecnologÃa, sino de sacar la conclusión que los datos ya nos están gritando: si una sola clase de error explica la mayorÃa de las vulnerabilidades graves y sabemos cómo eliminar esa clase de raÃz, seguir tolerándola deja de ser una fatalidad y se convierte en una decisión —y, para quien programa, en una responsabilidad—. Vista asÃ, la discusión no enfrenta a C++ contra Rust: enfrenta la comodidad de repetir lo heredado contra la evidencia de que existen mejores herramientas. Aceptar esa evidencia es barato y reversible; ignorarla se paga en parches, en incidentes y, sobre todo, en la confianza de quienes usan un software que nunca podrán auditar.
El autor es Administrador de base de datos del Instituto Especializado de Análisis, de la Universidad Tecnológica de Panamá
