Para la elaboración del informe, Core Infrastructure Initiative (CII) y el Laboratorio para Ciencia de Innovación de Harvard (LISH) han unido sus fuerzas con empresas de seguridad como Snyk y Synopsys Cybersecurity Research Center para combinar datos de uso privado con otros públicamente para identificar más de 200 de los proyectos de software Open Source más utilizados, los cuales han sido divididos en dos categorías: los que se basan en JavaScript y los que no. Los primeros cobran especial relevancia debido al ecosistema NPM, que contiene decenas de componentes que han sido escritos con unas pocas decenas de líneas de código de JavaScript y en muchos casos sin que haya funciones declaradas. Curiosamente, aquí no se encuentran pedazos de software populares como podrían serlo Linux, Apache y MySQL, por nombrar tres ejemplos socorridos.
Además, y siguiendo la línea del informe publicado hace poco por Red Hat, se recalca la cada vez mayor importancia del FLOSS en el mundo empresarial. Frank Nagle, profesor de la Escuela de Negocios de Harvard y codirector del informe Census II, ha comentado que “el FLOSS fue visto por mucho tiempo como el dominio de los aficionados y manitas de la computación. Sin embargo, ahora se ha convertido en un componente integral de la economía moderna y fundamental de las tecnologías cotidianas como teléfonos inteligentes, automóviles, Internet de las cosas y numerosas piezas de infraestructura crítica. Comprender qué componentes son los más utilizados y los más vulnerables nos permitirá ayudar a garantizar la salud continua del ecosistema y la economía digital.”
Programas de JavaScript más usados:
- Async: Un módulo de utilidad que proporciona funciones para trabajar con JavaScript asíncrono. Aunque originalmente se diseñó para ser uado con Node.js y se puede instalar a través del comando “npm install async”, es posible usarlo directamente en el navegador.
- Inherits: Herencia amigable con el navegador totalmente compatible con las herencias del node.js estándar.
- Isarray: Matriz para navegadores más antiguos y versiones obsoletas de Node.js.
- Kind-of: Obtiene el tipo nativo de JavaScript de un valor.
- Lodash: Una moderna biblioteca de utilidades de JavaScript que ofrece modularidad, rendimiento y extras.
- Minimist: Opciones de argumento de análisis.
- Natives: Llama a los módulos JavaScript nativos de Node.js.
- Qs: Una biblioteca de parseo y conversación a string de cadenas de consulta con cierta seguridad adicional - Readable-stream:: Flujos principales de Node.js para el espacio de usuario.
- String_decoder:: Node-core string_decoder para el espacio de usuario.
Los componentes más usados que no están hechos con JavaScript:
- Com.fasterxml.jackson.core:jackson-core: Una parte central de Jackson, un procesador JSON (JavaScript Object Notation) que define la API Streaming y las abstracciones básicas compartidas.
- Com.fasterxml.jackson.core:jackson-databind: Paquete general de enlace de datos para Jackson (2.x). Funciona en implementaciones de API de transmisión.
- Com.google.guava:guava: Bibliotecas principales de Google para Java.
- Commons-codec: El software Apache Commons-Codec proporciona implementaciones de codificadores y decodificadores comunes como Base64, Hex, Fonética y URL.
- Commons-io: Commons IO es una biblioteca de utilidades para ayudar con el desarrollo de la funcionalidad entrada-salida.
- Httpcomponents-client: El proyecto Apache HttpComponents es un conjunto de herramientas de componentes Java de bajo nivel centrados en HTTP y protocolos asociados.
- Httpcomponents-core: Lo mismos que el anterior. - Logback-core: El marco de registro confiable, genérico, rápido y flexible para Java.
- Org.apache.commons: commons-lang3: Un paquete de clases de utilidad Java para las clases que están en la jerarquía de java.lang, o que se consideran tan estándar como para justificar la existencia en java.lang.
- Slf4j: Fachada de registro simple para Java.
Los principales problemas en el Open Source
Los investigadores tras el informe descubrieron que el mito del desarrollador único de código abierto que trabaja por amor al arte es solo eso: un mito. Un programador puede comenzar en casa, pero no se queda ahí a menos que le guste su oficina en casa. En lugar de eso, lo que se plasma en el informe Census II es una alta correlación entre estar empleado y ser uno de los principales contribuyentes a los paquetes FOSS más populares.
The Linux Foundation y sus socios creen que existe una “necesidad crítica de crear un esquema de denominación de componentes de software estandarizado. Hasta que exista, las estrategias para la seguridad del software, la transparencia y más tendrán un efecto limitado. Las organizaciones seguirán siendo categóricamente incapaces de comunicarse entre sí”, algo a lo que suma “la frecuencia y la sofisticación crecientes de los incidentes de ciberseguridad en los que la cadena de suministro de software juega un papel importante.”
El segundo problema es que muchos de estos programas viven de la mano de desarrolladores individuales. “De los diez paquetes de software más utilizados en nuestro análisis, el equipo de CII descubrió que siete estaban alojados en cuentas de desarrolladores individuales”. ¿Qué sucede si una de estas cuentas es hackeada? Lastimosamente, aquí hay ejemplos de proyectos que han acabado mal debido al hackeo de la cuenta de sus propietarios, que eran personas individuales.
Por ejemplo, un programa de Node.js llamado left-pad fue eliminado por su desarrollador, provocando que miles de programas JavaScript npm fallaran. Otro ejemplo fue el hecho de que un hacker obtuvo acceso a la popular biblioteca de JavaScript Event-Stream y colocó una puerta trasera en el código. Luego agregó código malicioso en la biblioteca, lo que le permitió robar Bitcoin.
Está claro que las cuentas de desarrolladores individuales necesitan más protección de la que tienen. El programa de identificación CII de la Fundación Linux y Trust and Security Initiative incorporan la seguridad de la cuenta del desarrollador en sus controles para mitigar estos riesgos.
El último problema es que el código abierto no ha escapado a la maldición del software heredado o software legacy. Los desarrolladores pasan a programas más nuevos o versiones más nuevas de sus programas anteriores, pero muchos programadores todavía dependen del programa anterior. Estos desarrolladores son reacios a moverse cuando el nuevo paquete de reemplazo generalmente hace el mismo trabajo. Esto es especialmente cierto cuando el nuevo componentes viene, como a menudo pasa, con errores de compatibilidad. Para solventa esto los desarrolladores que usan Open Source deben comenzar a abordar los problemas del software legacy, cosa que puede resultar engorrosa o plomiza, pero muy necesaria para mantener la seguridad.
Fuente : desdelinux
- Visto: 1281