Recientemente se ha dado a conocer un estudio en el que el 96% de las aplicaciones propietarias contienen componentes de código abierto con un promedio de 257 componentes por aplicación. Los números son relativamente altos porque existe el concepto erróneo de que los paquetes de código abierto no son fácilmente vulnerables a explotaciones. El simple hecho de hacer que el código fuente esté disponible al público, no siempre garantiza una revisión. Tener una gran cantidad de ojos revisando el código puede "tranquilizar al usuario con una falsa sensación de seguridad".
Dado que los componentes de código abierto son una parte fundamental de la dinámica de trabajo de un desarrollador, aquí tienes algunas de las mejores prácticas que deberías tener en cuenta a la hora de utilizar una librería OSS en tu aplicación. La lista incluye:
Crear una cultura de seguridad inicial y hacer que se cumpla.
Una organización debería centrarse en algo más que poner al unísono a los desarrolladores y la seguridad. También debe garantizar que las prácticas de seguridad eficaces y eficientes estén integradas en el seno de la dinámica de trabajo. Los mejores mecanismos de alerta y las mejores soluciones a problemas no nos pueden ayudar cuando existen malas prácticas de seguridad. Esto incluye la gestión de la vulnerabilidad.
Un ejemplo de ello fue la brecha de Equifax, que se atribuyó a una versión vulnerable del OSS Adobe Struts. Incluso después de la brecha en 2017, las organizaciones continúan descargando versiones afectadas del paquete a pesar de que hay un parche disponible.
Cuando se trata del DevOps, los debates sobre la seguridad deberían estar presente al inicio del proyecto y en el mejor de los casos, continuar durante el desarrollo del software e incluso en la post-producción. En el caso de que se utilicen componentes de código abierto, el equipo debe responsabilizarse de seguirle la pista a las actualizaciones y aplicar los parches de seguridad a medida que se vayan lanzando. Recursos como los siguientes pueden ayudar a tu equipo a realizar un seguimiento fiable de los problemas de seguridad:
- Herramientas de gestión de vulnerabilidades de código abierto https://resources.whitesourcesoftware.com/blog-whitesource/open-source-vulnerability-management
- Analizadores de código https://www.owasp.org/index.php/Source_Code_Analysis_Tools
La buena noticia es que hay herramientas disponibles que ayudan a evaluar y proporcionan una cierta garantía con respecto a la seguridad del software de código abierto. Black Duck y Sonatype Nexus son dos de estas herramientas que proporcionan soluciones completas y listas para la empresa que permiten administrar de manera eficiente los riegos del software de código abierto. Dicho esto, debe saber que estas herramientas no proporcionan soluciones inmediatas ni de la noche a la mañana. Por lo general, requieren de un tiempo para integrarse.
Mantener un registro de las actualizaciones de seguridad de las dependencias
A menudo puede parecer que una parte de tu software hace frente a posible un aviso de seguridad o se lanza una nueva versión cada dos semanas. Aunque solo las vulnerabilidades críticas requerirían atención inmediata, puede que tengas que combinar muchas versiones e identificar qué sistemas necesitan una actualización y cuales ya tiene un parche de seguridad.
Lo bueno es que hay algunos recursos oficiales y tambien privados que puedes utilizar para mantenerte informado sobre la gestión del ciclo de vida del software. Si los usas regularmente, además de tus herramientas de seguimiento internas, podrás mantener tu entorno TI relativamente seguro y actualizado. Hay tres aspectos que debes tener en cuenta:
Avisos de seguridad
La mayoría de los grandes proveedores publican un aviso de seguridad cada vez que descubren una vulnerabilidad o cuando se lanza un nuevo parche al público. Debes seguir de cerca la página de errores o una mejor opción es registrarse para recibir una notificación por correo electrónico cada vez que se publique dicha actualización.
Por ejemplo, VMware tiene una página de información sobre seguridad (https://www.vmware.com/security/advisories.html), y Microsoft también (https://docs.microsoft.com/en-us/security-updates/). Además, los proveedores como Trend Micro tienen una página de información de seguridad que recopila una lista de parches, anuncios de vulnerabilidades de seguridad, etc. de muchas compañías diferentes en un sólo lugar.
El Equipo de Respuesta ante Emergencias Informáticas de los Estados Unidos o US-CERT también tiene un sitio web actualizado de alertas crítica, vulnerabilidad y parches (https://www.us-cert.gov/ncas/current-activity). Éste cubre una amplia variedad de plataformas que se utilizan frecuentemente. Además de las alertas por correo electrónico, algunos de estos avisos también ofrecen una fuente RSS que puedes elegir marcarla como favorita o añadirla a tu lector preferido.
Seguimiento de versiones
El seguimiento de versiones tiene dos partes esenciales: identificar la versión aplicada con los cambios que están en curso y registrar qué versiones estás ejecutando en tus servidores.
Diversos sitios web pueden ayudarte a identificar los números de compilación y los nombres de los parches específicos para el software estándar, los sistemas operativos y los hipervisores que utilizas. También puedes consultar en los sitios web de los proveedores el software que utiliza para las alertas de seguridad. También debes realizar un seguimiento del servidor que se está ejecutando y de la versión del software. Para un entorno pequeño, una hoja de cálculo sería suficiente, aunque podría quedarse inservible después de un tiempo.
Existen diferentes plataformas de software que ayudan con el inventario de software y la gestión de activos TI. Algunos ejemplos son: SolarWinds, Git, SVN, Mercurial, Helix, Microsoft Team Foundation Server, etc.
Bases de conocimiento
Si necesitas conocer las características específicas de una nueva versión de software, Las denominadas bases de conocimiento deberían poder ayudarte. Al igual que las páginas de alertas de seguridad, la mayoría de los grandes proveedores de software TI tienen una base de conocimientos online. Estas BC contienen artículos de ayuda, historial de actualizaciones y cambios de software, descripciones de soporte, etc. Recurriendo a la base de conocimientos, puede determinar si tu nuevo software será o no compatible en tu entorno existente.
Usar herramientas de seguridad para encontrar exploits de seguridad dentro de tus paquetes
A lo largo de los años, se han desarrollado un gran número de herramientas de código abierto para resolver el problema de la identificación de vulnerabilidades de seguridad en los componentes de código abierto. Cada herramienta o servicio intenta resolver este problema de un modo un tanto diferente:
- Node Security Project (NSP) - NSP es conocido principalmente por su trabajo en los módulos Node.js y las dependencias NPM.
- Dependency-check – Dependency-check soporta Java, Javascript, .NET y Ruby. Extrae su información de vulnerabilidad de NIST NVD.
- Gemnasium - Gemnasium admite Ruby, NPM, PHP, Python y Bower.
- Bundler-audit: Bundler-audit es una herramienta de línea de comandos de código abierto. Comprueba las dependencias centradas en Ruby Bundler.
- RetireJS: un comprobador de dependencia de código abierto específico para JavaScript, el USP de RetireJS es fácil de usar y altamente eficiente. Contiene varios componentes, incluido un escáner de línea de comandos y complementos para Chrome, Firefox, Grunt, Gulp, ZAP y Burp
- OSSIndex: OSSIndex es una herramienta que admite varias tecnologías diferentes. Cubre adecuadamente los ecosistemas de JavaScript, .NET/C # y Java. Además, proporciona las vulnerabilidades API de forma gratuita.
- Hakiri - Hakiri es una herramienta comercial que proporciona verificaciones de dependencia para proyectos GitHub basados en Ruby y Rails a través del análisis de códigos estáticos.
- Snyk - Snyk es un servicio comercial que se centra en las dependencias de JavaScript npm.
- SRC: CLR: Source Clear viene con un monton de complementos para varios IDE, sistemas de implementación y repositorios fuente, así como una interfaz de línea de comandos.
Usar librerías OSS que están en desarrollo activo.
En el caso de librerías que han expirado o que ya no tienen sistemas activos de soporte y mantenimiento para desarrolladores, lo mejor es crear herramientas internas. Si conoces cómo funciona el ecosistema de código abierto, debes saber que las librerías que tienen un mantenedor activo reciben parches y actualizaciones de seguridad. A veces, los desarrolladores bifurcan los repositorios y las versiones bifurcadas son las más activas, aunque las actualizaciones no están insertadas en la corriente principal.
Puedes usar las herramientas que hemos mencionado para monitorizar y solucionar vulnerabilidades similares y de seguridad. Incluso si el coste inicial y el tiempo invertido podría llegar a disuadir a algunas organizaciones o a sus equipos DevOps, a la larga, la funcionalidad y confiabilidad de una herramienta interna puede ser una ventaja tanto para las organizaciones como para los desarrolladores.
Testear todos tus componentes
Es esencial implementar un mecanismo para realizar pruebas con el fin de garantizar que la aplicación y todas las dependencias relacionadas son seguras. Dado que los equipos de desarrollo continuamente agregan funciones a los componentes existentes e importan nuevas dependencias a medida que avanzan, es crucial que se lleven a cabo algunas pruebas que prevengan posibles amenazas graves como son las vulnerabilidades de acceso remoto.
Be the first to comment