GitHub открыл публичное предварительное тестирование пакетного файрвола, который проверяет npm-пакеты до установки и блокирует загрузки, не прошедшие заданные правила. Сервис доступен клиентам GitHub Enterprise Cloud, в том числе использующим версию с хранением данных в определённом регионе. Пока поддерживаются только npm-пакеты.
GitHub называет новинку «контрольным шлюзом на этапе установки». Он проверяет запросы метаданных и сами загрузки на признаки вредоносной активности. Файрвол размещается между конечными системами или внутренними реестрами и внешними репозиториями пакетов: вместо прямого обращения к публичному реестру запросы могут направляться через него. Среди возможных отправителей — среды для кодовых ИИ-агентов и узлы CI/CD.
Повод для такого контроля — автоматическая установка зависимостей. ИИ-агент может добавить пакет, чтобы выполнить задачу, а CI-система — скачать его при сборке; в обоих случаях установка порой происходит без отдельного подтверждения пользователя. Если пакет заражён, атака может начаться прямо во время установки.
Файрвол не блокирует всё подряд по умолчанию: администраторы должны настроить политики. Правило «Блокировать известное вредоносное ПО» сверяется с GitHub Advisory Database и ищет действующие уведомления о вредоносных пакетах. Другая политика запрещает версии с уязвимостями: начальный порог — только критические, но его можно изменить на «Высокий и выше», «Средний и выше» или «Любая степень серьёзности».
Отдельный контроль выявляет понижение уровня подтверждений происхождения пакета. Он сравнивает аттестации запрошенной версии с более ранними и останавливает загрузку, если у новой версии нет аттестации SLSA. Ещё одно правило отслеживает недавно добавленные сценарии установки, запускаемые через хуки preinstall и postinstall: такие скрипты могут использовать для кражи конфиденциальных данных.
Администратор может задать и период ожидания для новых версий: пакет не установится, пока с момента публикации не пройдёт установленное число дней. Допустимый диапазон — от 1 до 365 дней, значение по умолчанию — один день. Установка без задержки доступна при значении 0. Если файрвол ошибочно заблокировал нужный пакет, пользователь может запросить исключение; одобрить его вправе администратор предприятия или менеджер по безопасности.
Похожая мера готовится и в Rust. Версию Rust 1.100 планируют выпустить 12 ноября 2026 года; в неё собираются добавить настройку минимального возраста публикации пакета. Параметр global-min-publish-age задаётся в cargo/config.toml, а срок можно указать в днях или неделях. Если настройку не задать, Cargo будет ждать семь дней и пропускать релизы, опубликованные в течение этого периода.
За последний год периоды ожидания появились также в npm, Python, Microsoft Visual Studio Code, Ruby, Bun, pnpm и Yarn. Задержка даёт исследователям, сопровождающим проектов и реестрам время заметить подозрительный релиз до того, как он попадёт в сборки. Это особенно полезно при атаке на аккаунт сопровождающего популярного пакета: злоумышленник может опубликовать заражённую версию, рассчитывая на быстрые автоматические обновления.
У подхода есть цена. По оценке Socket, вместе с вредоносными релизами могут задерживаться и полезные исправления, если разработчики не оформят исключение. А сам факт, что версия пролежала несколько дней, не делает её безопасной: незамеченная атака способна пережить срок ожидания. Выигрыш в другом — у специалистов и реестров появляется время отреагировать, прежде чем очередное обновление зависимости распространит проблему дальше.
GitHub называет новинку «контрольным шлюзом на этапе установки». Он проверяет запросы метаданных и сами загрузки на признаки вредоносной активности. Файрвол размещается между конечными системами или внутренними реестрами и внешними репозиториями пакетов: вместо прямого обращения к публичному реестру запросы могут направляться через него. Среди возможных отправителей — среды для кодовых ИИ-агентов и узлы CI/CD.
Повод для такого контроля — автоматическая установка зависимостей. ИИ-агент может добавить пакет, чтобы выполнить задачу, а CI-система — скачать его при сборке; в обоих случаях установка порой происходит без отдельного подтверждения пользователя. Если пакет заражён, атака может начаться прямо во время установки.
Файрвол не блокирует всё подряд по умолчанию: администраторы должны настроить политики. Правило «Блокировать известное вредоносное ПО» сверяется с GitHub Advisory Database и ищет действующие уведомления о вредоносных пакетах. Другая политика запрещает версии с уязвимостями: начальный порог — только критические, но его можно изменить на «Высокий и выше», «Средний и выше» или «Любая степень серьёзности».
Отдельный контроль выявляет понижение уровня подтверждений происхождения пакета. Он сравнивает аттестации запрошенной версии с более ранними и останавливает загрузку, если у новой версии нет аттестации SLSA. Ещё одно правило отслеживает недавно добавленные сценарии установки, запускаемые через хуки preinstall и postinstall: такие скрипты могут использовать для кражи конфиденциальных данных.
Администратор может задать и период ожидания для новых версий: пакет не установится, пока с момента публикации не пройдёт установленное число дней. Допустимый диапазон — от 1 до 365 дней, значение по умолчанию — один день. Установка без задержки доступна при значении 0. Если файрвол ошибочно заблокировал нужный пакет, пользователь может запросить исключение; одобрить его вправе администратор предприятия или менеджер по безопасности.
Похожая мера готовится и в Rust. Версию Rust 1.100 планируют выпустить 12 ноября 2026 года; в неё собираются добавить настройку минимального возраста публикации пакета. Параметр global-min-publish-age задаётся в cargo/config.toml, а срок можно указать в днях или неделях. Если настройку не задать, Cargo будет ждать семь дней и пропускать релизы, опубликованные в течение этого периода.
За последний год периоды ожидания появились также в npm, Python, Microsoft Visual Studio Code, Ruby, Bun, pnpm и Yarn. Задержка даёт исследователям, сопровождающим проектов и реестрам время заметить подозрительный релиз до того, как он попадёт в сборки. Это особенно полезно при атаке на аккаунт сопровождающего популярного пакета: злоумышленник может опубликовать заражённую версию, рассчитывая на быстрые автоматические обновления.
У подхода есть цена. По оценке Socket, вместе с вредоносными релизами могут задерживаться и полезные исправления, если разработчики не оформят исключение. А сам факт, что версия пролежала несколько дней, не делает её безопасной: незамеченная атака способна пережить срок ожидания. Выигрыш в другом — у специалистов и реестров появляется время отреагировать, прежде чем очередное обновление зависимости распространит проблему дальше.
