GitHub расширил систему оповещений о вредоносных пакетах: теперь Dependabot и база советов по безопасности GitHub Advisory Database покрывают восемь основных экосистем — npm, PyPI, Maven, RubyGems, NuGet, Go, crates.io и PHP Composer. Это позволит разработчикам быстрее выявлять вредоносные зависимости в своих проектах.
Ранее GitHub мог автоматически помечать вредоносные пакеты только в npm. В начале года Dependabot начал выдавать такие предупреждения по npm-зависимостям, а сейчас та же возможность стала доступна для PyPI и других экосистем за счёт интеграции с репозиторием malicious-packages организации OpenSSF.
GitHub Advisory Database уже несколько лет импортирует данные о уязвимостях из внешних публичных репозиториев: RubySec для RubyGems, RustSec для crates.io, PyPA для Python. Каждый такой источник обрабатывается отдельным импортером, который считывает записи и приводит их к единому формату. Вредоносные пакеты до сих пор обрабатывались отдельно и только для npm, на основе собственных механизмов выявления внутри GitHub.
Расширение этой внутренней системы с одной до восьми экосистем заняло бы годы. Вместо этого команда Dependabot использовала уже существующий источник: репозиторий OpenSSF malicious-packages, запущенный в 2023 году и содержащий более 15 000 отчётов в формате OSV. Репозиторий постоянно пополняется за счёт заявок от сообщества и автоматических систем обнаружения (typosquatting, dependency confusion, захваты аккаунтов, вредоносные бинарные сборки) и поддерживает разные экосистемы через схему OSV.
Вместо того чтобы строить отдельные системы детектирования для каждой экосистемы, GitHub реализовал единый импортер для OpenSSF. Он использует тот же паттерн, что и существующие импортеры: обходит дерево файлов репозитория, находит изменённые файлы с момента последнего запуска и обрабатывает каждый из них. Новый импортер считывает каждую запись OSV и проверяет обязательные поля, типы и формат на соответствие схеме до загрузки в базу. Записи, которые не проходят валидацию, отклоняются и логируются — их данные не исправляются автоматически и не попадают в систему.
Прошедшие проверку записи нормализуются в единый формат: источник, идентификатор, CVE (если есть), полный исходный отчёт как снимок и подмножество полей, которое затем использует внутренняя цепочка публикации советов по безопасности. Нормализация решает ряд практических задач: строки экосистем из исходных данных не всегда совпадают с тем, как они обозначены в базе GitHub (например, upstream указывает PyPI, а база — pip); версии часто перечисляются поштучно, а в GitHub используют диапазоны; бывают отчёты без полезной информации по версиям.
Отдельная проблема — текст описания. Поле details нередко пустое, а когда несколько источников сообщают о том же пакете, их описания объединяются в один большой блок. Кроме того, в репозитории есть механизм отзыва отчётов: для ошибочных советов используется каталог osv/withdrawn, поэтому импортер должен корректно обрабатывать ситуацию, когда пакет помечен как вредоносный в один день и разметка отзывается через пару дней.
Ещё одна важная задача — устранение дубликатов. GitHub сам отправляет данные по npm-малваре в репозиторий OpenSSF, поэтому при прямом импорте возник бы замкнутый круг: ранее импортированные советы возвращались бы обратно как новые. Для решения используется поле origin в формате OSV: каждая запись в malicious-packages содержит источник отчёта, и все записи с меткой ghsa-malware, которые изначально сформированы GitHub, отбрасываются до создания записей в ленте. Валидация на реальных данных показала, что более половины новых npm-отчётов в месяц приходились на собственные советы GitHub и были корректно пропущены как «обратные».
Ключевой вопрос на этапе анализа безопасности — что произойдёт, если в исходный поток попадут некорректные данные. Советы по вредоносным пакетам публикуются автоматически, без ручной проверки каждого отчёта, и это сделано намеренно: если пакет крадёт данные прямо сейчас, задержка публикации на несколько дней играет на руку атакующим.
Ранее автоматически публикуемые советы не генерировали оповещения, однако теперь такие авто-публикации могут вызывать предупреждения Dependabot. Для классических уязвимостей в библиотеках действует отдельный подход: как описывала коллега Madison Ficorilli, «проверенный» совет означает, что специалисты вручную подтвердили соответствие пакета, диапазоны версий и уровень серьёзности. Такая задержка оправдана, когда важно точно указать, какие версии уязвимы.
С вредоносными пакетами ситуация иная: отчёт зачастую сводится к бинарному решению — пакет признан враждебным или нет, а время реакции важнее нюансов. Поэтому архитектура изначально исходит из того, что в какой‑то момент во входящие данные могут попасть ошибки: ложное обвинение популярного пакета, запись с неправильным именем или серия отчётов от скомпрометированного источника.
В ответ на это в GitHub построили устойчивый конвейер обработки с несколькими уровнями защиты именно на такой случай. Подробности реализации в тексте описаны как трёхуровневая модель, которая должна удержать некорректные записи до того, как они повлияют на пользователей.
Теперь Dependabot и GitHub могут оповещать о вредоносных зависимостях в большинстве используемых экосистем. Оповещения о малваре включаются по желанию — их можно активировать в настройках безопасности на уровне репозитория, организации или предприятия. После этого Dependabot начнёт сопоставлять зависимости с советами по вредоносным пакетам в Advisory Database, включая обратную проверку уже существующих зависимостей.
Dependabot сегодня наблюдает более чем за 30 млн репозиториев и 34+ экосистемами пакетов. Это описывает в заключении Ankit, старший руководитель инженерной команды GitHub, который возглавляет команду Dependabot в блоке Supply Chain Security и отмечает, что масштаб задач требует повышенного внимания к атакам на цепочку поставок.
Материал подготовлен по данным инженерного блога GitHub.
