ha tenido que matizar para no pasarse de frenada

En el mundo del incremento de software, las vulnerabilidades de memoria siguen siendo una de las principales amenazas para la seguridad informática. A pesar de los avances en la creación de lenguajes de programación más seguros, gran parte del software crítico aún depende de tecnologías con décadas de decadencia, como C y C++.

Pero, aunque éstos han sido la columna vertebral de muchos sistemas informáticos modernos, su dirección manual de memoria los hace propensos a errores que pueden ser aprovechados por atacantes.

Oportuno a estos peligros, los Estados Unidos se han tomado la programación es una cuestión de seguridad franquista: hace un año, la Oficina del Director Doméstico de Ciberseguridad (ONCD) de los EE.UU. emitía un noticia instando a los programadores a portar alrededor de 'lenguajes de programación seguros en memoria' con el objetivo de evitar vulnerabilidades que pudieran comprometer datos sensibles y afectar infraestructuras nacionales.

Sin bloqueo, la acogida de estos 'lenguajes seguros' se enfrenta obstáculos importantes: la efectividad es que una gran cantidad de software crítico ya está escrito en C y C++, y su migración completa a lenguajes seguros no es siempre viable a corto plazo.

El desafío de reemplazar C y C++ con Rust

Rust ha sido promocionado como una alternativa para acortar la 'superficie de ataque' del software crítico. Sin bloqueo, la transición no es sencilla: la mayoría de los sistemas operativos, compiladores, servidores DNS, proxies inversos y software criptográfico siguen estando escritos en C/C++.

Encima, está el problema de la desliz de formación: empresas y universidades continúan formando a programadores en estos lenguajes, ya que dominar C/C++ sigue siendo una tiento enormemente demandada en la industria...

...y la mayoría de los desarrolladores que han trabajado con C y C++ durante primaveras no están dispuestos a formarse un nuevo lengua desde cero, ya que esto implica una curva de educación significativa.

Por otra parte, el debate sobre Rust ha recordado a muchos expertos la advertencia de Joel Spolsky, fundador de Stack Overflow, sobre que reescribir un código saco desde cero es una de las peores decisiones que puede tomar una empresa: perder primaveras de optimización y corrección de errores para despuntar desde cero con una nueva tecnología puede resultar contraproducente.

Pasito a paso

Delante este panorama, la Agencia de Seguridad de Infraestructura y Ciberseguridad de Estados Unidos (CISA) ha actualizado hace un par de semanas sus recomendaciones sobre prácticas inseguras en el incremento de software, estableciendo un nuevo enfoque sucesivo para la migración a lenguajes más seguros.

CISA reconoce que la transición alrededor de lenguajes seguros no es una tarea sencilla: reconoce explícitamente que muchas compañías han construido sus productos en lenguajes como C y C++ durante décadas, y reescribir millones de líneas de código de un día para otro es prácticamente irrealizable.

Por ello, la agencia ha propuesto un maniquí de migración progresiva, que permite a los fabricantes mejorar la seguridad de sus productos sin comprometer su estabilidad o funcionalidad. Este enfoque consta de tres fases esencia:

1. A corto plazo: Implementar controles en hardware o compiladores para acortar los errores de dirección de memoria sin requisito de modificar el código existente, y aplicar técnicas para mitigar vulnerabilidades de memoria en tiempo de ejecución.
2. A medio plazo: Consolidar que todo nuevo código se desarrolle en lenguajes seguros, como Rust o Go, y mejorar las prácticas de codificación en lenguajes inseguros, minimizando el uso de funciones propensas a errores como 'strcpy' o 'malloc' sin verificaciones adecuadas.
3. A holgado plazo: Reescribir progresivamente módulos críticos en lenguajes seguros para la memoria, y priorizar la conversión de componentes enormemente expuestos a ataques, como aquellos responsables de comunicaciones en red, autenticación y oculto.

Hojas de ruta

Uno de los cambios más relevantes en las recomendaciones de CISA es la exigencia de que los proveedores de software publiquen una hoja de ruta clara y accesible sobre cómo planean encarar los riesgos de seguridad de memoria en sus productos. Este documento debe incluir:

• Un plan de mitigación de vulnerabilidades en componentes críticos del código, como aquellos expuestos a redes o responsables de operaciones criptográficas.
• Una táctica de matanza progresiva del uso de lenguajes inseguros, asegurando que nuevos desarrollos se realicen en entornos más seguros.
• Pruebas de compromiso con la seguridad, demostrando que la empresa está implementando medidas concretas para acortar estos riesgos.

CISA ha establecido que los fabricantes que no cuenten con esta hoja de ruta ayer de 2026 estarán incurriendo en una ejercicio de seguridad inaceptable. No obstante, la agencia ha aclarado que esta obligación no se aplicará a productos cuyo soporte finalice ayer de 2030, permitiendo que la industria haga la transición de modo ordenada y sin afectar el mantenimiento de productos en escalón final de vida útil.

Imagen | Marcos Merino mediante IA

En Genbeta | El kernel de Linux lleva desarrollándose 34 primaveras. Un debate sobre lenguajes de programación está logrando intoxicar el esquema