Los desarrolladores interesados ​​en medir la seguridad de los componentes de código abierto tienen una gran cantidad de opciones, pero todavía tienen que optar por usar la información para auditar los componentes en sus aplicaciones, dicen los expertos.

El 11 de abril, Google anunció su servicio API deps.dev, que incluye metadatos de seguridad que cubren más de 5 millones de componentes en cinco ecosistemas de software, incluidos los principales repositorios de código abierto para Go, Java, Python, JavaScript y Rust. Los datos son accesibles a través de ambas el sitio web deps.dev de la empresa y un conjunto de datos que se puede consultar a través de una nueva API.

Los desarrolladores pueden usar la información para ayudar a elegir paquetes, los entornos de desarrollo integrados (IDE) podrían ofrecer métricas de seguridad a medida que trabaja el desarrollador, y los fabricantes de herramientas de seguridad de aplicaciones podrían agregar la información a la lista de fuentes que usan para ofrecer veredictos sobre la seguridad y la mantenibilidad. de componentes de software de fuente abierta, dice Nicky Ringland, gerente de producto del equipo de seguridad de fuente abierta de Google.

“También podría significar analizar los informes después del hecho... y tal vez descubrir algunos desafíos de dependencia que deben abordar”, dice. “En última instancia, poder verificar un conjunto de dependencias potencialmente muy grande en ecosistemas de múltiples idiomas para problemas de seguridad o licencias, automatizado y a escala… es una herramienta poderosa que esperamos beneficie a todo el ecosistema”.

El Lanzamiento del servicio Google deps.dev se produce cuando los desarrolladores de software, las empresas de seguridad de aplicaciones y el gobierno de EE. UU. trabajan para encontrar formas de mejorar la seguridad del ecosistema de software de código abierto. La explotación de vulnerabilidades en el paquete de registro de Log4j para Java, que se espera que sea una “vulnerabilidad endémica”, según la Junta de Revisión de Seguridad Cibernética (CSRB) del Departamento de Seguridad Nacional de EE. UU., subraya la importancia no solo de minimizar las vulnerabilidades en los paquetes de código abierto, sino también de eliminar el uso de paquetes vulnerables.

Ya se están realizando varios esfuerzos para brindar a los proyectos de código abierto más herramientas para mejorar la seguridad y comunicar sus propias dependencias, pero los desarrolladores deben hacer de la seguridad una prioridad y usar la información para saber qué componentes descargar, dice Brian Fox, cofundador y jefe de tecnología. oficial de la firma de seguridad de software Sonatype. La firma descubrió que cuando un desarrollador "consume" un componente de software que tiene una vulnerabilidad, el 96% de las veces se soluciona. ya estaba para todos.

“En otras palabras, el problema no es realmente que nuestros proyectos de código abierto hagan un buen trabajo. El equipo de Log4j entregó un parche durante el fin de semana de Acción de Gracias, en días, probablemente más rápido de lo que la mayoría de las empresas habrían podido hacer para un proyecto comercial”, dice. “Necesitamos hacer un mejor trabajo. Las organizaciones que consumen código abierto están haciendo un trabajo terrible al tomar estas decisiones”.

Una fiesta de datos de dependencia

El servicio deps.dev de Google agrega otra fuente para que los desarrolladores busquen información sobre componentes de código abierto, pero está lejos de ser la única. Sonatype renovó su Índice de OSS en 2018, modernizando el servicio para brindar acceso a datos de seguridad y mantenimiento en millones de proyectos de software de 14 ecosistemas diferentes, como el sistema de paquetes RubyGems para Ruby y RPM Package Manager para Linux, además de los cinco cubiertos por Google.

Otros servicios, como OpenText está desmantelado, también ofrecen una vista de sus propios conjuntos de datos de dependencia, etiquetan los proyectos y ofrecen medidas de popularidad, actividad de los contribuyentes y seguridad.

Los datos deberían permitir a cualquier desarrollador tomar mejores decisiones, pero también dar a los fabricantes de herramientas otra fuente de datos para mejorar su orientación para los programadores de software, dice Ringland de Google.

“Nuestra intención para la API es que se pueda usar para cualquier cosa, desde scripts únicos y rápidos hasta herramientas complejas, como complementos de edición o integraciones de sistemas de compilación”, dice. “Vemos un apetito real por estos datos - en todo, desde IDE hasta sistemas CI/CD y paneles de auditoría - y estamos entusiasmados de brindar información de seguridad crítica a los desarrolladores, CISO, mantenedores de código abierto y más”.

Endor Labs, que se enfoca en ayudar a los desarrolladores a tomar mejores decisiones utilizando datos de dependencia de software, ya usa deps.dev como una de sus fuentes, pero elogió el acceso a la base de datos más optimizado. Endor Labs combina dichos datos con un análisis exhaustivo para minimizar los falsos positivos, como cuando una aplicación utiliza una biblioteca de código abierto pero no las funciones vulnerables de esa biblioteca.

La compañía también tiene la intención de hacer que su propia información de dependencia sea más accesible a través de DroideGPT, un servicio basado en ChatGPT que hace que los datos de riesgo se puedan buscar de forma conversacional, dice Varun Badhwar, director ejecutivo y cofundador de Endor Labs. El objetivo es reducir la cantidad de trabajo para seleccionar y administrar dependencias de código abierto porque seleccionar las incorrectas puede crear una gran cantidad de trabajo futuro, también conocido como deuda técnica.

“La deuda técnica generalmente se crea cuando se les pide a los desarrolladores que parchen y corrijan constantemente las vulnerabilidades en el código fuente abierto, a pesar de que la mayor parte de ese código en realidad no está en uso”, dice Badhwar. “La forma de reducir la deuda técnica con OSS es seleccionando mejores dependencias y priorizando el riesgo que realmente importa”.

SBOM + Datos de dependencia = Mejor seguridad de software

Los datos de dependencia realmente comenzarán a ser útiles a medida que los desarrolladores y fabricantes de herramientas comiencen a combinar los datos con la lista de materiales de software (SBOM) que las herramientas de desarrollo crean cada vez más.

Los SBOM pueden ayudar a las organizaciones y los equipos de desarrollo al iluminar su uso de las bibliotecas de código abierto, por ejemplo, si están usando cinco bibliotecas de cifrado diferentes o 12 registradores, dice Fox de Sonatype.

“Tienen ese momento de sorpresa cuando se dan cuenta de que están usando una docena de 15 componentes diferentes que hacen lo mismo”, dice Fox. Al combinar SBOM y datos de seguridad, "puedo ver la totalidad de mi cartera y comenzar a razonar sobre ella".

Agregar datos de seguridad a eso permite a las empresas tomar mejores decisiones sobre cómo optimizar su selección de software, y las herramientas, como el Security Scorecard disponible públicamente, o los servicios comerciales pueden ayudar, dice Badhwar de Endor Labs.

“A medida que el esfuerzo comience a abarcar varios equipos y requiera mucho esfuerzo de ingeniería, y a medida que busquen comenzar a reducir el esfuerzo de desarrollo en las alertas de seguridad falsas positivas, las empresas encontrarán un mejor retorno de la inversión con [estas] herramientas”, dice.

• Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
• Platoblockchain. Inteligencia del Metaverso Web3. Conocimiento amplificado. Accede Aquí.
• Acuñando el futuro con Adryenn Ashley. Accede Aquí.
• Fuente: https://www.darkreading.com/dr-tech/software-dependency-data-delivers-security-to-developers