Pararse sobre hombros de gigantes: Sobre el análisis de composición de software

¡Más de 14 GiB de software dependen de libpng! Y eso solo en los repositorios de Arch Linux, que no es precisamente la distribución más popular de Linux. Además, esta biblioteca es la referencia oficial de PNG y es multiplataforma, por lo que seguramente muchos otros paquetes en otros sistemas operativos dependen de ella.

Ahora bien, en el año 2015, cuando libpng aún no había corregido el error low-high palette, todos los programas y bibliotecas anteriores también eran automáticamente vulnerables al mismo problema. De hecho esto es lo que le pasó a Equifax con una vulnerabilidad en Apache Struts. Al igual que muchos servicios web que utilizan OpenSSL con Heartbleed.

Si esto pudo pasarle a productos tan emblemáticos como Bash, Qt, TeX y Xfce, también podría pasarle a tu organización. De hecho, este problema es tan común que forma parte del Top 10 de OWASP de 2017; lo llaman "A9: Uso componentes con vulnerabilidades conocidas."

Dada la rápida adopción del software libre y de código abierto (FOSS, por su nombre en inglés) por parte de grandes empresas, de repente la vulnerabilidad de las dependencias parece ser un problema tremendo. O más bien, como les gustaría señalar a los yuppies, ¿una "oportunidad de negocio"?

Desde entonces han aparecido en la escena de la seguridad muchos proveedores del llamado análisis de composición de software (SCA) (no lo busques en Google). Algunos de ellos están respaldados por empresas de larga trayectoria; la mayoría, no. De hecho, este negocio ha tomado tanto impulso que se espera que crezca más de un 20% cada año de aquí al 2022.

Estas empresas, que tanto deben al FOSS, tienden a hacerlo quedar mal cuando comercializan su SCA. Sin embargo, la adopción del FOSS no se está reduciendo. Como intentaremos demostrar aquí, no es culpa del FOSS si las aplicaciones lo utilizan con vulnerabilidades conocidas, sino de los propietarios de dichas aplicaciones.

Las aplicaciones de hoy en día utilizan en promedio más de 30 bibliotecas, lo que representa hasta un 80% de su código. Piensa en ello como si tu código fuera solo una fina capa sobre un edificio de algunas cajas pequeñas y otras más grandes. Lo que el SCA hace entonces es buscar vulnerabilidades dentro de esas cajas con información de bases de datos externas, las cuales pasan a ser consideradas vulnerabilidades en tu propia aplicación:

SCA escanea todos los bloques del edificio de tu app.

En lugar de ir desde la supuesta solución hacia el origen del problema, hagámoslo al revés.

Lo malo

El FOSS es desarrollado y utilizado por miles de personas en todo el mundo. Esto puede ser un arma de doble filo: Por un lado, según la "Ley de Linus", la búsqueda de errores y la aplicación de parches deberían ser más fáciles al haber más implicados. Por otro lado, la falta de una guía centralizada favorece la aparición de fallas.

Una diferencia del FOSS con el software propietario está en que, debido a todas sus restricciones, es "menos probable" que las fallas de este último se hagan públicas tan pronto como en el caso del primero. Así que suele esperarse que todas las vulnerabilidades en el software propietario sean de día cero.

Entonces, si el origen del problema no es el FOSS, ¿cuál es? Las principales razones por las que tantas empresas sufren de A9:

• Desconocimiento de las dependencias utilizadas

• Desconocimiento de sus vulnerabilidades

• No escanear continuamente en busca de fallas

• No realizar pruebas de compatibilidad

• Mala configuración de los componentes

En definitiva, todo se reduce a una falta de comunicación entre el usuario y la fuente de los componentes.

Lo bueno

¿Qué puedes hacer? OWASP recomienda las siguientes directrices para prevenir A9:

• Recorta dependencias innecesarias, características, componentes, etc. Así tendrás menos para revisar.

• Supervisa continuamente los componentes en búsqueda de actualizaciones y reportes de vulnerabilidades.

• Obtén solo componentes de fuentes fiables.

