Los defectos de código abierto tardan años en encontrar, pero solo un …



Las empresas deben adoptar la automatización y el seguimiento de dependencias para mantener el software program seguro, dice GitHub en su informe anual de seguridad.

Los errores de los desarrolladores y las dependencias indirectas son las dos fuentes principales de vulnerabilidades en los proyectos de software program de código abierto, que en conjunto se espera que generen la mayoría de las alertas de seguridad el próximo año, según el informe anual Octoverse de GitHub, publicado hoy.

Utilizando datos recopilados de su propia plataforma, GitHub descubrió que la gran mayoría de los proyectos utilizaban software program de código abierto, desde un mínimo del 65% para aplicaciones Java hasta un máximo del 94% para aplicaciones JavaScript. En promedio, una vulnerabilidad no se descubre durante 218 semanas, o más de cuatro años, mientras que se tarda poco más de un mes en corregir la vulnerabilidad promedio.

Los desarrolladores deben anticipar la necesidad de solucionar problemas rápidamente y mejorar la seguridad del código abierto, en lugar de encontrar formas de reducir la dependencia del código abierto, dice Maya Kaczorowski, directora senior de gestión de productos de GitHub.

«En lugar de tratar de compensar el uso de código abierto, abrácelo», dice Kaczorowski. «Una mayor transparencia e información sobre lo que eat en su cadena de suministro de application le permite estar más seguro de que está abordando adecuadamente los riesgos, como las vulnerabilidades de seguridad, que puede estar consumiendo».

por el informe, GitHub escaneó más de 45,000 repositorios activos en su servicio que utilizan uno de los seis principales ecosistemas de program de código abierto, como Node Bundle Supervisor (NPM) para JavaScript o RubyGems para Ruby, y tienen activada la función de gráfico de dependencia. La dependencia de los proyectos de código abierto conduce a vulnerabilidades que se filtran desde una biblioteca de código abierto a los programas que dependen de ella, con un promedio del 59% de los repositorios activos que probablemente recibirán una alerta de vulnerabilidad del servicio Dependabot de GitHub en el próximo año.

Si bien el programa promedio en los lenguajes rastreados por GitHub tiene menos de una docena de dependencias (10 para JavaScript, ocho para Java y seis para Python, por ejemplo), esos paquetes a menudo se basan en otras bibliotecas de código abierto. JavaScript, por ejemplo, tenía la friolera de 683 dependencias transitivas, en promedio, en comparación con 70 para PHP y 68 para Ruby, los dos siguientes recuentos de dependencia más altos.

Los desarrolladores deben centrarse en minimizar el área de superficie de ataque de sus aplicaciones eliminando las dependencias innecesarias y actualizando sus dependencias con regularidad, dice Kaczorowski.

«De forma proactiva, los equipos de seguridad deben ayudar a los desarrolladores a desplazarse hacia la izquierda para detectar los problemas de seguridad con anticipación, buscando problemas de seguridad antes de que se presenten», dice. «Todos los desarrolladores, no solo los que utilizan NPM, deben mantener las dependencias actualizadas y eliminar las que no sean necesarias. No es necesario que parchee algo que no esté en su entorno».

Además, los desarrolladores deben usar pruebas de seguridad y herramientas automatizadas para detectar vulnerabilidades en su código, y también deben estar atentos a los intentos maliciosos de insertar puertas traseras en sus proyectos.

Una encuesta de 521 muestras aleatorias de vulnerabilidades encontró que el 17% se insertó maliciosamente en proyectos de software, pero solo representaron el .2% de la actividad maliciosa porque esos proyectos rara vez se usaron, según el informe de GitHub. Sin embargo, de vez en cuando, los atacantes logran insertar código en una biblioteca de código abierto, y si otros proyectos se basan en esa biblioteca, pueden generar un impacto generalizado.

Sin embargo, de lejos, la gran mayoría del impacto en la seguridad fue creado por errores de los desarrolladores que resultaron en vulnerabilidades.

«Una gran parte del desafío de mantener la confianza en el código abierto es asegurar a los consumidores intermedios la integridad y la continuidad del código en un ecosistema donde el acceso de compromiso voluntario es la norma», afirma GitHub en el informe. «Esto requiere una mejor comprensión del gráfico de contribución de un proyecto, revisión por pares consistente, firma de compromiso y liberación, y seguridad de cuenta reforzada a través de la autenticación multifactor (MFA)».

El informe también destaca el éxito del servicio de Asesoramiento de seguridad de GitHub, que brinda a los proyectos un lugar para publicar avisos de seguridad sobre fallas recientemente descubiertas. Si bien el servicio de asesoramiento comenzó hace solo 18 meses, después de que GitHub se convirtiera oficialmente en una autoridad de numeración CVE (CNA) para el proyecto Popular Vulnerability Enumeration (CVE), el servicio ya ha contabilizado más de 3.000 nuevos informes de vulnerabilidad.

«Para los proyectos que no tenían listas de divulgación o procesos existentes, esta es una mejora noteworthy», dice Kaczorowski. «Queremos evitar informar intencional o accidentalmente sobre problemas de seguridad en los que puedan perderse o ser difíciles de encontrar, y en su lugar permitir que los usuarios vengan a un solo lugar para ver qué afecta su entorno».

JavaScript y NPM representaron el 26% de las vulnerabilidades reportadas, Java y el ecosistema Maven representaron el 24%, y Python y el índice de paquetes de Python (PyPI) representaron casi el 20%. El ecosistema de NPM produjo la mayor proporción de avisos críticos, alrededor del 14%.

Periodista tecnológico veterano de más de 20 años. Ex ingeniero de investigación. Escrito para más de dos docenas de publicaciones, incluidas CNET News.com, Dark Examining, MIT&#39s Engineering Critique, Common Science y Wired News. Cinco premios de periodismo, incluido el de Mejor fecha límite … Ver biografía completa

Lectura recomendada:

Más información





Enlace a la noticia primary