Invitado por  Limor Wainstein

Un descubrimiento reciente de la ejecución subrepticia del código cryptomining por una aplicación de espacio aislado, montando a cuestas sobre el ecosistema de software de código abierto (OSS), plantea preguntas pertinentes sobre la seguridad del código fuente abierto y sus dependencias. Los programadores a menudo usan OSS como un desempate para crear su software, y eso incluye autores de malware.

La aplicación fraudulenta, que se descubrió que estaba minando clientes el 11 de mayo, se entregó a través de Snapstore , el nuevo ecosistema de aplicaciones de distribución cruzada y espacio aislado iniciado y promovido por Canonical, los desarrolladores de Ubuntu. En los seguimientos de ese incidente, Canonical dijo:

Es imposible que un repositorio a gran escala acepte solo software después de que cada archivo individual haya sido revisado en detalle. Eso es cierto tanto si el código fuente está disponible como si no, ya que ninguna institución puede permitirse revisar cientos de miles de líneas de código fuente entrantes todos los días.

Como señaló Canonical, revisar y analizar las dependencias de código abierto no es una tarea fácil. Pero es importante para los programadores que quieren asegurarse de que su software no esté infiltrado por los malos actores, ya sea para obtener criptomonedas o para llevar a cabo negocios aún más nefastos.

¿Por qué necesita proteger sus bibliotecas de código abierto?

Los desarrolladores dependen en gran medida del software de código abierto, y las organizaciones tienden a utilizar bibliotecas populares gratuitas. Sin embargo, de acuerdo con el Informe de Confianza en Ciberseguridad 2016  de Barkley , solo el 22 por ciento de las organizaciones tienen un marco para identificar y analizar regularmente los diversos componentes integrados en sus aplicaciones. Con el crecimiento en el uso de código fuente abierto, la exposición al riesgo se expande también.

Nuevas vulnerabilidades se desenterran constantemente en diferentes códigos de fuente abierta y, preocupantemente, una cantidad de proyectos tienen pocos o ningún mecanismo para identificar y solucionar esos problemas. Según una encuesta reciente de Snyk sobre proveedores de código abierto, el 44 por ciento nunca se ha sometido a una auditoría de seguridad de ningún tipo, mientras que solo el 17 por ciento puede afirmar tener un alto nivel de conocimientos de seguridad.

Además, no existe un procedimiento operativo estándar para documentar la seguridad en proyectos de código abierto. Entre los 400,000 mejores repositorios públicamente disponibles en GitHub, solo el 2.4 por ciento tiene una forma de documentación de seguridad implementada.

Dado que una dependencia de código abierto puede estar muy implementada en varias aplicaciones web, un error o vulnerabilidad abrirá todos  esos proyectos a riesgos de seguridad. Para mejorar la  seguridad de sus componentes de código abierto ,  recomendamos las siguientes cinco prácticas recomendadas para revisar las dependencias, encontrar vulnerabilidades y aplicar parches a los componentes de código abierto vulnerables una vez encontrados.

1. Establezca normas y estándares de seguridad estrictos antes de usar una dependencia

Una buena forma de mejorar la seguridad de sus componentes de código abierto es crear y aplicar políticas que exijan que los desarrolladores las utilicen para demostrar que no tienen vulnerabilidades conocidas.

Muchos desarrolladores aún desconocen en gran parte los riesgos que presentan los diferentes componentes de código abierto. Es de suma importancia ayudarlos a comprender que las vulnerabilidades traídas de los componentes de código abierto a la aplicación ponen en riesgo toda la aplicación, si no la organización como un todo.

Al crear y aplicar políticas que requieren que el equipo de seguridad apruebe los componentes de código abierto o que los desarrolladores demuestren la seguridad de la herramienta, automáticamente se mejora la seguridad de la aplicación, solo haciendo que los desarrolladores conozcan esos riesgos.

2. Mantenga un registro de las actualizaciones de seguridad para las dependencias

Otro aspecto crucial para la seguridad de los componentes de código abierto es tener un inventario actualizado de las bibliotecas de código abierto de su organización, tanto en desarrollo como en producción. Hay un número bastante grande de organizaciones que no tienen información actualizada sobre qué componentes de código abierto están actualmente en uso en sus aplicaciones. Esto plantea una importante amenaza de seguridad.

Muchas de las aplicaciones patentadas populares contienen componentes indirectos de código abierto que podrían no estar en desarrollo activo. La mayoría de estos componentes de código abierto permanecen sin parchear y se vuelven inseguros con el tiempo. Esto se debe generalmente a que los desarrolladores gastan sus recursos en asegurar y mejorar los componentes internos. Sin embargo, ignorar las actualizaciones de seguridad para sus componentes de OSS puede abrir brechas que pasarán desapercibidas.

Un buen lugar para comenzar a rectificar esto es inspeccionando los equipos de desarrollo de la organización sobre qué componentes de código abierto usan y la última vez que se actualizaron. Esto proporciona una ventana para evaluar la actualización del equipo de desarrollo con la seguridad del componente de fuente abierta, así como una lista de proyectos en uso.

