La reciente inclusión de 'protestware' en las bases de código de software de código abierto (OSS) popular destaca algunos riesgos emergentes para las organizaciones que confían en OSS.
Ha habido incidentes recientes de 'protestware' o código malicioso que se incorporan a las bases de código de software de código abierto (OSS).Las organizaciones que confían en software comercial crítico que contiene OSS pueden estar sujetas a riesgos comerciales y de seguridad.Las organizaciones deben implementar políticas y procedimientos para mitigar nuevamente los riesgos asociados con el uso de OSS.
El software de código abierto ( OSS ) es omnipresente en el software comercial. Tanto los desarrolladores internos como los externos utilizan código de origen comunitario de repositorios públicos como GitHub para crear, probar, lanzar y mantener software de manera más eficiente. Esto acorta los tiempos de lanzamiento y ayuda a las organizaciones a obtener una ventaja competitiva. Si bien la comunidad de OSS generalmente funciona como un guardián del control de calidad, el gran volumen y el uso generalizado de OSS significa que todavía existen riesgos asociados con su uso.
El 8 de marzo de 2022, el mantenedor de node-ipc, una biblioteca JavaScript de OSS que se descarga aproximadamente un millón de veces a la semana, lanzó una actualización que contenía 'protestware'. El lanzamiento incluía un código ofuscado que determinaba la ubicación aproximada de las máquinas que ejecutaban el software. Si la dirección IP estaba geocodificada como rusa o bielorrusa, el software atravesaba el sistema de archivos del usuario y sobrescribía cualquier dato encontrado con símbolos de corazón. El mantenedor defendió sus adiciones al módulo como una protesta por la invasión rusa de Ucrania.
El Director de Defensa de los Desarrolladores de Developer Security Platform 'Snyk', que investigó y reveló el incidente, observó que destacaba ' un problema mayor que enfrenta la cadena de suministro de software: las dependencias transitivas en su código pueden tener un gran impacto en su seguridad' . Como era de esperar, la implementación del software de protesta node-ipc afectó más que solo a sus objetivos previstos: informes posteriores afirmaron que una ONG estadounidense que ejecuta un servidor de producción en Bielorrusia se vio afectada negativamente.
Este es solo un ejemplo de software de protesta OSS reciente y otros incidentes relacionados con OSS. En enero, el mantenedor de dos bibliotecas de código abierto (con más de 3500 millones de descargas totales combinadas) emitió una actualización que provocó que las aplicaciones, entre otras cosas, imprimieran repetidamente la palabra 'Liberty'. El mantenedor declaró que esto era en protesta por las corporaciones más grandes que usan su trabajo de forma gratuita.
Y en diciembre de 2021, se descubrió un código malicioso (conocido como 'Log4Shell') en Log4j, una biblioteca de JavaScript OSS ubicua empleada en numerosos servicios basados en la nube, que permitió a los piratas informáticos acceder de forma remota y tomar el control de los sistemas afectados.
Estos incidentes resaltan cómo las organizaciones que dependen del OSS para el software crítico del negocio, o que contratan a proveedores de servicios subcontratados que OSS, o productos o servicios que contienen OSS, confían en la diligencia y la buena fe de la comunidad de código abierto. Esto tiene el potencial de crear un riesgo en la cadena de suministro para la organización.
¿Cómo pueden las organizaciones mitigar estos riesgos?
Para mitigar estos riesgos, las organizaciones deben considerar dar efecto a lo siguiente:
Establecer políticas y estándares corporativos para el uso de OSS , exigibles a través de un proceso documentado y auditado regularmente. Estas políticas y estándares deben incluir evitar el uso de OSS desarrollado por mantenedores 'falsos' o cambiar a otros paquetes de OSS si se identifican tales riesgos. El Open Source Security Scorecard de Google, cuyo objetivo es automatizar los análisis de OSS por referencia a la base de datos de vulnerabilidades de código abierto de los Estados Unidos, es un recurso útil.
Supervisar y mantener de forma centralizada una base de datos de OSS utilizada dentro de la organización (y sus proveedores clave), incluida la coincidencia de OSS con proyectos individuales; documentar el modelo de licenciamiento de cada OSS; documentar las actualizaciones del OSS; y asignar la responsabilidad del monitoreo constante de las actualizaciones a personal específico
Compruebe las actualizaciones antes de la instalación. Evite las actualizaciones automáticas de software; en su lugar, asegúrese de que todas las actualizaciones sean examinadas cuidadosamente (por ejemplo, por la comunidad de OSS y las evaluaciones de la empresa de seguridad) antes de la instalación.
Formalice las relaciones con los mantenedores del OSS crítico para el negocio. Si es factible, considere establecer relaciones comerciales directas con los mantenedores de OSS crítico para el negocio, que brinden soporte continuo e incluyan garantías contra la inclusión de código dañino.
Incorporar disposiciones sólidas relacionadas con el OSS en los contratos con los proveedores clave , que establezcan que la organización debe dar su consentimiento para el uso de cualquier OSS en el software (incluidos los productos de software como servicio) proporcionado a la organización, y posiblemente también imponga obligaciones a los proveedores. que dan efecto a las cuestiones antes planteadas.
Fuente: lexology | somoslibres
