Nuevo libro de O’Reilly: Cómo proteger las bibliotecas de código abierto, de Guy Podjarny
2 de julio de 2019
0 minutos de lecturaSnyk se asoció con O’Reilly para ofrecer un nuevo libro, Cómo proteger las bibliotecas de código abierto: gestión de vulnerabilidades en paquetes de código abierto. En el libro, Guy Podjarny, CEO y fundador de Snyk, aborda varios temas para ayudarte a gestionar el riesgo que representan las bibliotecas de código abierto vulnerables que usan actualmente tus aplicaciones.
Las dependencias vulnerables son la parte de tu aplicación que los atacantes tienen más probabilidades de explotar. El libro aborda algunas de las prácticas recomendadas y herramientas clave para proteger tus aplicaciones a escala.
¡Descarga tu libro gratis ahora!
Guy comienza explicando qué es una vulnerabilidad conocida y cómo se divulga públicamente, por ejemplo, en las bases de datos CVE y NVD; también analiza por qué no basta con depender únicamente de ellas. Además, Guy explica qué es la divulgación responsable y qué pasos puedes seguir ante las vulnerabilidades que descubras.
En el capítulo 2, Guy profundiza en el tema central del libro y analiza cómo puede haber varias rutas para que las vulnerabilidades lleguen a tu aplicación. Esto ocurre cuando una biblioteca vulnerable aparece varias veces en el árbol de dependencias.
Piensa en una aplicación que usa dos paquetes, A y B, donde A también usa B (en la misma versión), lo que da como resultado el siguiente árbol de dependencias:

Ahora supongamos que B@1.0.0 tiene una vulnerabilidad conocida de denegación de servicio (DoS). Al probar la aplicación, ¿cuántas vulnerabilidades deberíamos reportar? Por un lado, la aplicación solo tiene una vulnerabilidad conocida: DoS en B@1.0.0. Por otro, hay dos instancias de esta vulnerabilidad. ¿Qué deberíamos reportar: una o dos?
Otro tema clave es cuándo hacer las pruebas. El libro analiza los beneficios de probar tanto a nivel del código fuente como las aplicaciones compiladas. Sin embargo, probar el código fuente ofrece una aproximación, mientras que probar una aplicación compilada es más preciso. ¡La mejor solución es usar ambos métodos!
Para combinar ambos métodos, algunas herramientas prueban _built_apps, pero también buscan archivos de manifiesto de paquetes, construyen un árbol lógico e intentan ubicar en él las bibliotecas encontradas. Así, puedes tener la certeza de contar con la cobertura de las pruebas de aplicaciones compiladas y, en la medida de lo posible, con la profundidad de análisis que ofrece el código fuente.
También puedes usar ambos métodos en distintas etapas del desarrollo. Por ejemplo, puedes analizar el código fuente como parte de tu flujo de trabajo de GitHub/GitLab/BitBucket y probar una aplicación compilada durante el proceso de compilación o como condición para el despliegue. En la mayoría de los casos, ambos métodos arrojan los mismos resultados y son consistentes. Cuando no es así, las pruebas de la aplicación compilada te aseguran que no desplegarás una vulnerabilidad.
El capítulo explica cómo encontrar vulnerabilidades conocidas en tu SCM, la línea de comandos, los registros de contenedores y el navegador. Sin embargo, esa es solo la mitad de la historia. Lo más interesante ocurre cuando necesitas actuar sobre los datos que recibes. Guy explica cómo actualizar tus dependencias directas e indirectas, así como aplicar parches cuando no hay rutas de actualización. Sin embargo, en algunos lenguajes pueden surgir conflictos:
Muchos lenguajes, como Ruby y Python, requieren que las dependencias sean globales, y clientes como bundler de Ruby y pip de Python determinan qué combinación de versiones de bibliotecas puede coexistir. Por eso, actualizar una biblioteca puede generar un conflicto con otra. Aunque los desarrolladores saben cómo manejar estos conflictos, a veces simplemente no es posible resolverlos.
Además de centrarse en las vulnerabilidades de las aplicaciones, el libro también aborda cómo corregir las vulnerabilidades en las imágenes de contenedores. Guy explica que, a diferencia de las vulnerabilidades de las aplicaciones, las vulnerabilidades del sistema operativo suelen no tener versiones corregidas a las que puedas actualizar fácilmente. Por eso, dependemos más de buenas prácticas de priorización.
El capítulo 4 aborda un tema muy importante en el acelerado mundo del desarrollo moderno: agregar pruebas de seguridad a tus pipelines existentes para que puedas probar los cambios de desarrollo a medida que los envías a producción. A esto se le suele llamar pipeline de DevSecOps.
Prepárate para corregir vulnerabilidades rápidamente
Una parte importante de todo este proceso consiste en cómo reaccionan tus equipos cuando se descubren nuevas vulnerabilidades, ya sea por un cambio en el código o porque se divulgó una vulnerabilidad nueva. ¿A quién debes contactar cuando recibes una notificación de seguridad? ¿Al equipo de seguridad? ¿A los desarrolladores? ¿A la gerencia? ¿Qué tan rápido debes responder ante problemas de distintos tipos y niveles de gravedad? ¿Deberías detener las compilaciones cuando se detectan vulnerabilidades nuevas? ¿Estás expuesto a actualizaciones en la cadena de dependencias? Descarga el libro ahora para obtener orientación y más consejos prácticos sobre cómo empezar a proteger tus bibliotecas de código abierto.