A partir del informe titulado Product Security Bad Practices (Malas prácticas en la seguridad de los productos), la CISA (Cybersecurity and Infrastructure Security Agency), agencia federal estadounidense responsable de la ciberseguridad y la infraestructura de redes de datos en todos los niveles del gobierno, insta a las empresas productoras de software a abandonar el uso de los lenguajes de programación C/C++, y a implementar otras medidas que puedan reducir el riesgo para el cliente, no solamente en los programas para el gobierno, sino para cualquier cliente en general.

Conjuntamente, la CISA y el FBI han establecido la fecha límite del 1 de enero de 2026 para el cumplimiento de las directrices de seguridad expuestas en el informe, aunque este no constituye una norma obligatoria, sino una serie de directrices y recomendaciones en forma de guía.

Aunque no se menciona de manera directa que el uso de lenguajes «inseguros» podría descalificar a los fabricantes para contratos gubernamentales, y el informe es no vinculante, el mensaje es claro: tales prácticas son inadecuadas para cualquier trabajo clasificado como relevante para la seguridad nacional.

Dentro del documento, ambas agencias han destacado específicamente el software on-premises, los servicios en la nube y el software como servicio.

Lenguajes de Programación Inseguros y sus Riesgos

Desde hace muchos años, la forma en la que los lenguajes de programación C/C++ gestionan la memoria, ha sido objeto de debate y de crítica a estos mismos lenguajes y, de forma más reciente, de su uso mismo para el desarrollo de sistemas y aplicaciones.

La aparición de alternativas como Rust, que inciden precisamente en el ámbito de la seguridad y, más específicamente, en cómo gestionan la memoria RAM, contribuye en gran medida a alimentar este debate y a las medidas como la que estamos explicando en estas líneas.

Y el gran problema de C/C++ en la gestión de la memoria es que no disponen de herramientas que, por defecto, hagan tareas de seguridad de forma automática en la memoria utilizada como, por ejemplo, con el uso de punteros, un mecanismo que, técnicamente, se llama “recolección de basura”, y que en faltar, facilita que las aplicaciones sufran de errores de buffer overflow entre otros.

Dichos errores, a la postre, pueden ser aprovechados por ciberdelincuentes para forzar la escalada de privilegios en el sistema, o inyectar código arbitrario, que se ejecuta en el ordenador atacado gracias a estos errores de memoria, lo que lleva a abrir las puertas del sistema informático a un atacante, robando información o secuestrándolo.

En cambio otros lenguajes de programación sí que integran mecanismos para gestionar de forma automática la memoria, evitando estos problemas.

El porqué de que unos tengan estos mecanismos y otros no, es simple: los que no integran estos mecanismos (que dejan a los desarrolladores la opción de implementarlos manualmente), ofrecen una mayor flexibilidad y potencia para llevar a cabo prácticas con la memoria que en los otros casos no están permitidas, dando con ello mayor potencial al programador.

El informe describe los lenguajes de programación con seguridad de memoria deficiente como “peligrosos y que incrementan significativamente el riesgo para la seguridad nacional”.

Requisitos para los Fabricantes de Software para 2026

Para el 1 de enero de 2026, y según el informe conjunto de la CISA y el FBI, los fabricantes deberán:

• Tener una hoja de ruta de seguridad de memoria para los productos existentes escritos en lenguajes con seguridad de memoria deficiente. Esta debe «detallar el enfoque priorizado del fabricante para eliminar las vulnerabilidades de seguridad de memoria en los componentes de código prioritarios«.
• Demostrar cómo la hoja de ruta de seguridad de memoria reducirá las vulnerabilidades de seguridad de memoria.
• Demostrar un «esfuerzo razonable» en el seguimiento de la hoja de ruta.
• Alternativamente, los fabricantes deberán utilizar un lenguaje de programación con mecanismos de seguridad de memoria incorporados.

La lista de lenguajes de programación con seguridad de memoria incorporada aprobados por la NSA consiste en Python, Java, C#, Go, Delphi/Object Pascal, Swift, Ruby, Rust, y Ada.

Otras Prácticas de Riesgo Identificadas

Además de las recomendaciones sobre el uso de lenguajes de programación, el informe identifica otras prácticas que comportan riesgos para la seguridad de los sistemas informáticos, y que consisten en:

• Permitir la entrada de usuario directamente en el contenido crudo de una consulta de base de datos SQL.
• Permitir la entrada de usuario directamente en el contenido crudo de un comando del sistema operativo.
• Utilizar contraseñas predeterminadas, recomendando en su lugar que los fabricantes aseguren que su producto proporcione contraseñas iniciales aleatorias y únicas por instancia, requieran que los usuarios creen nuevas contraseñas al inicio del proceso de instalación, exijan acceso físico para la configuración inicial y transicionen las implementaciones existentes lejos de las contraseñas predeterminadas.
• Lanzar un producto que contenga una vulnerabilidad del Catálogo de Vulnerabilidades Explotadas Conocidas (KEV) de CISA.
• Usar software de código abierto con vulnerabilidades explotables conocidas.
• No aprovechar la autenticación multifactor.
• Carecer de la capacidad para recopilar evidencias de intrusiones si ocurre un ataque.
• No publicar CVE oportunos incluyendo la Enumeración de Debilidades Comunes (CWE), que indica el tipo de debilidad subyacente al CVE.
• No publicar una política de divulgación de vulnerabilidades.

El informe completo incluye los pasos recomendados que las organizaciones pueden utilizar para cumplir con las directrices de las agencias.