La superficie de ataque de las contribuciones de código abierto surge del modelo de confianza específico del desarrollo de código abierto: las contribuciones de colaboradores consolidados reciben menos escrutinio que las de colaboradores nuevos porque la reputación funciona como indicador de confiabilidad. Este modelo de confianza basado en la reputación crea una vulnerabilidad en la cadena de suministro cuando cambian las motivaciones o circunstancias de un colaborador consolidado: cuando un empleado se va en circunstancias conflictivas, cuando una cuenta se ve comprometida o cuando se coacciona a un colaborador legítimo. La confianza que construyeron tres años de contribuciones de calidad se extiende a la contribución que contiene la puerta trasera, precisamente porque esa confianza hace menos probable una revisión a fondo.
La transición de amenaza interna a amenaza externa es el escenario de riesgo específico. Un empleado que contribuye a proyectos de código abierto como parte de su función tiene una doble identidad: es un empleado de confianza sujeto a los acuerdos laborales, los procesos de revisión de código y el monitoreo de seguridad de la empresa, y es un colaborador de código abierto de confianza cuyas contribuciones están sujetas a los estándares de revisión de la comunidad de código abierto. Cuando la relación laboral termina, en particular en circunstancias conflictivas como un despido con causa, terminan los controles de la empresa sobre la conducta del antiguo empleado. La reputación acumulada del antiguo empleado en el código abierto no termina.
El ataque a XZ Utils de marzo de 2024 es el ejemplo real de referencia. Un atacante dedicó aproximadamente dos años a generar confianza como colaborador de la biblioteca de compresión xz-utils con un seudónimo: presentó contribuciones de calidad, estableció relaciones con el mantenedor existente y, finalmente, obtuvo permisos de commit. Cuando se insertó la carga útil del ataque, la fusionó un mantenedor que confiaba en el colaborador por dos años de trabajo de calidad. La ingeniería social fue paciente, sistemática y diseñada específicamente para explotar el modelo de confianza basado en la reputación que hace posible la colaboración en el código abierto.
Por qué es importante
El riesgo de las contribuciones de código abierto es importante para la TPRM porque las bibliotecas de código abierto sobre las que se construye el software de los proveedores son mantenidas por colaboradores humanos cuyas motivaciones pueden cambiar, y porque el modelo de confianza que hace eficiente el desarrollo de código abierto es también el modelo de confianza al que apuntan específicamente los atacantes de la cadena de suministro. El proveedor cuyo software se basa en paquetes de código abierto mantenidos por colaboradores de confianza depende de que sigan siendo confiables colaboradores cuyas circunstancias el proveedor no puede monitorear.
- Riesgo de las contribuciones de código abierto no incluido en el modelo de seguridad de la cadena de suministro
- Contribuciones de código abierto de empleados que se fueron sin monitorear
- Revisión de PR basada en la confianza que crea vulnerabilidad ante cuentas de colaboradores comprometidas
- Dependencias de paquetes con equipos de colaboradores reducidos que aumentan la exposición al riesgo interno
- Ingeniería social dirigida a mantenedores de código abierto como vector de ataque a la cadena de suministro
Cómo se ve una buena práctica
Los programas maduros de gestión del riesgo de las contribuciones de código abierto implementan políticas para las contribuciones de los empleados al código abierto, monitorean los cambios en las dependencias de código abierto críticas, incluidos los cambios de colaboradores, y aplican un escrutinio adicional a los PR de colaboradores con cambios recientes de cuenta, transferencias de reputación o patrones de contribución inusuales.
- Política de contribuciones de los empleados al código abierto: alcance y requisitos de revisión
- Monitoreo de colaboradores de las dependencias: cambios en el equipo de mantenedores de los paquetes críticos
- Escrutinio adicional para colaboradores con cambios de credenciales: cuentas transferidas recientemente
- Detección de patrones de contribución anómalos: actividad inusual después de un período de inactividad
- Conciencia de ataques al estilo de XZ Utils: ataques pacientes de ingeniería social a la cadena de suministro
Herramientas
Monitoreo de contribuciones: Socket.dev para detectar cambios en mantenedores y colaboradores; OpenSSF Scorecard para el estado de los mantenedores
El monitoreo de paquetes en tiempo real de Socket.dev detecta cambios en las cuentas de colaboradores y mantenedores, en concreto el tipo de transferencias de cuentas e incorporaciones de nuevos mantenedores que preceden a los ataques a la cadena de suministro a través del vector de contribuciones de código abierto. OpenSSF Scorecard ofrece una puntuación del estado de seguridad de los proyectos de código abierto que incluye señales de la actividad de los colaboradores y de la calidad del proceso de revisión.
Desafíos de gobernanza
El desafío de gobierno del riesgo de las contribuciones de código abierto es la escala del monitoreo. Una cadena de suministro de software que incluye miles de dependencias transitivas no puede monitorear manualmente a todos los colaboradores de todos los paquetes. La solución de gobierno es un monitoreo por niveles: monitoreo integral de los colaboradores para las dependencias directas y las dependencias transitivas críticas, y detección automatizada de anomalías para el resto del árbol de dependencias.
- Monitoree los cambios de colaboradores en las dependencias directas críticas
- Aplique el modelo del ataque a XZ Utils al análisis de patrones de contribución
- Implemente una política de contribuciones de los empleados al código abierto
- Incluya el riesgo de las contribuciones en la evaluación del estado de las dependencias de código abierto
- Utilice Socket.dev para la detección automatizada de cambios en los colaboradores
Si usted forma parte de un equipo pequeño
Configure el monitoreo de Socket.dev para sus diez dependencias directas de código abierto más críticas. Socket.dev le alertará sobre cambios en las cuentas de colaboradores, incorporaciones de nuevos mantenedores y patrones de contribución inusuales, que son las señales específicas que preceden a los ataques a la cadena de suministro a través del vector de contribuciones de código abierto. Configurar ese monitoreo automatizado para diez paquetes lleva minutos y proporciona la capacidad de alerta temprana cuya ausencia demostró el ataque a XZ Utils.
- Configure Socket.dev para las diez dependencias directas más críticas
- Genere alertas ante cambios en las cuentas de colaboradores e incorporaciones de nuevos mantenedores
- Implemente una política de contribuciones de los empleados al código abierto
- Incluya el riesgo de los colaboradores en la evaluación del estado de las dependencias
Qué exigir
Pregunte directamente:
“¿Cómo monitorean los ataques a la cadena de suministro a través de los canales de colaboradores de sus dependencias de código abierto, en particular el patrón de ingeniería social demostrado por el ataque a XZ Utils, en el que un colaborador paciente genera confianza durante años antes de insertar código malicioso?”
Evidencia que debe esperar
- Programa de monitoreo de colaboradores de las dependencias
- Detección de patrones de contribución anómalos
- Política de contribuciones de los empleados al código abierto
- Conciencia de ataques al estilo de XZ Utils en el modelo de seguridad de la cadena de suministro
A un proveedor que confirma que gestiona sus dependencias de código abierto se le debe preguntar por el monitoreo del riesgo de los colaboradores. La gestión de versiones de las dependencias abarca qué paquete se utiliza. El monitoreo de colaboradores abarca a quién se le confía la modificación de ese paquete.
Cómo demostrarlo
- Implementación del monitoreo de colaboradores
- Detección de contribuciones anómalas
- Política de contribuciones de los empleados al código abierto
- Riesgo de los colaboradores en la evaluación del estado de las dependencias
Conclusión clave
Tres años de contribuciones de confianza. Un empleado que se fue. Su reputación en el código abierto, intacta. Un PR con una puerta trasera. Fusionado por confianza. Catorce proveedores aguas abajo. La relación laboral terminó con la revocación del acceso. La reputación en el código abierto, no. XZ Utils demostró el mismo patrón de ataque: ingeniería social paciente, orientada a generar confianza y sistemática contra el modelo de reputación que hace posible la colaboración en el código abierto. El monitoreo de cambios en los colaboradores detecta las transferencias de cuentas y las incorporaciones de nuevos mantenedores antes de la puerta trasera. Socket.dev ofrece detección automatizada. La reputación que logra que se fusionen los PR es la misma reputación que el atacante de la cadena de suministro construye a lo largo de años de contribuciones legítimas.