Los 10 principales riesgos de seguridad y operaciones de código abierto para 2023

Imagen: klss777/Adobe Stock

Endor Labs, una empresa de software que promueve la seguridad y el mantenimiento del software de código abierto, publicó un informe que identifica los diez principales riesgos operativos y de seguridad del software de código abierto en 2023.

El informe fue realizado por el equipo de Station 9 de Endor Labs e incluyó contribuciones de más de 20 CISO de la industria de compañías destacadas como Adobe, HashiCorp, Discord y Palo Alto Networks.

Según Endor Labs, la dependencia excesiva del software de código abierto ha documentado vulnerabilidades conocidas que se detectan como vulnerabilidades y exposiciones comunes; estas vulnerabilidades a menudo se pasan por alto y los atacantes podrían explotarlas si no se solucionan.

«El software de fuente abierta es una mina de oro para los desarrolladores de aplicaciones, pero necesita características de seguridad igualmente efectivas», dijo Henrik Plate, investigador principal de seguridad de Endor Labs. «En un entorno en el que más del 80 por ciento del código de una nueva aplicación puede provenir de un repositorio existente, claramente existen riesgos graves».

Los mayores riesgos de código abierto de 2023

A continuación, se destacan los puntos clave del informe de Endor Labs sobre los 10 principales riesgos de código abierto para 2023.

1. Vulnerabilidades conocidas

El informe reveló que una versión de un componente de código abierto puede contener código vulnerable introducido accidentalmente por su desarrollador. La vulnerabilidad podría explotarse en el software posterior, lo que podría comprometer la confidencialidad, la integridad o la disponibilidad del sistema y sus datos.

2. Compromiso de paquetes legales

Según el informe de Endor, los atacantes pueden apuntar a recursos legítimos en proyectos existentes o infraestructura de distribución para inyectar código malicioso en los componentes. Por ejemplo, podrían secuestrar las cuentas de mantenedores de proyectos legítimos o explotar vulnerabilidades en repositorios de paquetes. Este tipo de ataque puede ser peligroso porque el código malicioso puede distribuirse como parte de un paquete legítimo y ser difícil de detectar.

3. Ataque de confusión de nombres

Un atacante podría crear componentes con nombres similares a componentes legítimos de código abierto o del sistema. Endor Labs informa que esto se puede hacer mediante:

• Error de tipografía: El nombre creado por el atacante es un error ortográfico del nombre del componente original.
• Secuestro de marca: El atacante sugiere un autor de confianza.
• Sentadilla combinada: Los atacantes usan patrones de nombres comunes en diferentes idiomas o ecosistemas.

Estos ataques se pueden usar para engañar a los usuarios para que descarguen y usen componentes maliciosos que creen que son legítimos.

4. Software sin mantenimiento

Informes de seguridad de lectura obligada

El software sin mantenimiento es un problema operativo, según Endor Labs. Es posible que un componente o una versión de un componente ya no se desarrolle activamente, lo que significa que el proyecto de código abierto original puede no proporcionar parches para errores funcionales y no funcionales de manera oportuna o en absoluto. Esto puede dejar el software vulnerable a la explotación por parte de atacantes que se dirigen a vulnerabilidades conocidas.

5. Software obsoleto

Por conveniencia, algunos desarrolladores usan versiones obsoletas del código base cuando hay versiones más nuevas disponibles. Esto puede hacer que el proyecto pierda correcciones de errores importantes y parches de seguridad, dejándolo vulnerable a la explotación.

6. Dependencias no rastreadas

Los desarrolladores de proyectos pueden no ser conscientes de las dependencias de los componentes por varios motivos:

• No forma parte de la lista de materiales del software para componentes upstream.
• La herramienta de análisis de composición de software no se está ejecutando o no se detecta.
• Las dependencias no se crean con un administrador de paquetes, lo que puede generar problemas de seguridad, ya que las vulnerabilidades en las dependencias no rastreadas pueden pasar desapercibidas.

7. Licencias y riesgos regulatorios

Un componente o elemento puede no tener una licencia, o puede tener una licencia que sea incompatible con el uso previsto o que no cumpla o no cumpla con sus requisitos.

Es esencial que los componentes se utilicen de acuerdo con los términos de la licencia. El no hacerlo, como el uso de componentes sin licencia o el incumplimiento de sus términos, puede resultar en una infracción de derechos de autor o licencia. En tales casos, el propietario de los derechos de autor tiene derecho a emprender acciones legales.

Además, las violaciones de los requisitos legales y reglamentarios pueden limitar o impedir la capacidad de abordar ciertos problemas de la industria o el mercado.

8. Software inmaduro

