El 78 % de las vulnerabilidades se encuentra en dependencias indirectas, lo que dificulta su corrección

Te damos la bienvenida al informe anual de Snyk sobre el estado de la seguridad del código abierto de 2019. Este informe se divide en varias publicaciones:

• Los paquetes de Maven Central se duplican; se indexa un cuarto de millón de paquetes nuevos en npm

• Las vulnerabilidades en bibliotecas de aplicaciones aumentan un 88 % en dos años

• El 81 % cree que los desarrolladores deberían encargarse de la seguridad, pero no cuentan con las herramientas adecuadas

• Los mantenedores de código abierto quieren protegerse, pero al 70 % le faltan habilidades

• Las diez imágenes de Docker más populares contienen al menos 30 vulnerabilidades cada una

• Las vulnerabilidades ReDoS en npm aumentan un 143 % y el XSS sigue creciendo

• El 78 % de las vulnerabilidades se encuentra en dependencias indirectas, lo que dificulta su corrección

También puedes descargar nuestro atractivo informe en PDF, elaborado con esmero, que reúne toda esta información y mucho más en un solo lugar.

Descarga el informe sobre el estado de la seguridad del código abierto de 2019

Dependencias indirectas

Cuesta imaginar los días en que se escribía software sin dependencias de código abierto. Administrar las dependencias de un proyecto es una tarea importante que requiere la debida diligencia para llevar un registro correcto de las bibliotecas de las que dependes. Después de todo, la aplicación que implementas incluye tanto tu código como tus dependencias.

La mayoría de las dependencias en npm, Maven y Ruby son dependencias indirectas, solicitadas por las pocas bibliotecas definidas explícitamente. Las vulnerabilidades en dependencias indirectas representan el 78 % del total de vulnerabilidades.

Snyk analizó más de un millón de proyectos en instantáneas y descubrió que las vulnerabilidades en dependencias indirectas representan el 78 % del total. Esto pone aún más de relieve la necesidad crítica de tener una visión clara del árbol de dependencias y de poder identificar correctamente los matices de una ruta vulnerable para corregir estas vulnerabilidades.

Por supuesto, encontrar las vulnerabilidades en una dependencia es apenas el primer paso. Poder determinar con precisión todas las rutas del árbol de dependencias por las que se puede llegar a la dependencia vulnerable es más complejo.

Además, poder sugerir los pasos para eliminar la vulnerabilidad y, al mismo tiempo, preservar la compatibilidad entre las dependencias representa un desafío aún mayor y mucho más interesante.

Riesgos e impacto

Solo uno de cada tres desarrolladores puede corregir una vulnerabilidad de gravedad alta o crítica en un día o menos

No debería sorprender a la mayoría que, en el informe State of the Octoverse de GitHub de este año, la seguridad sea la categoría más popular de aplicaciones de integración de proyectos, con más de una integración para desarrolladores. A continuación, una cita de Gartner, analista del sector, incluida en un informe reciente sobre seguridad de aplicaciones que aborda la necesidad de que las organizaciones realicen pruebas de seguridad lo antes posible en el ciclo de vida de las aplicaciones.

Casi la mitad (43 %) de las personas encuestadas tiene al menos 20 dependencias directas, lo que refuerza la necesidad de monitorear las vulnerabilidades de código abierto que estas bibliotecas pueden incorporar.

Cuanto más usamos software de código abierto, más riesgos acumulamos, ya que incluimos código de otras personas que podría contener vulnerabilidades ahora o en el futuro. Además, el riesgo no refleja únicamente qué tan seguro es el código, sino también el cumplimiento de las licencias del código que adoptas y si ese código infringe la licencia correspondiente.

Toma medidas

La composición de aplicaciones es compleja. Como mantenedores y desarrolladores de sistemas operativos, puedes tomar medidas para mejorar la seguridad de los proyectos que mantienes y en los que contribuyes.

Mantenedores de código abierto

Como mantenedor de código abierto, debes ofrecer versiones seguras de tu código y definir una estrategia de comunicación para quienes lo usan. Así, puedes tener un impacto positivo en otros proyectos y aplicaciones, y probablemente también beneficiar a tus propios proyectos.

• Siempre que sea posible, revisa el código de forma segura con tus colegas y sigue las prácticas recomendadas para escribir código seguro. Incluye consideraciones de seguridad en la lista de verificación de revisión de código y capacita a quienes hacen las revisiones para que sepan qué deben buscar.

• Audita periódicamente tu base de código en busca de vulnerabilidades, por ejemplo, mediante análisis estático y dinámico de código. Puedes automatizar estos análisis en tu flujo de trabajo de desarrollo para detectar vulnerabilidades con más facilidad antes de que se hagan públicas.

• Define claramente un proceso sencillo para comunicar divulgaciones responsables, ya sea con tu propia política o remitiendo a un programa existente. Para comunicar tu compromiso con la seguridad, considera adoptar una política SECURITY.MD y una insignia del proyecto que refleje su estado de seguridad.

• Implementa una estrategia de seguridad desde el inicio que permita a tu equipo conocer los problemas de seguridad durante el desarrollo, en CI e incluso al crear pull requests, para eliminar toda posibilidad de que se incorpore código vulnerable a tus proyectos.

Desarrolladores de código abierto

Como usuario de componentes de código abierto, es tu responsabilidad comprender por completo las dependencias directas e indirectas que usan tus proyectos, incluidos los fallos de seguridad que pueda haber en ese árbol de dependencias. Considera adoptar las siguientes pautas de seguridad:

• Audita periódicamente tu base de código con una herramienta que detecte automáticamente vulnerabilidades en las dependencias de terceros, recomiende medidas correctivas a tu equipo y monitoree las dependencias de un proyecto incluso después de su implementación.

• Sigue las políticas de divulgación responsable si reportas una vulnerabilidad de seguridad, para evitar poner en riesgo a los usuarios. Si no tienes claro cómo hacerlo, considera reportarla a una empresa de seguridad que te acompañe durante el proceso, como el programa de divulgación responsable de Snyk.

• Suscríbete a los canales de comunicación sobre seguridad de tus dependencias de código abierto, si los tienen, para estar al tanto de posibles vulnerabilidades cuando se reporten.

Sigue leyendo nuestras publicaciones con los principales hallazgos:

• Los paquetes de Maven Central se duplican; se indexa un cuarto de millón de paquetes nuevos en npm

• Las vulnerabilidades en bibliotecas de aplicaciones aumentan un 88 % en dos años

• El 81 % cree que los desarrolladores deberían encargarse de la seguridad, pero no cuentan con las herramientas adecuadas

• Los mantenedores de código abierto quieren protegerse, pero al 70 % le faltan habilidades

• Las diez imágenes de Docker más populares contienen al menos 30 vulnerabilidades cada una

• Las vulnerabilidades ReDoS en npm aumentan un 143 % y el XSS sigue creciendo

• El 78 % de las vulnerabilidades se encuentra en dependencias indirectas, lo que dificulta su corrección