Las 10 principales amenazas de seguridad en el software de código abierto en 2023

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

Realizado por el equipo de Station 9 de Endor Labs, el informe contó con la contribución de más de 20 directores de seguridad de la información de destacadas empresas como Adobe, HashiCorp, Discord y Palo Alto Networks.

Según Endor Labs, la dependencia excesiva del software de código abierto ha registrado algunas vulnerabilidades conocidas, capturadas como Vulnerabilidades y Exposiciones Comunes. Estas vulnerabilidades a menudo se pasan por alto y podrían ser aprovechadas por atacantes si no se solucionan.

"El software de código abierto representa una mina de oro para los desarrolladores de aplicaciones, pero necesita capacidades de seguridad igualmente efectivas", dijo Henrik Plate, investigador principal de seguridad de Endor Labs. "En un entorno donde más del 80% del código en nuevas aplicaciones puede provenir de repositorios existentes, está claro que existen riesgos graves".

Principales riesgos de código abierto en 2023

A continuación, se presentan los principales puntos destacados del informe de Endor Labs sobre los 10 principales riesgos de código abierto en 2023.

Protección antivirus en línea: McAfee Clinic lleva la seguridad de tu PC al siguiente nivel

1. Vulnerabilidades conocidas

El informe reveló que una versión de componente de código abierto puede contener código vulnerable introducido accidentalmente por sus desarrolladores. La vulnerabilidad puede ser explotada en el software descendente, comprometiendo potencialmente la confidencialidad, integridad o disponibilidad del sistema y sus datos.

2. Compromiso de paquetes legítimos

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

3. Ataques de confusión de nombres

Los atacantes pueden crear componentes con nombres que se asemejen a los de componentes legítimos de código abierto o del sistema. El informe de Endor Labs reveló que esto se puede hacer mediante:

• Errónea: El atacante crea un nombre que es un error ortográfico del nombre del componente original.
• Secuestro de marca: El atacante sugiere un autor confiable.
• Secuestro combinado: El atacante juega con patrones de nombres comunes en diferentes idiomas o ecosistemas.

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

4. Software no mantenido

El software no mantenido es un problema operativo, según el informe de Endor Labs. Un componente o versión de un componente puede dejar de desarrollarse activamente, lo que significa que es posible que los parches para errores funcionales y no funcionales no se proporcionen de manera oportuna o no se proporcionen en absoluto por el proyecto de código abierto original. Esto puede dejar el software vulnerable a la explotación por parte de atacantes que apuntan a vulnerabilidades conocidas.

5. Software desactualizado

Por comodidad, algunos desarrolladores utilizan una versión desactualizada de una base de código cuando hay versiones actualizadas disponibles. Esto puede resultar en que el proyecto se pierda importantes correcciones de errores y parches de seguridad, dejándolo vulnerable a la explotación.

Cómo proteger tu computadora de los virus: métodos y consejos

6. Dependencias no rastreadas

Los desarrolladores de proyectos pueden no ser conscientes de una dependencia en un componente por varias razones:

• No forma parte de los materiales de software de un componente aguas arriba.
• Las herramientas de análisis de composición de software no se ejecutan o no lo detectan.
• La dependencia no se establece utilizando un gestor de paquetes, lo que puede generar problemas de seguridad, ya que las vulnerabilidades en la dependencia no rastreada pueden pasar desapercibidas.

7. Riesgo de licencia y regulación

Un componente o proyecto puede no tener una licencia o puede tener una que sea incompatible con el uso previsto o cuyos requisitos no se cumplan o no se puedan cumplir.

Utilizar componentes de acuerdo con los términos de su licencia es crucial. No hacerlo, como utilizar un componente sin licencia o no cumplir con sus términos, puede dar lugar a infracciones de copyright o licencia. En estos casos, el titular de los derechos de autor tiene derecho a emprender acciones legales.

Además, violar los requisitos legales y regulatorios puede limitar o dificultar la capacidad de abordar ciertas industrias o mercados.

8. Software inmaduro

Un proyecto de código abierto puede no seguir las mejores prácticas de desarrollo, como utilizar un esquema de versionado estándar, tener un conjunto de pruebas de regresión o tener pautas de revisión o documentación. Esto puede resultar en un componente de código abierto que no funciona de manera confiable o segura, lo que lo hace vulnerable a la explotación.

Depender de un componente o proyecto inmaduro puede plantear importantes riesgos operativos. Por ejemplo, el software que depende de él puede no funcionar como se esperaba, lo que puede provocar problemas de fiabilidad en tiempo de ejecución.

¡Defiéndete! Protege tu seguridad en línea contra amenazas críticas

