De todas las cosas que esperaba leer en mi feed matutino de noticias tecnológicas, un informe de la Casa Blanca de EE. UU. que afirmaba que las empresas tecnológicas y los gobiernos deben dejar de usar ciertos lenguajes de programación para combatir el cibercrimen no estaba en lo más alto de mi lista. Pero eso es exactamente lo que ha sucedido y el documento en cuestión, Back to the Building Blocks, expone los cambios necesarios y las razones detrás de ellos.
Lo primero que hay que eliminar, según el informe, es el uso de lenguajes de programación que no sean seguros para la memoria para crear las aplicaciones y las bases de código de las que dependen los sistemas críticos a gran escala. Los lenguajes como C y C++ se clasifican como inseguros para la memoria ya que no tienen un sistema automático para gestionar el uso de la memoria; en cambio, corresponde a los propios programadores evitar problemas como el desbordamiento del búfer, ya sea comprobando el código directamente o utilizando aplicaciones adicionales.
Agencias como la NSA, CISA y el FBI recomiendan el uso de C#, Python y Rust, ya que todos se consideran seguros para la memoria. Reescribir cada pieza de software crítico es una tarea monumental y el informe sugiere que incluso reescribir un puñado de bibliotecas pequeñas ayudará. Por lo menos, todos nuevo Las aplicaciones deben desarrollarse utilizando un lenguaje seguro para la memoria.
Y no se trata sólo de software, ya que elegir el hardware adecuado también es muy importante. Elija cualquiera de los últimos procesadores de AMD, Intel, Nvidia o Qualcomm y verá que vienen con todo tipo de funciones para mejorar la seguridad de su memoria. Un ejemplo de ello es la extensión de etiquetado de memoria que verifica si en el código se abordan las ubicaciones de memoria correctas. Por supuesto, su uso tiene un impacto en el rendimiento, pero esto se aplica a todas estas medidas.
El informe continúa afirmando que los desarrolladores deberían confiar en los llamados métodos formales, que son técnicas matemáticas para diseñar, escribir y probar código, que actúan como un medio confiable para garantizar que las aplicaciones sean lo más sólidas posible.
Sin embargo, noté que había un área que no se cubrió en el informe y es el uso de IA generativa para crear código solo a partir de unas pocas palabras de entrada. Dichos modelos han sido entrenados en ejemplos de código que ya existen, por así decirlo, y si mucho de eso no es seguro para la memoria o contiene varias vulnerabilidades, entonces hay una buena posibilidad de que el código de IA también lo haga.
Esta fue una oportunidad perdida por parte del gobierno de EE. UU. para resaltar los riesgos de usar IA generativa de esta manera y, si no se aborda adecuadamente, podríamos llegar a un punto en el que tales modelos serían casi imposibles de desentrañar, porque a medida que los modelos continúan entrenándose En el código existente, existe una mayor probabilidad de que la capacitación se vea contaminada por el código de IA, que se construye sobre sí mismo, sin eliminar nunca las vulnerabilidades.
Un desafío importante que señala el informe es cómo se mide qué tan cibersegura es una aplicación o código base. Incluso piezas de software relativamente simples pueden ejecutar fácilmente millones de líneas de código, utilizando cientos o miles de bibliotecas. Verificar todo eso manualmente simplemente no es factible, pero la tarea de crear software para realizar la evaluación es igualmente exigente.
Esto es especialmente problemático para el software de código abierto. Si bien se pueden monitorear varias métricas de calidad, una empresa puede configurar fácilmente un sistema para garantizar que esto suceda con regularidad y asignar personal dedicado a la función; Los proyectos de código abierto dependen en gran medida de que los voluntarios hagan lo mismo.
El informe no proporciona ninguna solución a esto y simplemente afirma que la comunidad de investigadores no debería ignorar el tema, aunque me apresuro a agregar que el problema es tan complejo que ningún informe podría jamás abordarlo.
Hay un par de aspectos más que cubre el informe Back to the Building Blocks, pero termina con una observación interesante: «Los fabricantes de software no están suficientemente incentivados para dedicar recursos apropiados a prácticas de desarrollo seguras, y sus clientes no exigen software de mayor calidad porque No sé cómo medirlo.»
La solución recomendada para la primera parte de esa declaración es que «la calidad de la ciberseguridad también debe verse como un imperativo empresarial del que el CEO y la junta directiva son en última instancia responsables». En otras palabras, hacer que el software sea ciberseguro es responsabilidad de las grandes empresas, no del usuario individual de dicho software.
A estas alturas nadie sabe si este informe obtendrá algún impulso dentro de la industria tecnológica, pero es bueno ver que los organismos gubernamentales se toman el asunto en serio. ¿Hay algo que podamos hacer que marque la diferencia? Sí, protestando con la cartera. No entregue el dinero que tanto le costó ganar (o sus datos personales) a empresas que no hacen que sus productos sean lo más seguros posible.
Es más fácil decirlo que hacerlo, por supuesto, y eso probablemente sea cierto para todo lo tratado en el informe de la Casa Blanca.