Es posible que los proyectos de código abierto no sigan las mejores prácticas de desarrollo, como usar esquemas de control de versiones estándar, tener conjuntos de pruebas de regresión o tener guías de revisión o documentación. Esto puede impedir que los componentes de código abierto funcionen de forma fiable o segura, haciéndolos vulnerables a la explotación.

La dependencia de componentes o proyectos inmaduros puede introducir un riesgo operativo significativo. Por ejemplo, es posible que el software que depende de él no se comporte como se esperaba, lo que provoca problemas de confiabilidad en el tiempo de ejecución.

9. Cambios no aprobados (Variable)

Existen importantes riesgos de seguridad cuando se utilizan componentes que no garantizan que sean iguales cuando se descargan en diferentes momentos. Los ataques como Codecov Bash Uploader demuestran esto, donde los scripts descargados se canalizan directamente a bash sin verificación previa de su integridad. El uso de componentes variables también representa una amenaza para la estabilidad y repetibilidad de las compilaciones de software.

10. Muy pocas/demasiadas dependencias

El informe de Endor establece que la dependencia excesiva o insuficiente de los componentes puede crear riesgos operativos. Por ejemplo, los componentes pequeños, como los que contienen solo unas pocas líneas de código, son susceptibles a los mismos riesgos que los componentes grandes. Estos riesgos incluyen tomas de control de cuentas, solicitudes de extracción maliciosas y vulnerabilidades de canalización de integración continua y desarrollo continuo.

Por otro lado, los componentes voluminosos pueden acumular mucha funcionalidad que no es necesaria para los casos de uso estándar. Estas funciones aumentan la superficie de ataque del componente y pueden introducir dependencias no utilizadas, lo que da como resultado dependencias infladas.

Pasos para mitigar estos riesgos de código abierto

Estos son algunos consejos de Endor Labs sobre cómo los desarrolladores de software y los administradores de TI pueden mitigar estos riesgos de código abierto.

Escanea regularmente el código en busca de paquetes rotos

La prevención de paquetes rotos es un problema complejo porque no existe una solución única para todos. Para abordar esto, las organizaciones pueden consultar estándares y marcos emergentes, como el marco de consumo de la cadena de suministro segura de OpenSSF (S2C2F).

Pueden seleccionar y priorizar las medidas de seguridad que mejor se adapten a sus requisitos en función de sus necesidades específicas de seguridad y tolerancia al riesgo.

Comprobar que el proyecto sigue las mejores prácticas de desarrollo

Para evaluar la calidad y la puntualidad de un proyecto, verifique la integridad y la puntualidad de su documentación y notas de publicación. Busque insignias que indiquen cobertura de prueba o canalizaciones de CI/CD con regresiones detectables.

Además, puede evaluar proyectos examinando la cantidad de mantenedores y colaboradores activos, la frecuencia con la que se lanzan nuevas versiones y la cantidad de problemas abiertos y cerrados y solicitudes de incorporación de cambios. También es importante encontrar información sobre las políticas de soporte o mantenimiento de un proyecto, por ejemplo, la existencia y las fechas de las versiones de soporte a largo plazo.

Mantenga las dependencias actualizadas y verifique las funciones del código antes de usar

Para garantizar la seguridad del código, es importante examinar las características del código y del proyecto. Los ejemplos de características de código para verificar incluyen ganchos previos y posteriores a la instalación y cargas útiles codificadas. Para las características del proyecto, considere los repositorios de código fuente, las cuentas de mantenedor, la frecuencia de publicación y la cantidad de usuarios intermedios.

Una forma de mantener sus dependencias actualizadas es usar una herramienta que genere solicitudes de combinación o extracción con propuestas actualizadas. También es importante priorizar las actualizaciones de dependencia y los trabajos pendientes recurrentes.

Evaluar y comparar herramientas de análisis de composición de software

Los equipos de seguridad deben asegurarse de que las herramientas SCA puedan generar listas de materiales precisas, tanto en un nivel de grano grueso (por ejemplo, dependencias declaradas a través de herramientas de administración de paquetes como Maven o npm) como en un nivel de grano fino (por ejemplo, artefactos) como sería el caso. sin un administrador de paquetes En «Fuera de banda» contiene el mismo archivo único.

Usar componentes que cumplan con los términos de las licencias de código abierto

Los líderes de TI deben asegurarse de que sus desarrolladores de software eviten el uso de componentes de código abierto sin licencia, lo que puede crear riesgos legales. Para garantizar el cumplimiento y evitar posibles problemas legales, es importante determinar las licencias aceptables para los componentes utilizados en el desarrollo de software.

Los factores a considerar incluyen cómo se vinculan los componentes, el modelo de implementación y el escenario de distribución previsto. Una vez que haya determinado las licencias aceptables, siga los requisitos establecidos en esas licencias de código abierto.

Lea a continuación: Principales amenazas de ciberseguridad en 2023 (República tecnológica)