GitHub запустил npm-файрвол, блокирующий вредоносные пакеты до установки

GitHub объявил о запуске пакетного файрвола, который должен останавливать подозрительные npm-пакеты ещё на этапе установки. По словам компании, файрвол «проверяет как запросы метаданных, так и загрузку пакетов на признаки вредоносной активности, выступая политическим шлюзом в момент установки».

Пока поддерживается только npm. Функция доступна в публичной предварительной версии всем клиентам GitHub Enterprise Cloud, включая вариант с размещением данных в выбранном регионе.

Как это работает

Файрвол располагается между конечными точками или внутренними реестрами и вышестоящими репозиториями пакетов. Задача — защититься от атак, при которых система заражается в момент установки пакета. Риск особенно высок, когда ИИ-агенты и CI-раннеры устанавливают зависимости автоматически, без явного разрешения пользователя, чтобы выполнить задачу или собрать проект.

Предполагается, что агенты для написания кода и CI/CD-хосты будут отправлять запросы через файрвол, а не напрямую в публичные реестры. Файрвол сверяет загрузки с заданными политиками и блокирует те, что им не соответствуют.

Администраторы могут настроить следующие правила:

• блокировка известного вредоносного ПО — по активным предупреждениям в GitHub Advisory Database;
• блокировка по серьёзности уязвимостей в запрошенной версии пакета; по умолчанию установка запрещается только при критических уязвимостях, но можно выбрать уровни «высокий и выше», «средний и выше» или «любой»;
• блокировка понижения аттестаций — загрузка останавливается, если у запрошенной версии нет SLSA-аттестации, в отличие от прежних версий;
• блокировка новых установочных скриптов, запускаемых через хуки preinstall и postinstall, которые могут использоваться для кражи конфиденциальных данных;
• период ожидания — запрет на установку версий моложе заданного возраста: от 1 до 365 дней, по умолчанию 1 день; значение 0 отключает правило.

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

Отрасль берёт паузу

Параллельно Rust 1.100, выход которого запланирован на 12 ноября 2026 года, получит настраиваемый минимальный возраст публикации крейтов. Параметр global-min-publish-age в cargo/config.toml задаёт его в днях или неделях; если параметр не указан, по умолчанию действует семидневная пауза.

За последний год похожие периоды ожидания появились в npm, Python, Visual Studio Code, Ruby, Bun, pnpm и Yarn. Они затрудняют атаки, при которых злоумышленник захватывает аккаунт мейнтейнера и публикует отравленную версию популярного пакета, рассчитывая на её быстрое распространение.

В компании Socket отмечают и обратную сторону: легитимным исправлениям тоже приходится ждать, если разработчики не сделают исключение. Кроме того, вредоносный код с возрастом безвредным не становится: незамеченный релиз может просто пережить период ожидания. Ценность подхода в том, что исследователи, мейнтейнеры и реестры выигрывают время, чтобы среагировать до того, как очередное обновление зависимостей разнесёт атаку дальше.

Источник: The Hacker News