[07/09/2020] Este año se presentaron aún más desafíos para asegurar la integridad y la seguridad de los ecosistemas open source o de código abierto. El open source ha sido la mayor ventaja para los desarrolladores en el sentido de que prácticamente cualquier persona puede utilizarlo y personalizarlo, normalmente sin costo alguno, y contribuir a la comunidad. Lo que ha sido un medio para garantizar una mayor transparencia y seguridad; y promover la colaboración de los desarrolladores en todos los proyectos también ha allanado el camino para que los adversarios se beneficien de la causa.
Como investigador de seguridad, me encontré y analicé los incidentes de este año en los que más de 700 paquetes de RubyGems no sirvieron para nada más que para extraer bitcoins. Luego está el popular caso del Octopus Scanner, un malware que ha inyectado silenciosamente sus tentáculos en al menos 26 proyectos de GitHub. Estos incidentes subrayan el hecho de que cualquier sistema abierto que sea accesible al público, también es accesible a los adversarios y propenso al abuso.
Los ejemplos anteriores se centran en los componentes maliciosos. ¿Qué pasa con los paquetes de open source legítimos con vulnerabilidades de seguridad que pasan desapercibidas?
Un paquete vulnerable o malicioso que se abre paso en los repositorios populares, y eventualmente en su cadena de suministro de software, puede causar estragos a sus clientes. Los componentes vulnerables y maliciosos han sido detectados en populares repositorios de código abierto como npm, PyPI, NuGet y Fedora.
"En años pasados, hemos visto que, en términos de vulnerabilidades totales identificadas en los paquetes de código abierto en todos los ecosistemas, Node.js y Java han mostrado el mayor número de nuevas vulnerabilidades cada año", señalaron los autores del informe The State of Open Source Security 2020 de Snyk.
El informe también sugiere que las medidas de seguridad aplicadas en las primeras etapas del proceso de desarrollo de programas informáticos son responsables de que en el 2019 se registraran menos vulnerabilidades nuevas que en el 2018. "Si esta tendencia continúa, podría ser una señal positiva de que los esfuerzos por mejorar la seguridad del software de código abierto están empezando a dar resultados", prosigue el informe.
A continuación, se presentan algunas prácticas óptimas para gestionar el open source de manera segura.
1. Conozca su software
La 2020 DevSecOps Community Survey realizada por Sonatype [divulgación completa: Sonatype es mi empleador] revela que la mayoría de las empresas -incluso aquellas con algún nivel de prácticas de DevOps incorporadas en su flujo de trabajo- carecen de una visibilidad completa de todos los componentes de código abierto que utilizan sus aplicaciones de software y de las vulnerabilidades que les afectan.
"Cuando una vulnerabilidad es anunciada en un proyecto de código abierto, debería hacer dos preguntas inmediatamente: ¿Hemos usado alguna vez ese componente de código abierto? y (si es así), ¿dónde está?", señalan los autores del informe.
Otra encuesta de Sonatype de más de cinco mil desarrolladores mostró que solo el 45% de las organizaciones con prácticas maduras de DevOps mantienen una lista completa de materiales de software (SBOM) para sus aplicaciones. "Los resultados revelan que hasta el 74% de las organizaciones con 'prácticas inmaduras' no tendrían los medios para saber si una vulnerabilidad recién revelada en un componente de código abierto es siquiera aplicable a su software", indica el informe. Esto significa que las organizaciones con prácticas inmaduras que mantienen un SBOM completo, no sabrían si han utilizado código abierto vulnerable, o dónde encontrar las vulnerabilidades recientemente anunciadas dentro de sus entornos.
Dado el gran volumen de vulnerabilidades que se publican cada día en NVD, GitHub y otros sitios de hospedaje, sería muy difícil para los desarrolladores y los profesionales de la seguridad mantenerse al día con estos datos sin alguna solución automatizada. La historia muestra que la mayoría de las organizaciones esperan hasta después de que se haya producido un incidente de seguridad para intensificar sus esfuerzos de seguridad. Sin embargo, como dice el viejo refrán, una onza de prevención vale más que una libra de curación.
Implementar la seguridad desde el principio adoptando un enfoque "shift left" cuando se trata del ciclo de vida del desarrollo de software puede tener diez veces más beneficios, y aumentar la conciencia general de los desarrolladores.
2. Resolver los problemas de dependencia
El informe de Veracode titulado 2020 State of Software Security destaca un problema común de seguridad de software. En lugar de los propios desarrolladores, las "dependencias interconectadas" introducen indirectamente riesgos latentes en sus aplicaciones que pueden pasar desapercibidos para la mayoría de los desarrolladores. "Nuestros datos revelan que la mayoría de las bibliotecas defectuosas terminan en código indirectamente. El 47% de las que se encuentran en las aplicaciones son transitorias; es decir, no son arrastradas directamente por los desarrolladores, sino por la primera biblioteca (el 42% son arrastradas directamente y el 12% ambas). Esto significa que los desarrolladores están introduciendo mucho más código, y a menudo código defectuoso, de lo que podrían estar anticipando", se lee en el informe.
Sin embargo, corregir este problema no parece ser una tarea importante según Veracode: "Abordar las fallas de seguridad en estas bibliotecas no suele ser un trabajo significativo. La mayoría de las fallas introducidas por las bibliotecas (casi el 75%) en las aplicaciones se pueden solucionar con una simple actualización de la versión. Normalmente no se requieren actualizaciones importantes de la biblioteca. Este punto de datos sugiere que este es un problema de descubrimiento y rastreo, y no de una enorme refactorización del código."
3. Automatizar el escaneo de códigos para encontrar incógnitas desconocidas
El incidente de Octopus Scanner y otras formas de abuso del ecosistema de código abierto, como el typosquatting, han llevado a los encargados de los repositorios, como GitHub, a imponer el escaneo automático de los proyectos de código abierto que albergan. Como se ha informado este año en, GitHub ahora integra el escaneo automático basado en CodeQL de sus repositorios de código abierto.
Justin Hutchings, gerente senior de productos de GitHub, dijo a The Register, "Resulta que esa capacidad es extremadamente útil en la seguridad. La mayoría de los problemas de seguridad son producto de un mal flujo de datos o un mal uso de los datos de una manera u otra".
Además de identificar vulnerabilidades y errores ocultos, el escaneo barre regularmente los proyectos de código abierto en busca de signos de fuga de datos, como claves privadas y credenciales hechas públicas inadvertidamente por el colaborador. Desde el año pasado, unos pocos proveedores han integrado en sus productos esfuerzos de escaneo automatizado para identificar el malware publicado en depósitos legítimos de código abierto. Estas técnicas incorporan el análisis de comportamiento con aprendizaje automático para buscar proactivamente "componentes falsificados".
También han surgido, en menor escala, escáneres experimentales de código abierto (como npm-scan) publicados por desarrolladores independientes y que sirven para fines similares de detección de componentes vulnerables mediante heurística. En el frente de RubyGems, los continuos esfuerzos de monitoreo y análisis de ReversingLabs es lo que llevó al descubrimiento de los más de 700 componentes maliciosos mencionados anteriormente.
La habilitación de tales auditorías de seguridad generalizadas mediante herramientas de automatización puede ayudar a aumentar la confianza y los asuntos de integridad dentro del ecosistema de código abierto, antes de que los componentes se abran paso en su cadena de suministro.
4. Cuidado con los riesgos de las licencias
La principal ventaja de usar software de open source es la libertad que ofrecen sus licencias permisivas. Si descubre un error en un paquete de código abierto que no ha sido arreglado, puede arreglarlo usted mismo en lugar de esperar al proveedor. Podría adaptar una aplicación de open source en su proyecto como considere oportuno, y enviar una versión personalizada a sus clientes.
Sin embargo, se necesita un poco más de habilidad para ser consciente de cualquier conflicto potencial de licencia que pueda surgir al usar componentes open source. El Informe publicado por Synopsys titulado 2020 Open Source Security and Risk Analysis afirma lo siguiente:
"Los conflictos de licencia declarados surgen cuando una base de código contiene componentes de código abierto cuyas licencias parecen entrar en conflicto con la licencia general de ésta. Por ejemplo, el código bajo la Licencia Pública General v2.0 de GNU (GPLv2) usualmente planteará un conflicto cuando sea compilado en una pieza de software comercial normalmente distribuida. Pero el mismo código no será un problema en el software considerado software como un servicio o SaaS".
Estos términos contradictorios pueden confundir a los desarrolladores que utilizan las mismas aplicaciones de código abierto en contextos ligeramente diferentes. Algunas soluciones de automatización pueden reconocer numerosas licencias y los posibles conflictos que de ellas se derivan, además de las vulnerabilidades y los componentes maliciosos.
Un informe de Black Duck encontró que el 67% de las bases de código auditadas en el 2019 contenían componentes con conflictos de licencia. Ese porcentaje era mucho mayor en algunas industrias como la de internet y las aplicaciones móviles (93%). "La GPL es una de las licencias de código abierto más populares y sus diversas versiones pueden crear conflictos de licencia con otros códigos en las bases de datos. De hecho, cinco de las diez principales licencias con conflictos fueron la GPL y sus variantes", señala el informe.
Ax Sharma, CSO (EE.UU.)