Спор вокруг Go-библиотеки fsnotify напомнил, что доступ мейнтейнеров — тоже поверхность атаки

После того, как Go-разработчик Ясухиро Мацумото, известный как mattn, сообщил в X, что его удалили из GitHub-организации fsnotify, началось обсуждение. Пост позже был удалён, но успел разойтись по сообществу и стал поводом для обсуждения в GitHub issue. Там пользователя @arp242, Мартина Турнойя, попросили объяснить, почему другие участники лишились доступа к организации. Автор issue отметил, что библиотека используется в крупных open source-проектах, поэтому downstream-командам нужен контекст для оценки риска.

fsnotify — не маленькая экспериментальная библиотека. Она даёт Go-приложениям единый интерфейс для уведомлений файловой системы в Windows, Linux, macOS, BSD и illumos. На GitHub у проекта около 10,7 тыс. звёзд и 970 форков, а страница репозитория показывает использование примерно в 321 тыс. проектов. В Go Packages последняя версия v1.10.1 опубликована 4 мая 2026 года, а число известных импортёров указано как 13 659.

Для обычного пользователя это звучит как внутренний конфликт. Для ИБ-команды — как повод открыть граф зависимостей. Библиотеки такого уровня часто живут глубоко внутри стека: в dev-серверах, CLI, сборочных инструментах, контейнерных утилитах, инфраструктурных сервисах и системах горячей перезагрузки, а используют их транзитивно.

Сигналы выглядели неприятно в связке: популярная зависимость, свежие релизы после долгой паузы, удаление участников из GitHub-организации, спорные публичные сообщения, новый форк и неопределённость с тем, кто может мержить и выпускать версии. Такие признаки сами по себе не доказывают компрометацию, но именно так со стороны часто выглядит ранняя стадия проблемы с цепочкой поставки.

Дополнительный фактор — релизная пауза. В апреле в проекте открыли issue о статусе поддержки: автоматические сканеры начали считать библиотеку «неподдерживаемой», потому что больше года не было нового релиза. После этого вышли v1.10.0, а затем v1.10.1 от 4 мая 2026 года. Последний релиз исправлял поведение inotify, где связанные watch-записи с общим префиксом пути могли некорректно удаляться или переименовываться.

Мартин Турной в обсуждении отверг версию о захвате проекта. Его позиция сводится к тому, что удалённые аккаунты имели commit-доступ исторически, но не были активными мейнтейнерами в практическом смысле. Он указал на поспешные изменения, недостаточное обсуждение и проблемы с качеством ревью для библиотеки, которая поддерживает несколько операционных систем и разные backend-механизмы файловых событий.

Отдельным раздражителем стал файл финансирования. В обсуждении утверждалось, что FUNDING.yml был изменён напрямую в main без предварительного согласования. Мацумото позднее признал, что часть удалённого поста была ошибочной, включая утверждение о снятии доступа у оригинальных сопровождающих, и извинился. Он также назвал изменение FUNDING.yml ошибкой задним числом, но объяснил свою активность желанием помочь проекту после долгого отсутствия релизов.

В Kubernetes открыли issue с прямым вопросом: «fsnotify/fsnotify — healthy or not?». Автор предложил внимательно следить за ситуацией, а при необходимости оценить форки или рассмотреть собственный форк. В заметках к issue упоминались обсуждения в Slack, новый репозиторий gofsnotify/fsnotify и риск путаницы из-за похожих названий организаций: старый проект fsnotify/fsnotify, новый — gofsnotify/fsnotify.

fsnotify отслеживает изменения в файловой системе: создание, изменение, переименование и удаление файлов. Внутри используются системные механизмы: inotify на Linux, kqueue на BSD и macOS, ReadDirectoryChangesW на Windows, FEN на illumos. Библиотека не реализует слежение за файловой системой «с нуля», а даёт Go-приложениям единый API поверх разных платформенных интерфейсов.

Быстрая проверка для Go-проекта:

go list -m all | grep github.com/fsnotify/fsnotify

go mod graph | grep github.com/fsnotify/fsnotify

go mod why -m github.com/fsnotify/fsnotify

Для более строгой проверки можно закрепить версию в go.mod, включить ревью dependency update в чувствительных репозиториях, проверить diffs между v1.9.x, v1.10.0 и v1.10.1, а также временно отключить автоматическое принятие обновлений низкоуровневых зависимостей без ревью.