9. Cambios no aprobados (mutables)

Cuando se utilizan componentes que no se garantiza que sean idénticos al descargarlos en momentos diferentes, existe un riesgo de seguridad significativo. Esto se demuestra en ataques como el Cargador de Bash de Codecov, donde los scripts descargados se envían directamente a bash sin verificar su integridad de antemano. El uso de componentes mutables también representa una amenaza para la estabilidad y la reproducibilidad de las compilaciones de software.

10. Dependencia de tamaño insuficiente/excesiva

El informe de Endor señaló que la sobredependencia/sobredimensionamiento de componentes puede ser un riesgo operativo. Por ejemplo, los componentes pequeños, como aquellos que contienen solo unas pocas líneas de código, son vulnerables a los mismos riesgos que los componentes más grandes. Estos riesgos incluyen apoderarse de cuentas, solicitudes de extracción maliciosas y vulnerabilidades en canalizaciones de integración continua y desarrollo continuo.

Por otro lado, los componentes enormes pueden haber acumulado muchas características que no son necesarias para casos de uso estándar. Estas características aumentan la superficie de ataque del componente y pueden introducir dependencias no utilizadas, lo que da como resultado componentes inflados.

Medidas para mitigar estos riesgos de código abierto

Aquí hay algunos consejos de Endor Labs sobre cómo los desarrolladores de software y los gerentes de TI pueden mitigar estos riesgos de código abierto.

Escanear regularmente el código para detectar paquetes comprometidos

Prevenir paquetes comprometidos es un problema complejo porque no existe una solución que sirva para todos. Para abordar esto, las organizaciones pueden consultar estándares emergentes y marcos como el Marco de Consumo de Cadena de Suministro Seguro de OpenSSF (S2C2F).

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

Protege tus contraseñas con PAM: Tu aliado para la seguridad

Verificar si un proyecto sigue las mejores prácticas de desarrollo

Para evaluar la calidad y actualidad de un proyecto, verifique su documentación y notas de lanzamiento en cuanto a completitud y puntualidad. Busque insignias que indiquen la cobertura de pruebas o la presencia de canalizaciones de CI/CD que puedan detectar regresiones.

Además, puede evaluar un proyecto verificando el número de mantenedores y colaboradores activos, con qué frecuencia se realizan nuevos lanzamientos y la cantidad de problemas y solicitudes de extracción que se abren y cierran. También es crucial buscar información sobre la estrategia de mantenimiento o soporte de un proyecto, por ejemplo, la presencia y fechas de versiones de soporte a largo plazo.

Mantener las dependencias actualizadas y verificar las características del código antes de usarlas

Para garantizar la seguridad del código, es importante verificar tanto las características del código como las del proyecto. Ejemplos de características del código para verificar incluyen ganchos de pre y post-instalación y cargas útiles codificadas. Para características del proyecto, considere el repositorio de código fuente, las cuentas de los mantenedores, la frecuencia de lanzamiento y el número de usuarios descendentes.

Una forma de mantener actualizadas las dependencias es utilizar herramientas que generen solicitudes de fusión o extracción con sugerencias de actualización. También es importante priorizar las actualizaciones de dependencias y los elementos recurrentes de la lista de tareas pendientes.

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

Los equipos de seguridad deben asegurarse de que las herramientas de análisis de composición de software sean capaces de generar listas de materiales precisas, tanto a nivel grueso como a nivel fino. Por ejemplo, para dependencias declaradas con la ayuda de herramientas de administración de paquetes como Maven o npm, y a nivel fino, como para artefactos como archivos individuales incluidos "fuera de banda" sin usar administradores de paquetes.

Usar componentes cumpliendo los términos de licencia de código abierto

Los líderes de TI deben asegurarse de que sus desarrolladores de software eviten utilizar componentes de código abierto sin licencia, ya que esto podría crear riesgos legales. Para garantizar el cumplimiento y evitar posibles problemas legales, es importante identificar licencias aceptables para los componentes utilizados en el desarrollo de software.

Cómo configurar un servidor VPN para hacer conexiones a través de firewalls

Factores a tener en cuenta incluyen cómo se vincula el componente, el modelo de implementación y el esquema de distribución previsto. Una vez que haya identificado las licencias aceptables, cumpla con los requisitos establecidos en esas licencias de código abierto.

En Newsmatic nos especializamos en tecnología de vanguardia, contamos con los artículos mas novedosos sobre Seguridad, allí encontraras muchos artículos similares a Las 10 principales amenazas de seguridad en el software de código abierto en 2023 , tenemos lo ultimo en tecnología 2023.