• Convierte estas directrices en una política de empresa.

Existen herramientas específicas que comparan la versión de la dependencia que estás utilizando tanto con repositorios remotos (para comprobar si hay actualizaciones) como con bases de datos de vulnerabilidades (para averiguar si alguna de tus dependencias contiene vulnerabilidades reportadas que aún no han sido corregidas).

• Para JavaScript puedes usar retire.js.

• Los usuarios de Java tienen el plugin Versions para Maven.

• También para Java y .NET, puedes utilizar la herramienta OWASP Dependency-Check.

• Hay un plugin de SonarQube de evaluación de dependencias.

Ten en cuenta que las herramientas específicas del lenguaje tienen que estar integradas con el gestor de paquetes apropiado, como npm o yarn con retire.

Una vista panorámica de cómo el proceso debería integrarse con tu flujo de desarrollo se representa en el siguiente diagrama proporcionado por SourceClear.

Integrando SCA en tu flujo de desarrollo. Vía SourceClear.

Vemos que cada vez que se añade código, todo el sistema es escaneado en búsqueda de vulnerabilidades de software de terceros y otros problemas fácilmente identificables por análisis estático cuando el código no está disponible. Esto se hace siguiendo este procedimiento:

1. Identificar las dependencias en las que tu software se basa.

2. Detectar las versiones de esas dependencias.

3. Comprobar si hay actualizaciones en el repositorio maestro de dependencias.

4. Comprobar una o varias bases de datos de vulnerabilidades, como CVE y NVD o las propias.

5. Reportar los hallazgos.

En realidad, se trata de un proceso sencillo.

Ten en cuenta que la integración no es totalmente automática, y no debería serlo, ya que estas herramientas podrían dar (y suelen dar) falsas alarmas, por lo que son revisadas por especialistas en seguridad.

Internamente, el proceso de escaneo de software de terceros es el mismo tanto para el propietario como para el FOSS, y es una simple cuestión de consultar las bases de datos de vulnerabilidades como hemos descrito anteriormente.

Hablando de integración, puede que te preguntes: ¿Qué pasa si mi aplicación se despliega dentro de un contenedor? "El 30% de las imágenes oficiales de Docker Hub contienen vulnerabilidades de seguridad de alta prioridad", según PenTestIt. Afortunadamente, hay herramientas que entran en tu contenedor y realizan SCA dentro de él (y más), como Anchore y Dockerscan.

Lo feo

Sé que buscaste "análisis de composición de software" cuando te sugerí que no lo hicieras. Solo sé que lo hiciste. Si no lo hiciste, ¡bien por ti! Esto es lo que te estás perdiendo:

Proveedores de "análisis de composición de software".

Todos estos líderes de la industria, galardonados, creadores de avances, oráculos del futuro de la tecnología, quieren venderte una cosa: análisis de código estático más las herramientas que hemos comentado antes.

Aunque el análisis estático es una técnica válida, es solo una técnica. Escanea código y detecta vulnerabilidades y prácticas poco saludables, pero también fomenta la detección tardía y produce muchos falsos positivos.

Podrías contratar un servicio de este tipo e incluso intentar complementarlo con herramientas de análisis dinámico como fuzzing y debuggers, pero estas tienen sus propios problemas.

Cabe señalar que no sustituyen a la revisión de código a la antigua, por humanos. Al menos por el momento. Según Contrast Security,

La única forma de afrontar el riesgo de vulnerabilidades desconocidas en las bibliotecas es que alguien que entienda de seguridad analice el código fuente. El análisis estático de las bibliotecas es mejor concebirlo como una forma de dar señales de dónde pueden estar localizadas las vulnerabilidades de seguridad en el código, y no como un sustituto de los expertos.

En el futuro, es posible que veamos cosas como pruebas de seguridad distribuidas bajo demanda y algoritmos de machine learning que utilicen máquinas de vectores de soporte para intentar predecir qué commits tienen más probabilidades de abrir vulnerabilidades, pero mientras tanto, quédate con lo probado y comprobado.