La popular biblioteca de Go llamada fsnotify ha generado una alerta de seguridad en la cadena de suministro debido a un cambio repentino en el acceso de sus mantenedores. Esta herramienta, que ofrece notificaciones del sistema de archivos multiplataforma para diversos sistemas operativos, provocó preocupación en la comunidad de código abierto tras la eliminación de colaboradores de su repositorio de GitHub.

Una biblioteca de Go muy utilizada llamada fsnotify se ha encontrado en el centro de un susto de seguridad en la cadena de suministro después de que un cambio repentino en el acceso de los mantenedores provocara una alarma en toda la comunidad de código abierto.

El proyecto proporciona notificaciones del sistema de archivos multiplataforma para aplicaciones que se ejecutan en Windows, Linux, macOS, BSD e illumos. Los colaboradores fueron eliminados de su organización de GitHub sin una explicación pública, y los usuarios no pudieron determinar inmediatamente si los cambios eran tareas rutinarias de mantenimiento o algo mucho más grave.

La ansiedad era comprensible dado el impacto de la biblioteca. Según los datos de GitHub, fsnotify tiene más de 10.700 estrellas, 969 bifurcaciones (forks) y más de 321.000 proyectos dependientes.

Se encuentra en lo más profundo de la pila de software, debajo de herramientas de desarrollo, interfaces de línea de comandos, servidores de desarrollo y tuberías de infraestructura. Cuando surge incertidumbre sobre quién puede implementar cambios en una biblioteca tan crítica, el efecto se desplaza hacia abajo casi instantáneamente.

Investigadores de Socket.dev siguieron el incidente de cerca y señalaron que la situación presentaba todas las señales superficiales de un posible compromiso de la cadena de suministro. Una dependencia popular, lanzamientos recientes, cambios en el acceso de los mantenedores, una publicación pública eliminada y una autoridad poco clara sobre la canalización de lanzamientos crearon un patrón que parecía preocupante desde el exterior, incluso sin evidencia confirmada de código malicioso.

El incidente salió a la luz cuando el desarrollador de Go Yasuhiro Matsumoto, conocido en línea como mattn, publicó en X diciendo que había sido eliminado de la organización de fsnotify en GitHub. Su publicación, escrita en japonés y posteriormente eliminada, describía que había sido reprendido por contribuir de forma independiente y que descubrió que incluso el autor original había sido eliminado. Una vez traducida y compartida, esa publicación hizo que los usuarios se apresuraran a revisar los historiales de lanzamiento y evaluar las bifurcaciones.

La popular biblioteca de Go fsnotify activa alarmas en la cadena de suministro

Oshi Yamaguchi, Defensor del Desarrollador del Staff de Grafana, abrió un problema (issue) en GitHub señalando los cambios, observando que fsnotify está integrada en importantes proyectos de código abierto y que los usuarios finales necesitaban respuestas más claras. El problema atrajo una atención significativa de la comunidad y presionó al mantenedor Martin Tournoij para que explicara lo sucedido.

Tournoij respondió directamente en el hilo de GitHub, rechazando la idea de que se hubiera producido una toma de control. Afirmó que las cuentas eliminadas tenían derechos de commit por razones históricas, pero que nunca habían funcionado como mantenedores activos en un sentido significativo. Argumentó que los cambios recientes se habían fusionado demasiado rápido, carecían de una revisión suficiente en las plataformas soportadas y corrían el riesgo de deshacer años de cuidadoso trabajo de limpieza.

Un detonante relacionado fue un cambio en el archivo de financiación del proyecto. Tournoij dijo que Matsumoto realizó una actualización de patrocinio directamente en la rama principal, al principio de su participación y sin discusión previa. Describió esto como una de las razones clave para revocar el acceso. Matsumoto reconoció más tarde que el cambio en el archivo de financiación fue un error y se disculpó, aclarando que su publicación eliminada contenía errores, incluida una afirmación falsa de que el autor original también había perdido el acceso.

Temores en la cadena de suministro y la respuesta de Kubernetes

La preocupación llegó rápidamente a los usuarios en los niveles inferiores de la pila. Un problema de GitHub de Kubernetes titulado “fsnotify/fsnotify: ¿Sano o no?” pidió que se vigilara cuidadosamente el proyecto y sugirió evaluar bifurcaciones si la situación no se estabilizaba. Matsumoto también había creado un repositorio separado llamado gofsnotify/fsnotify tras perder el acceso, lo que los contribuyentes de Kubernetes señalaron como algo a monitorear.

Sebastiaan van Stijn, ingeniero principal de software de Docker, señaló que las bibliotecas como fsnotify se encuentran lo suficientemente bajas en la pila como para ser olvidadas, y que herramientas como Dependabot facilitan que los proyectos actualicen las dependencias sin mucho escrutinio. Su comentario capturó exactamente cómo un ataque a la cadena de suministro podría moverse silenciosamente a través de una biblioteca ampliamente confiada.

Los analistas de Socket.dev señalaron que las primeras etapas de un compromiso de la cadena de suministro y una disputa entre mantenedores se ven casi idénticas desde el exterior. Ambas pueden implicar lanzamientos inesperados, cambios de acceso y declaraciones públicas contradictorias.

La puerta trasera de xz-utils es un recordatorio reciente de que la amenaza es real, lo que hace que los desarrolladores sean mucho más cautelosos con la actividad inusual en las bibliotecas fundamentales. Se recomienda a los equipos de seguridad monitorear la actividad de los mantenedores en las dependencias críticas, verificar los historiales de lanzamiento durante las disputas y evaluar las bifurcaciones cuando la gobernanza del proyecto se vuelva incierta.