Si su organización cuenta con la infraestructura necesaria, también puede crear un repositorio central de componentes de código abierto donde se puedan administrar las actualizaciones de seguridad y las licencias. Al igual que en cualquier otro proceso de seguridad, administrar un componente de código abierto no es un esfuerzo de una sola vez. Es un proceso continuo mientras la aplicación esté en despliegue. Revisa, enjuaga y repite.

Al garantizar que se sigan sus políticas en las bibliotecas de código abierto, y al monitorear cómo se están utilizando, así como al administrar su inventario, su programa de seguridad general de la aplicación debería ser una buena opción.

3. Pon a prueba tus componentes y dependencias

Probablemente el método más seguro para mejorar y garantizar la seguridad de su código fuente abierto, y en el proceso su aplicación general, es probar la seguridad de los componentes de código abierto que se utilizan en su organización una vez que se han identificado.

El análisis de fuente abierta es tan importante como el código de propiedad. Esto no solo se debe a que el código podría contener vulnerabilidades de seguridad desconocidas, sino también porque sus dependencias y funciones pueden diferir entre diferentes casos de uso. Esto podría significar que un componente puede estar seguro en una aplicación, pero que se considera inseguro cuando se usa en una aplicación diferente. En casos como este, solo las pruebas y la revisión del código pueden identificar estos problemas.

4. Cree herramientas internas en lugar de bibliotecas no compatibles (caducadas)

Para las bibliotecas expiradas, o las bibliotecas que ya no tienen sistemas de mantenimiento de desarrollador activos, es mejor construir sus propias herramientas internas que pueda usar para verificar y solucionar vulnerabilidades activamente. Aunque el costo inicial y el tiempo invertido podrían disuadir a algunas organizaciones y equipos de desarrollo, a largo plazo, la funcionalidad de una herramienta interna puede ser un activo para los desarrolladores.

También puede considerar devolver su esfuerzo interno a la comunidad, fortaleciendo el ecosistema de código abierto. Esto alentará a más desarrolladores a enviar parches y revisiones y, por lo tanto, a mejorar la seguridad general de la biblioteca. Además de eso, se ganará el respeto de los desarrolladores de código abierto, lo que lo ayudará a crecer como individuo y como negocio. Por ejemplo, en los últimos años, Microsoft lanzó toneladas de bibliotecas bajo una licencia de código abierto que les ayudó a ganarse la confianza de los desarrolladores y usuarios de OSS.

5. Use herramientas de seguridad para verificar vulnerabilidades de seguridad

A lo largo de los años se han desarrollado varias herramientas comerciales y de código abierto para abordar el problema de la identificación de vulnerabilidades de seguridad en componentes de código abierto. Cada herramienta o servicio aborda el problema de forma un poco diferente.

Proyecto de seguridad de nodo (NSP)

El NSP es ampliamente conocido por su trabajo en módulos Node.js y dependencias de NPM. La última versión de npm integra NSP para implementar el script de auditoría npm. Comprueba si existen vulnerabilidades conocidas en los módulos de nodo y las dependencias relacionadas, y ofrece soporte para reparar esas vulnerabilidades.

RetireJS

RetireJS es un comprobador de dependencias de código abierto específico para JavaScript. Su única propuesta de venta (USP) es su facilidad de uso. RetireJS contiene múltiples componentes, incluido un escáner de línea de comandos, así como complementos para Chrome, Firefox, Grunt, Gulp, ZAP y Burp.

OSSIndex

OSSIndex es una herramienta que admite varias tecnologías diferentes. Efectivamente cubre los ecosistemas JavaScript, .NET / C # y Java. También proporciona vulnerabilidad de API de forma gratuita.

Verificación de dependencia

Dependency-check es compatible con Java, .NET y JavaScript, además de Ruby. Extrae su información de vulnerabilidad del NIST NVD.

Herramientas comerciales

Además de las herramientas gratuitas, hay algunas herramientas comerciales que puede usar para ayudar a encontrar vulnerabilidades en su código de código abierto. Los populares incluyen:

• Hakiri: una herramienta comercial que proporciona comprobaciones de dependencia para proyectos GitHub basados ​​en Rub-y y Rails a través del análisis de código estático
• Snyk: un servicio comercial que se centra en las dependencias JavaScript npm
• WhiteSource: actualmente es compatible con Ruby, NPM, PHP, Python y Bower
• SRC: CLR: Source Clear viene con una carga de complementos para varios IDE, sistemas de implementación y repositorios de origen, así como también una interfaz de línea de comando

Los componentes de código abierto generalmente son seguros cuando hay una gran cantidad de personas revisando el código. Sin embargo, hacer que el código fuente esté disponible o que muchos usuarios observen el código fuente no garantiza que todos los problemas de seguridad se hayan encontrado y solucionado. Es por eso que es importante integrar políticas de seguridad estándar de la industria en su aplicación.

En esta publicación, hemos cubierto algunas de las mejores formas posibles de proteger sus componentes de código abierto contra vulnerabilidades y otros ataques de seguridad. Entonces, ¿qué piensas sobre la seguridad de los componentes de código abierto? Compártalos en los comentarios a continuación.