GitHub представила npm Firewall для защиты от вредных зависимостей

GitHub запустила в публичном превью npm Firewall — шлюз для блокировки подозрительных npm-пакетов до их установки. Функция доступна всем клиентам GitHub Enterprise Cloud, включая вариант с резидентностью данных, и пока работает только с npm.

Проверка происходит до установки

npm Firewall анализирует запросы метаданных и скачивание пакетов, выступая политическим барьером на этапе установки. GitHub предлагает размещать его между конечными точками или внутренними реестрами компании и внешними репозиториями пакетов.

Вместо прямого обращения к публичному реестру агенты для программирования, CI/CD-хосты и другие системы должны направлять запросы через этот шлюз. Такой сценарий рассчитан в том числе на процессы, где зависимости устанавливаются автоматически без явного действия человека.

После проверки политики firewall либо разрешает загрузку, либо останавливает её до попадания пакета в среду сборки или на конечную точку. Для ошибочно заблокированных пакетов предусмотрен запрос исключения, который могут одобрить администраторы предприятия и менеджеры по безопасности.

Какие правила доступны администраторам

Политики опираются на GitHub Advisory Database. Можно блокировать пакеты с активными предупреждениями о вредоносном ПО, а также версии с уязвимостями определённой серьёзности. По умолчанию установка блокируется только при критическом уровне, но доступны варианты «высокий и выше», «средний и выше» и любой уровень.

Отдельное правило отслеживает понижение уровня аттестации: firewall сопоставляет аттестации запрошенной версии с предыдущими и останавливает скачивание, если у новой версии нет SLSA-аттестации. Ещё один контроль обнаруживает недавно добавленные скрипты preinstall и postinstall, которые могут использоваться для кражи чувствительных данных.

Администратор также задаёт минимальный возраст версии — от 1 до 365 дней. Значение по умолчанию составляет один день, а при установке 0 правило отключается. Такой период не делает вредоносный код безопасным, но даёт время на обнаружение и выпуск предупреждений до того, как новая версия попадёт в автоматические обновления зависимостей.

Контекст для цепочек поставки ПО

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

GitHub делает контроль установки частью корпоративного маршрута зависимостей: организации могут определить допустимый риск, направить через шлюз CI-системы и агентов, а исключения оставить под контролем ответственных сотрудников. Для бизнеса практический шаг состоит в том, чтобы согласовать эти правила с процессом сборки и порядком одобрения исключений, прежде чем включать автоматическую установку зависимостей.