La Fundación Linux sin fines de lucro, junto con el Laboratorio de Ciencias de la Innovación de Harvard, publicó recientemente el Censo II de software libre y de código abierto (FOSS): bibliotecas de aplicaciones.
Compilado a partir de datos de uso anónimos basados en escaneos de bases de código en miles de empresas aportadas por Synopsys Cybersecurity Research Center (CyRC) , Snyk y FOSSA, este informe identifica más de 1000 de las bibliotecas de aplicaciones de código abierto más implementadas.
Los autores del informe señalaron que debido a que FOSS se produce de manera descentralizada y distribuida, determinar su salud, valor económico y seguridad puede ser un desafío. Debido a que los componentes de software están empaquetados y las versiones se identifican y catalogan de muchas maneras no estandarizadas, el informe los ha organizado en ocho listas Top 500.
Como dice Mike McGuire, gerente de soluciones de seguridad de Synopsys Software Integrity Group , los paquetes y las versiones son un poco como los diferentes modelos, años y acabados de un automóvil.“Si te dijera que conduzco un Toyota Camry, todavía no sabes exactamente lo que conduzco. ¿Es la versión de 1999 o la versión de 2022? Es importante saber esto al pedir piezas, obtener servicio, hacer un seguimiento de las retiradas del mercado, etc.”, dijo.
Si bien el informe Census II tiene como objetivo "informar acciones para mantener la seguridad y la salud a largo plazo de FOSS" y representa "nuestra mejor estimación de qué paquetes de FOSS son los más utilizados por diferentes aplicaciones", los autores advierten que el informe no no reflejan los perfiles de riesgo del software. “Hay muchos indicadores que podrían usarse para sugerir riesgos y diferentes organizaciones pueden ponderar los factores de manera diferente”, escribieron los autores.
McGuire está de acuerdo con la advertencia. Ampliamente utilizado no es lo mismo que crítico."Toneladas de aplicaciones pueden estar utilizando un marco de GUI de Java específico, lo que lo hace muy popular, pero es posible que no sirva como una parte crítica del software en caso de que algo le suceda".
Agregó que lo que se considere crítico será exclusivo de cada organización en función de cómo se construyan sus aplicaciones. Aún así, medir los perfiles de riesgo es más fácil una vez que se identifica el software más utilizado, escribieron los autores del Censo II.
A medida que la industria avanza hacia la estandarización generalizada y la adopción de listas de materiales de software (SBOM), el informe define varios obstáculos para mejorar la forma en que se identifica, cataloga y mantiene el software. Estos desafíos incluyen:
- La necesidad de un esquema de nomenclatura estandarizado para los componentes de software para que las bibliotecas de aplicaciones puedan identificarse de forma única. Sin esto, "las organizaciones seguirán siendo categóricamente incapaces de comunicarse entre sí a gran escala, particularmente a escala global, necesaria para compartir dicha información".
- Las complejidades asociadas con el control de versiones de paquetes. El equipo se encontró con un problema inesperado: las empresas “mantenían versiones internas de un paquete y no aportaban sus cambios al repositorio oficial. En un caso, observaron la versión 2.87 de un paquete varias veces, pero el repositorio oficial solo subió a la versión 2.26”. Eso significa que si un SBOM "no puede distinguir entre una versión 'principal' y una variante... será difícil para los compradores de dicho software saber si son vulnerables a vulnerabilidades recién descubiertas".
El informe también identificó varios problemas que afectan la seguridad a largo plazo de FOSS. Éstos incluyen:
- Gran parte del FOSS más utilizado es desarrollado por solo un puñado de colaboradores: los resultados en un conjunto de datos muestran que 136 desarrolladores fueron responsables de más del 80% de las líneas de código agregadas a los 50 paquetes principales. El peligro aquí, como se informó en el informe OSSRA de 2021, es que "a medida que un proyecto de código abierto crece en popularidad, sin un crecimiento correspondiente en las personas que mantienen el proyecto, la consecuencia a menudo es el agotamiento del desarrollador y muchos proyectos de código abierto se abandonan". Y si se abandonan los proyectos, eso significa que los errores no se corrigen.
- La creciente importancia de la seguridad de la cuenta de desarrollador individual. Las cuentas individuales generalmente no están tan bien protegidas como las organizacionales. Eso, escribieron los autores, significa que “los cambios en el código bajo el control de estas cuentas de desarrolladores individuales son significativamente más fáciles de realizar y de realizar sin detección. Además, podría ocurrir un problema relacionado si el desarrollador individual tuvo una pausa prolongada o fue golpeado por el bus proverbial, lo que impidió que se realizaran actualizaciones en el código”. Ese no es el único riesgo. Otros incluyen desarrolladores independientes que eliminan o borran sus proyectos, rompiendo cientos o millones de paquetes que dependen de ellos.
- La persistencia del software heredado en el espacio de código abierto. Todos hemos oído hablar de empresas que declaran que dejarán de admitir versiones anteriores de sistemas operativos o aplicaciones. Pero eso no significa que todos dejen de usar esas versiones anteriores por varias razones. “A muchas organizaciones les resultará difícil justificar el cambio a diferentes paquetes, ya que hay costos financieros y relacionados con el tiempo para cambiar a un nuevo software cuando no hay garantía de un beneficio adicional”, escribieron los autores. De hecho, el informe de OSSRA encontró que el 85% de las bases de código examinadas en 2020 tenían dependencias de código abierto que tenían más de cuatro años de antigüedad, a pesar de que había versiones más nuevas disponibles, a veces muchas versiones más nuevas. Pero eso puede ser peligroso. Una de las razones de las versiones más nuevas es corregir errores en las versiones anteriores.
Si bien no es prescriptivo, Census II sí señala la necesidad de que las organizaciones y los usuarios participen más activamente en el desarrollo de FOSS y no lo dejen únicamente en manos del pequeño grupo de desarrolladores que han liderado el camino hasta el momento. Además, el informe muestra cuán importante es el análisis de la composición del software para detectar la persistencia del software heredado en código abierto y la necesidad continua de estandarización en el espacio SBOM.
Fuente: thenewstack | somoslibres
