Todo lo que necesitas saber sobre tecnología

Etiqueta: Software de código abierto

Un informe de CISA revela que la mayoría de los proyectos de código abierto contienen código que no es seguro para la memoria

Más de la mitad de los proyectos de código abierto contienen código escrito en un lenguaje no seguro para la memoria, según un informe de la Agencia de Seguridad de Infraestructura y Ciberseguridad de Estados Unidos. El término «no seguro para la memoria» significa que el código permite operaciones que pueden corromper la memoria, lo que genera vulnerabilidades como desbordamientos de búfer, uso después de la liberación y fugas de memoria. Los resultados del informe, publicados conjuntamente con el FBI, el Centro Australiano de Seguridad Cibernética de la Dirección de Señales de Australia y el Centro Canadiense de Seguridad Cibernética, se basan en el análisis de 172 proyectos críticos definidos por el grupo de trabajo de Protección de Proyectos Críticos de OpenSSF. Del total de líneas de código de estos proyectos, el 55 % se escribió en un lenguaje no seguro para la memoria, y los proyectos más grandes contienen más. Las líneas no seguras para la memoria representan más de una cuarta parte de los 10 proyectos más grandes del conjunto de datos, mientras que la proporción media entre ellos es del 62,5 %. Cuatro de ellos están compuestos por más del 94 % de código no seguro para la memoria. ¿Qué son los lenguajes no seguros para la memoria? Los lenguajes que no son seguros para la memoria, como C y C++, requieren que los desarrolladores implementen manualmente prácticas rigurosas de administración de memoria, incluida la asignación y desasignación cuidadosa de la memoria. Naturalmente, se cometerán errores, y estos resultan en vulnerabilidades que pueden permitir a los adversarios tomar el control del software, los sistemas y los datos. Por otro lado, los lenguajes seguros para la memoria, como Python, Java, C# y Rust, manejan automáticamente la administración de la memoria a través de características integradas y transfieren la responsabilidad al intérprete o compilador. VER: Los 10 mejores cursos de Python que vale la pena tomar en 2024 Los autores del informe escribieron: «Las vulnerabilidades de seguridad de la memoria se encuentran entre las clases más frecuentes de vulnerabilidad de software y generan costos sustanciales tanto para los fabricantes de software como para los consumidores relacionados con la aplicación de parches, la respuesta a incidentes y otros esfuerzos». También analizaron las dependencias de software en tres proyectos escritos en lenguajes seguros para la memoria y descubrieron que cada uno de ellos dependía de otros componentes escritos en lenguajes no seguros para la memoria. “Por lo tanto, determinamos que la mayoría de los proyectos críticos de código abierto analizados, incluso aquellos escritos en lenguajes seguros para la memoria, potencialmente contienen vulnerabilidades de seguridad de memoria”, escribieron los autores. Chris Hughes, asesor jefe de seguridad de la empresa de seguridad de código abierto Endor Labs y miembro de innovación cibernética en CISA, dijo a TechRepublic: “Los hallazgos ciertamente plantean un riesgo tanto para las organizaciones comerciales como para las agencias gubernamentales debido a la explotación predominante de esta clase de vulnerabilidades cuando analizamos la explotación anual en todas las clases de vulnerabilidades. A menudo se encuentran entre las clases de vulnerabilidades más comúnmente explotadas año tras año”. ¿Por qué es tan frecuente el código inseguro para la memoria? El código inseguro para la memoria es frecuente porque brinda a los desarrolladores la capacidad de manipular directamente el hardware y la memoria. Esto es útil en casos en los que las limitaciones de rendimiento y recursos son factores críticos, como en los núcleos y controladores del sistema operativo, la criptografía y la red para aplicaciones integradas. Los autores del informe observaron esto y esperan que continúe. Cobertura de seguridad de lectura obligada Los desarrolladores pueden usar lenguajes inseguros para la memoria directamente porque desconocen o no les preocupan los riesgos. También pueden desactivar intencionalmente las características de seguridad de memoria de un lenguaje seguro para la memoria. Sin embargo, aquellos conscientes de los riesgos y que no desean incorporar código inseguro para la memoria pueden hacerlo involuntariamente a través de una dependencia en un proyecto externo. Realizar un análisis de dependencia integral es un desafío por varias razones, lo que hace que sea fácil que las dependencias inseguras para la memoria se escapen. Por un lado, los lenguajes a menudo tienen múltiples mecanismos para especificar o crear dependencias, lo que complica el proceso de identificación. Además, hacerlo es computacionalmente costoso, ya que se requieren algoritmos sofisticados para rastrear todas las interacciones potenciales y efectos secundarios. «En algún lugar debajo de cada pila de lenguaje de programación y gráfico de dependencia, se escribe y ejecuta código inseguro para la memoria», escribieron los autores. VER: Estudio de Aqua Security encuentra un aumento del 1,400% en ataques a la memoria Hughes le dijo a TechRepublic: «A menudo, estos lenguajes (inseguros para la memoria) han sido ampliamente adoptados y utilizados durante años antes de gran parte de la actividad reciente para tratar de alentar la transición a lenguajes seguros para la memoria. Además, existe la necesidad de que la comunidad de desarrollo más amplia realice la transición a lenguajes seguros para la memoria más modernos. “Sería difícil cambiar muchos de estos proyectos a lenguajes seguros para la memoria porque requeriría recursos y esfuerzos de los mantenedores, para refactorizar/reescribir a lenguajes seguros para la memoria. Los mantenedores pueden no tener experiencia en el lenguaje seguro para la memoria e incluso si la tienen, es posible que no estén incentivados a hacerlo, dado que son en gran parte voluntarios no remunerados que no reciben compensación por los proyectos que han creado y mantenido”. Agregó que las organizaciones deben ofrecer incentivos monetarios y otros recursos para alentar a los desarrolladores de código abierto a realizar la transición de su código, pero también deben monitorear cualquier esfuerzo para garantizar que se implementen prácticas de codificación seguras. Recomendaciones para reducir los riesgos de código inseguro para la memoria El informe hace referencia al documento The Case for Memory Safe Roadmaps de CISA y al informe del Technical Advisory Council sobre seguridad de la memoria para obtener recomendaciones sobre cómo reducir la prevalencia de lenguajes inseguros para la memoria. Estas recomendaciones incluyen: Transición de proyectos existentes a lenguajes seguros para la memoria, ya que los avances recientes significan que ahora son paralelos al rendimiento de los lenguajes inseguros para la memoria. Escribir nuevos proyectos en lenguajes seguros para la memoria. Crear hojas de ruta seguras para la memoria que incluyan planes claros para integrar la programación segura para la memoria en los sistemas y abordar la seguridad de la memoria en dependencias externas. Gestionar las dependencias externas asegurándose de que las bibliotecas y los componentes de terceros también sean seguros para la memoria o tengan mitigaciones implementadas. Capacitar a los desarrolladores en lenguajes seguros para la memoria. Priorizar la seguridad en el diseño de software desde el comienzo del ciclo de vida del software, por ejemplo, adhiriendo a los principios de Secure by Design. Esfuerzos de los funcionarios para reducir la prevalencia de código inseguro para la memoria Los funcionarios federales e investigadores en los EE. UU. han estado trabajando para reducir la cantidad de software inseguro para la memoria en circulación en los últimos años. Un informe de octubre de 2022 de Consumer Reports señaló que «aproximadamente del 60 al 70 por ciento de las vulnerabilidades del navegador y del kernel, y los errores de seguridad encontrados en las bases de código C/C++, se deben a la inseguridad de la memoria». Luego, la Agencia de Seguridad Nacional publicó una guía sobre cómo los desarrolladores de software podrían protegerse contra los problemas de seguridad de la memoria. En 2023, la directora de CISA, Jen Easterly, pidió a las universidades que educaran a los estudiantes sobre la seguridad de la memoria y las prácticas de codificación segura. Luego se publicó la Estrategia Nacional de Ciberseguridad 2023 y su plan de implementación, que discutía la inversión en lenguajes seguros para la memoria y la colaboración con la comunidad de código abierto para promoverlos aún más. Ese diciembre, CISA publicó The Case for Memory Safe Roadmaps y el informe del Consejo Asesor Técnico sobre seguridad de la memoria. En febrero de este año, la Casa Blanca publicó un informe que promovía el uso de lenguajes seguros para la memoria y el desarrollo de estándares de seguridad de software, que fue respaldado por importantes empresas de tecnología, incluidas SAP y Hewlett Packard Enterprise. Los esfuerzos del gobierno de EE. UU. están siendo apoyados por una serie de grupos de terceros que comparten su objetivo de reducir la prevalencia de código inseguro para la memoria. El Grupo de Trabajo de Mejores Prácticas de OpenSSF tiene un subgrupo de Interés Especial dedicado a la Seguridad de la Memoria, mientras que el proyecto Prossimo del Grupo de Investigación de Seguridad de Internet quiere «mover la infraestructura de software sensible a la seguridad de Internet a un código seguro para la memoria». Google ha desarrollado el servicio OSS-Fuzz que prueba continuamente el software de código abierto en busca de vulnerabilidades de seguridad de memoria y otros errores utilizando técnicas de fuzzing automatizadas.

