Давление сканеров заброшенного кода

Большинство автоматических сканеров цепочки поставок (Snyk, сигналы свежести Dependabot'а, утилиты в стиле npm-audit, их внутренние корпоративные аналоги) помечают как unmaintained зависимости, у которых не было релизов в течение заданного порога - обычно 12 месяцев. Замысел понятен: если проект никто не обновляет, значит, никто не выпускает для него патчи, и зависящим от него проектам стоит об этом знать.

Проблема в том, что зрелые, поддерживаемые как положено инфраструктурные библиотеки часто выпускают релизы всплесками. Канонический пример - fsnotify: кроссплатформенные уведомления файловой системы - задача конечная и хорошо изученная; библиотека находится в корректном, стабильном, рабочем состоянии; долгое время там попросту нечего релизить. Однако бинарная эвристика сканеров "устарело = плохо" создаёт давление независимо от этого.

Каскад давления

Библиотеке 12 месяцев нечего релизить, потому что она работает правильно.
Сканер помечает её как unmaintained.
Пользователи из зависимых проектов создают issue с просьбой сделать релиз.
Появляется новый контрибьютор, готовый выпустить релиз.
Происходят изменения в правах доступа. Со стороны это выглядит как начальная стадия захвата проекта.
Зависимые проекты переходят в режим проверки.

Issue #735 в репозитории fsnotify за апрель 2026 года наглядно показывает шаги 2-3 этого каскада: "Автоматические сканеры кода считают этот проект заброшенным, если за последние 12 месяцев не выходило новых релизов. Этот проект перешагнул данный порог 4 апреля 2026 года." Это issue отчасти и подтолкнуло mattn подключиться и возобновить поддержку, что в итоге привело к спору, описанному в fsnotify-maintainer-dispute.

По собственным метрикам сканер сработал правильно. В результате стабильный проект подтолкнули к бессмысленной суете, которая через несколько шагов едва не привела к инциденту безопасности цепочки поставок.

Более надёжные сигналы

Системное решение - заменить эвристику с единственным порогом сигналами, которые отличают "заброшен" от "стабилен":

Реакция на открытые issue и PR - отвечает ли проект на отчёты о безопасности в разумные сроки, даже без выпуска релизов? Для оценки рисков важен именно этот вопрос, а не частота релизов.
Регулярность мёрджа исправлений - даже если новая версия не выпускается, мёрджи в main показывают, следит ли кто-то за проектом на самом деле.
Зелёный CI на последнем коммите - собирается ли проект и проходят ли тесты на актуальных версиях языка?
Активность мейнтейнера в смежных частях экосистемы - публичные коммиты в других местах, доклады на конференциях, активность в списках рассылки. Для этого не нужны никакие внутренние данные самого проекта.

Ни один из них не идеален. Но сочетание двух или трёх гораздо лучше вопроса "выпустили ли они релиз в этом году".

Что разработчики и пользователи инструментов могут сделать уже сегодня

Если вы управляете конфигурацией сканера:

Увеличьте порог до 24 месяцев для низкоактивных инфраструктурных библиотек (отслеживание файлов, парсинг времени, определение возможностей терминала - стабильный базовый слой).
Объединяйте флаг устаревания с одним из более точных сигналов выше, чтобы оповещение сообщало о проекте "устаревший и неотзывчивый", а не просто "устаревший".
Подавляйте оповещение, если известно, что мейнтейнер - давний активный OSS-контрибьютор с деятельностью в других проектах (простая эвристика: лента публичных событий на GitHub не пуста за последние 6 месяцев).

Если вы разрабатываете сам сканер:

Зафиксируйте в описаниях продукта, что неактивность сама по себе не является уязвимостью, а принуждение проектов к релизам ради релизов не повышает, а ухудшает безопасность зависящих систем.

Ссылки

supply-chain-security
maintainer-governance-ambiguity - последствия для зависимых систем при развитии такого каскада
fsnotify-maintainer-dispute - разобранный пример