Snyk ha analizado la actual situación sobre la seguridad en torno al Open Source, publicando los resultados en un extenso informe lleno de datos interesantes, los cuales intentaremos resumir en esta entrada.
El informe, cuyo nombre es The State of Open Source Security (El Estado de la Seguridad del Open Source), ha abarcado tres áreas: El panorama del Open Source, el ciclo de vida de una vulnerabilidad hallada en un software Open Source y el futuro del Open Source. Para obtener los datos, Snyk ha analizado una encuesta a la que han respondido 500 mantenedores y usuarios de código abierto, utilizado sus datos internos basados en más de 40.000 proyectos, tomado información publicada por Red Hat y reunido datos tras escanear millones de repositorios GitHub, paquetes y registros.
El panorama del Open Source
Debido a las distintas áreas que abarca el informe, vamos a seguir su línea para así mostrar los datos de forma ordenada y comprensible. El primer apartado analizado por Snyk es la situación del Open Source tanto entre los desarrolladores como los usuarios.
Según datos de Gartner y Forrester, entre el 80 y el 90 por ciento de los desarrolladores de software comercial utilizan componentes de código abierto en sus aplicaciones, los cuales terminan siendo determinantes para potenciar la actividad de las empresas. Si tomamos como referencia las fechas de entre el 1 de octubre de 2016 y el 1 de octubre de 2017, se pueden destacar los siguientes datos:
- El número de Rubygems se ha incrementado un 10,3%.
- El número de bibliotecas de Python se ha incrementado un 32%.
- El número de artefactos de Maven se ha incrementado un 28%.
- El número de paquetes npm se ha incrementado un 57%.
- El número de aplicaciones disponibles de forma pública en Docker Hub es ahora de 900.000, cuando antes su número era de 460.000.
- 6.300 millones de paquetes de Python fueron descargados entre el 1 de enero y el 30 de septiembre de 2017.
- 87.300 millones de paquetes fueron descargados usando npm entre el 1 de enero y el 30 de septiembre de 2017.
Snyk ha recordado la encuesta sobre la situación del Open Source realizada por GitHub, destacando la frecuencia con la que los mantenedores auditan su propio código. Aquí el 13% respondió al menos una vez al año, un 11% al menos trimestralmente, un 43% respondió que nunca y un 31% una o dos veces. Por otro lado, el 16,8% de los mantenedores respondieron que los conocimientos sobre seguridad tendrían que ser altos.
Sobre las vulnerabilidades publicadas, la cantidad en 2016 hallada en bibliotecas utilizadas por las aplicaciones aumentó un 53,6%, mientras que la cantidad de vulnerabilidades halladas en RHEL ha disminuido un 65% desde 2012. Según un estudio llevado a cabo por la Universidad Carnegie Mellon, por cada mil líneas de código se hallan entre 20 y 30 fallos, los cuales podrían llevar a vulnerabilidades. Por su parte, la cantidad de vulnerabilidades críticas halladas en Java y Node.js no parece parar de aumentar.
Ciclo de vida de una vulnerabilidad hallada en un software Open Source
El ciclo de vida de una vulnerabilidad hallada en un software Open Source cuenta con muchos pasos. Desde el descubrimiento hasta la liberación de la corrección, el proceso siempre se realiza bajo los criterios del proyecto y juega un rol importante en la seguridad general ofrecida por el software. Sobre el descubrimiento de las vulnerabilidades se pueden destacar los siguientes datos:
- La mediana de tiempo que pasa desde la introducción de la vulnerabilidad hasta su descubrimiento es 2,89 años.
- El 75% de las vulnerabilidades no son descubiertas por el propio mantenedor del código.
- El 79,5% de los mantenedores no tenían una política de divulgación pública de las vulnerabilidades.
- El 21% de los mantenedores que no tienen una política de divulgación pública han sido notificados de forma privada sobre alguna vulnerabilidad.
- El 73% de los mantenedores que tienen una política de divulgación pública han sido notificados de forma privada sobre alguna vulnerabilidad.
- El tiempo máximo que ha llegado a pasar desde la inclusión de una vulnerabilidad hasta su descubrimiento fue de 5,9 años.
- El tiempo mínimo que ha llegado a pasar desde la inclusión de una vulnerabilidad hasta su descubrimiento fue de cero días.
- El tiempo medio que ha llegado a pasar desde la inclusión de una vulnerabilidad hasta su descubrimiento ha sido de 2,5 años.
Sobre el tiempo necesario para corregir una vulnerabilidad descubierta, Snyk ha extraído los siguientes datos:
- La cantidad de tiempo máxima que ha pasado desde el descubrimiento de la vulnerabilidad hasta la publicación de la corrección fue de 94 días.
- La cantidad de tiempo mínimo que ha pasado desde el descubrimiento de la vulnerabilidad hasta la publicación de la corrección fue de cero días.
- La mediana de tiempo que ha pasado desde el descubrimiento de la vulnerabilidad hasta la publicación de la corrección fue de 16 días.
Estos son los datos extraídos en lo que respecta a los medios humanos para hacer frente a esas situaciones:
- El 34% de los mantenedores han dicho que podrían responder a un problema de seguridad en un día si lo estudian bien, mientras que el 60% respondió que necesitaría una semana.
- El 2016, el 69% de las vulnerabilidades halladas en RHEL fueron corregidas en un día y el 90% en 14 días tras su publicación.
- El 86% de las vulnerabilidades halladas en bibliotecas de aplicaciones registradas en la base de datos de Snyk tiene una corrección disponible.
- Solo el 16,1% de las correcciones para vulnerabilidades halladas en bibliotecas de aplicaciones fueron portados hacia atrás a otras versiones.
También resulta interesante saber cómo suelen informar los mantenedores de software a los usuarios sobre las vulnerabilidades halladas en sus productos y servicios. Debido a que muchos encuestados han respondido varias cosas, el porcentaje supera el 100%:
- El 88% informa mediante las notas de lanzamiento.
- El 34% terminaron marcando la versión del software con la vulnerabilidad como obsoleta.
- El 10% envió un CVE.
- El 3% informa a través de servicios como Snyk o RubySec.
- El 25% no informa de ninguna manera.
¿Cómo mantienen los usuarios al día las dependencias del software que utiliza? Estos son los datos extraídos a partir de las respuestas de los encuestados:
- El 47% hace ocasionalmente un barrido sobre las versiones del software que está utilizando.
- El 42% utiliza herramientas que les alertan sobre dependencias vulnerables.
- El 37% utiliza herramientas para actualizar a nuevas versiones de las dependencias.
- El 16% no actualiza.
- El 9% actualiza cuando lo oyen o bien alguien le señala sobre alguna necesidad.
¿Puede impactar una vulnerabilidad en la reputación de un software? Pues al parecer, en el mundo del desarrollo, las consecuencias pueden ser demoledoras. La biblioteca requests de Python fue descargada unas 12 millones de veces al mes durante el 2016. Sin embargo, en ese mismo año se descubrió una vulnerabilidad en este componente que terminó por hundir su reputación, habiendo bajado el número de descargas casi en un 80% para septiembre de 2017.
El futuro del Open Source
Snyk no duda en decir que el Open Source se está expandiendo de forma clara e imparable, sin que haya signos claros de que la tendencia vaya a invertirse. Sin embargo, a pesar de elogiar de que el concepto es bien conocido, todavía falta concienciar sobre los riegos de no utilizarlo ni gestionarlo correctamente.