Algunas licencias de software de código abierto son sólo «abiertas», dice Thoughtworks

Se ha estimado que el 90% de las organizaciones utilizan algún tipo de software de código abierto, y si tuvieran que volver a codificarlo ellas mismas, les costaría 9 billones de dólares. Esto hace que el código abierto sea un enorme recurso económico global. Sin embargo, algunas herramientas han pasado a modelos comerciales en los últimos tiempos. Después de años de crecimiento gracias a la contribución de los desarrolladores y una aceptación generalizada entre los usuarios, están monetizando el resultado final, a menudo para disgusto de las comunidades de desarrolladores y los usuarios empresariales dependientes. La consultora de tecnología global Thoughtworks identificó la tendencia en su Radar Tecnológico más reciente. El director de tecnología australiano, Scott Shaw, dijo que esto se debe en parte a un mayor enfoque en las finanzas en los últimos tiempos, y que las organizaciones deben asegurarse de abordar el código abierto «con los ojos abiertos». Algunos favoritos del código abierto han pasado a las licencias comerciales. En abril de 2024, Thoughtworks notó una “cambio en el panorama previamente sereno” del código abierto. «Varias herramientas destacadas han obtenido recientemente mala prensa, cuando sus mantenedores cambiaron -en varios casos abruptamente- de una licencia de código abierto a un modelo comercial», dijo. Según Shaw, la tendencia se viene construyendo desde hace algunos años. Si bien la industria tecnológica tiene un conjunto común de principios y una serie de licencias de código abierto bien entendidas y regidas por la Iniciativa de Código Abierto, ha habido una creciente “divergencia” con respecto a ese paradigma. Cambios abruptos en las licencias de código abierto El primer ejemplo son aquellas empresas que han cambiado los términos de su licencia de código abierto a mitad de camino. Después de construir una comunidad de desarrolladores e incorporar a un gran número de usuarios que han integrado el software en los flujos de trabajo bajo los estándares permisivos de las licencias de código abierto, se ha tomado una decisión para tomar medidas drásticas, a menudo vinculadas a los ingresos. VER: Los 8 mejores software de gestión de proyectos de código abierto para 2024 Si bien Thoughtworks escribió que «no tenemos ningún problema en pagar por el software y estamos de acuerdo con el modelo común de licencias comerciales para funcionalidad adicional», agregó que «nos resulta problemático cuando la funcionalidad principal de una herramienta ampliamente utilizada de repente se pone detrás de un muro de pago, especialmente cuando se ha desarrollado un ecosistema alrededor de la herramienta”. ‘Difusión semántica’ en código abierto También se ha difuminado lo que significa código abierto, y Thoughtworks observa «software que proclama ser código abierto, pero las capacidades fundamentales sólo aparecen después de que los consumidores pagan suscripciones u otros cargos». En algunos casos, un proyecto de código abierto solo puede distribuir código, no compilar, lo que aumenta la carga para las organizaciones que lo utilizan localmente. “Un ejemplo son algunos grandes modelos de lenguaje a los que se hace referencia vagamente como código abierto y que no lo son; son abiertos de alguna manera, pero no cumplen con los principios del código abierto, ciertamente no con la forma en que los define OSI”, dijo Shaw. Docker, Terraform y Llama 3 difieren del código abierto puro. Thoughtworks dijo que ha habido varios ejemplos de cambios hacia licencias comerciales o licencias «abiertas» que están surgiendo. Tres ejemplos son el software de creación de contenedores Docker, Terraform de Hashicorp y el recientemente lanzado LLM Lllama 3 de Meta. Docker Docker es un software de código abierto utilizado por los desarrolladores para automatizar la implementación de aplicaciones dentro de contenedores. Se convirtió en la base para la mayor parte de la distribución de aplicaciones y en una parte integral de la entrega de software, y el 55 % de los desarrolladores lo utiliza a diario. Docker también tenía un Docker Desktop conveniente, que permitía a los desarrolladores ejecutar Docker localmente en una máquina para realizar pruebas. En 2021, y a partir de 2022, Docker cambió su licencia. Si bien seguía siendo gratuito para las pequeñas empresas con menos de 250 empleados y menos de 10 millones de dólares en ingresos, las empresas más grandes que lo utilizaban profesionalmente necesitaban pagar una membresía Pro, Team o Business, lo que significaba que las organizaciones ya no cumplían si no pagaban tarifas. a Docker. Terraform Terraform de Hashicorp es una de las herramientas de código de infraestructura más populares y efectivas para aprovisionar y administrar infraestructura de forma segura y predecible en cualquier nube. Sin embargo, Hashicorp provocó protestas en la comunidad de código abierto cuando tomó la decisión de cambiar de una licencia pública de Mozilla v2.0 a una licencia de fuente comercial, debido a su uso generalizado como software de código abierto que respalda las operaciones y empresas de DevOps. VER: Los 5 mejores CRM de código abierto para 2024 La compañía explicó su decisión, principalmente, para proteger sus intereses de los competidores que utilizan Terraform para competir con Hashicorp, que ahora puede utilizar licencias comerciales. Esto no aplacó a toda la comunidad de código abierto; algunos se animaron a iniciar OpenTofu, un proyecto impulsado por la comunidad que tiene como objetivo crear una bifurcación de Terraform y mantenerla como una herramienta de código abierto, en línea con los compromisos anteriores de la empresa con el código abierto. Llama 3 Llama 3 de Meta está siendo recibido como un poderoso modelo LLM, dijo Shaw. Sin embargo, en términos de sus credenciales de código abierto, el modelo tiene pesos abiertos pero no sigue otros principios de OSI como la capacidad de examinar el código fuente y completar la redistribución sin restricciones. Meta’s Llama 3 requiere el pago de tarifas de licencia basadas en el número de usuarios para el uso de pesas. “Si le preguntas a Meta, lo llaman modelo disponible abiertamente. Eso es honesto, pero el término código abierto se aplica de manera muy vaga a estas cosas, y creo que es importante que la gente entienda que estar disponible abiertamente o ser gratuito no necesariamente implica código abierto. Creo que esto a veces se pasa por alto; la gente no entiende completamente qué grado de apertura podría tener un modelo en particular”. Más cobertura en Australia Los LLM de IA tienen muchos grados de apertura. Thoughtworks dijo que la “difusión semántica” de la insignia de código abierto es algo que se está viendo en el espacio de IA de rápido crecimiento en particular. «Aunque este modelo de negocio ha existido antes, parece ser explotado más con muchas de las nuevas y brillantes herramientas de IA, que ofrecen capacidades sorprendentes que están demasiado escondidas bajo la letra pequeña», escribió la empresa en su Technology Radar. Shaw dijo que para los LLM, hay una variedad de apertura disponible en diferentes modelos. Van desde modelos completamente propietarios, como ChatGPT de OpenAI, hasta modelos en los que el código fuente, los datos de entrenamiento, la estructura del modelo y los pesos están disponibles gratuitamente y abiertos para inspección y contribución. Un ejemplo reciente es Arctic LLM de Snowflake, publicado con una licencia Apache 2.0. Dos razones por las que las empresas reconsideran las licencias de código abierto Thoughtworks sugiere que los ingresos y la protección de la propiedad intelectual están detrás de algunas de las medidas de concesión de licencias. Centrarse en las finanzas Toda la industria tecnológica ha sido más consciente de los costos en los últimos años debido a los vientos económicos en contra, y los directores financieros se han vuelto más influyentes en la toma de decisiones. Technology Radar de Thoughtworks dijo que «se ha echado mucha culpa a las empresas de capital privado y de capital de riesgo por ejercer más presión sobre las empresas para obtener ingresos y rentabilidad, particularmente a medida que la industria tecnológica se ha desacelerado». Shaw dijo que ha sido un momento en el que personas de toda la industria han estado reexaminando sus modelos de negocio, lo que ha provocado cierta rotación en el código abierto. La protección de la propiedad intelectual Otro factor, señalado por Hashicorp en su decisión de concesión de licencia Terraform, es la protección de la propiedad intelectual. Thoughtworks escribe que «otros especulan que los proveedores de código abierto sólo se protegen a sí mismos y a su propiedad intelectual de los proveedores de la nube que se beneficiarían de la propiedad intelectual a través de servicios alojados en la nube». Shaw dijo que en algunos casos las organizaciones más grandes, como las hiperescaladoras, habían estado adoptando herramientas de código abierto y creando servicios muy rentables y no pagaban ni otorgaban derechos de licencia al creador de las herramientas. Aunque ese es esencialmente el espíritu del código abierto, los proveedores originales quieren asegurarse de recibir algún tipo de beneficio financiero. Existen riesgos para las empresas cuando cambian las licencias de código abierto. Cuando las licencias de proyectos de software de código abierto ampliamente utilizados cambian a un modelo más comercial, se crea un «gran dolor de cabeza» para sus usuarios empresariales, dijo Shaw. Para seguir cumpliendo con los términos de la licencia, las empresas deben asegurarse de que el software (como Docker Desktop, en el caso de Docker) se elimine de los dispositivos individuales; de lo contrario, pueden verse afectados por tarifas de licencia o correr el riesgo de quedar atrapados en una auditoría, incluso si el software todavía está allí sin saberlo. Shaw dijo que las organizaciones ya dedican mucho tiempo, dinero y esfuerzo a realizar auditorías, asegurándose de que el software que utilizan sus empleados se utilice dentro de los términos de sus licencias. Los cambios abruptos en la oferta de los proveedores de código abierto pueden ser difíciles de gestionar. «Creo que es algo de lo que las juntas directivas, los directores ejecutivos y los directores financieros querrían ser conscientes, porque pueden depender en gran medida del software de código abierto que ha cambiado sus términos de licencia», dijo Shaw. Cosas que TI debe tener en cuenta al utilizar software de código abierto Thoughtworks ha aconsejado a las empresas y a las partes interesadas de TI que ejerzan “particular diligencia en torno a los problemas de licencias”. Preste atención a las advertencias y asegúrese de que todos los archivos en un repositorio estén cubiertos por la licencia de nivel superior”, detalló la firma en su Technology Radar. Shaw añadió que las empresas debían abordar el software de código abierto con los “ojos abiertos”. Verifique los detalles de los proyectos de código abierto Un factor a considerar es si un proyecto de código abierto realmente cuenta con apoyo de base o si depende de un interés comercial sin otro modelo de negocios aparente, dijo Shaw. En este último caso, recomienda considerar si vale la pena pagar por la versión empresarial del software, de modo que los términos de la licencia se acuerden contractualmente desde el principio. Tenga cuidado con la fuga de datos a los modelos SaaS Otro factor a considerar es si el software de código abierto realmente se ejecuta en una computadora de escritorio o está enviando algunos datos a la nube. Shaw dijo que las empresas deberían saber cómo se tratan los datos si se trata de un servicio en línea y qué tipo de salvaguardias existen contra la redistribución. En algunos casos, Shaw dijo que existe el riesgo de fuga de datos si las organizaciones no tienen cuidado. Nuevos proveedores y productos compiten después de los cambios en las licencias. Cuando una herramienta de código abierto cambia los términos de la licencia y los usuarios se ven obligados a pagar, siempre hay competidores esperando entre bastidores para intervenir y ofrecer competencia, dijo Shaw. Por ejemplo, en el Technology Radar de la empresa, donde marca herramientas para observar, las alternativas a Docker Desktop incluyen Colima. Y si bien la economía actual está provocando un escrutinio más detenido de los fundamentos empresariales, esos impulsores acentuados para el cambio a licencias comerciales pueden ser cíclicos.

Funciona con WordPress & Tema de Anders Norén