Ing. Calogero Bono
GitHub представил 20 октября 2026 года package firewall, фильтр, который стоит между компьютерами, устанавливающими пакеты, и публичными реестрами, откуда они их скачивают. Сейчас он доступен в публичной превью всем клиентам GitHub Enterprise Cloud и поддерживает только npm. Цель в том, чтобы остановить вредоносное ПО, которое атакует в момент установки, и это особенно опасно для AI-агентов и систем сборки, которые ставят зависимости без присмотра. Если ты разрабатываешь софт или руководишь теми, кто это делает, это сигнал о том, куда движется безопасность цепочки поставок.
Несколько терминов, прежде чем перейти к фактам. Реестр (registry) это онлайн-хранилище, откуда скачивают пакеты, например npm для JavaScript. Зависимость это чужой фрагмент кода, который использует твой проект. CI/CD это автоматические процедуры, которые собирают и публикуют софт. Аттестация SLSA это проверяемое заявление о том, как и кем был собран пакет. Метаданные это сведения о пакете, например список доступных версий.
Что такое package firewall от GitHub?
Согласно официальному changelog GitHub, в последнее время поднялась настоящая волна атак вредоносного ПО, которое использует момент установки пакетов. Особенно уязвимы AI-агенты и раннеры CI, потому что они устанавливают зависимости для выполнения задачи или сборки без человека в процессе.
Firewall располагается между конечными точками или внутренними реестрами и вышестоящими репозиториями пакетов. Как сообщает The Hacker News, GitHub описывает его так – «The firewall inspects both metadata requests and package downloads for signs of malicious activity, acting as an install-time policy gate», то есть как шлюз с правилами, которые применяются в момент установки.
Тема не теоретическая. Сайт The Register написал о кампании, в которой злоумышленники превратили issue на GitHub в атаку на цепочку поставок против 61 публичного репозитория менее чем за час. Из доступной нам страницы больше деталей не следует, поэтому мы не можем сказать, связаны ли эти две новости и как именно.
Как он работает и какие проверки предлагает?
Процесс состоит из двух шагов. Сначала администраторы задают правила для своей enterprise. Затем AI-агенты для программирования и хосты CI/CD обращаются к firewall, а не напрямую к публичным реестрам. И запросы метаданных, и загрузки пакетов проходят через firewall, который проверяет их по политике.
Доступные проверки
По списку The Hacker News, доступны следующие проверки.
- Блокировка известного вредоносного ПО с опорой на активные предупреждения в GitHub Advisory Database.
- Блокировка по степени серьезности уязвимостей, тоже через эту базу. По умолчанию блокируется только уровень «Critical only», но можно выбрать «High or higher», «Medium or higher» или «Any severity».
- Блокировка понижения аттестаций. Firewall сравнивает аттестации запрашиваемой версии с аттестациями предыдущих версий и останавливает загрузку, если аттестация SLSA отсутствует.
- Блокировка новых скриптов установки, то есть тех, которые запускаются через хуки preinstall или postinstall и могут использоваться для кражи конфиденциальных данных.
- Период ожидания (cooldown), который не дает устанавливать версии новее заданного минимального возраста.
Cooldown может составлять от 1 до 365 дней. По умолчанию это 1 день, а отключается он установкой значения 0.
А если заблокирован нормальный пакет?
Если пакет заблокирован по ошибке, пользователь может запросить исключение. Для GitHub процесс похож на тот, что используется в других функциях GitHub Advanced Security. Согласно The Hacker News, запрос может одобрить администратор или ответственный за безопасность enterprise.
Сколько стоит и кто может им пользоваться?
Сервис доступен в публичной превью всем клиентам GitHub Enterprise Cloud, включая версию с хранением данных в определенном регионе. Во время превью он бесплатный. Когда наступит общая доступность, GitHub обещает брать плату по измеренному потреблению, примерно так же, как за Actions.
GitHub объясняет, что превью нужно для расширения инфраструктуры и добавления функций по запросам клиентов. Инструкции по настройке он отсылает к документации «Protecting endpoints with package firewall».
Почему так много говорят о периодах ожидания?
Cooldown это самое простое и, пожалуй, самое распространенное правило. The Hacker News напоминает, что за последний год подобные периоды ожидания появились в npm, Python, Visual Studio Code, Ruby, Bun, pnpm и Yarn. Идея в том, чтобы снизить вероятность того, что только что опубликованная и не проверенная версия сразу попадет в сборку.
Это особенно помогает против тех, кто захватывает аккаунт мейнтейнера и публикует отравленную версию популярного пакета. Ожидание замедляет быстрое распространение, ручное или автоматическое.
Та же статья сообщает, что Rust 1.100, выход которого запланирован на 12 ноября 2026 года, должен добавить настраиваемый минимальный возраст публикации для крейтов. Опция называется «global-min-publish-age» и находится в файле cargo/config.toml. Если она не указана, применяется стандартный период ожидания в семь дней.
Обратную сторону медали отмечает Socket, которую цитирует The Hacker News. «The tradeoff is that legitimate fixes have to wait, too, unless developers make an exception», говорит компания. Она добавляет, что релиз, прошедший мимо проверок, может просто пережить cooldown. Ценность, по мнению Socket, в том, что у исследователей, мейнтейнеров и реестров появляется время на реакцию.
Ограничения, которые стоит знать
- Пока firewall поддерживает только npm. Те, кто работает с PHP, Python или другими экосистемами, не защищены, и источники не называют сроков для других реестров.
- Он доступен только клиентам GitHub Enterprise Cloud. Источники не говорят о более дешевых тарифах.
- Мы находимся в превью. Функции, инфраструктура и цены могут меняться, а стоимость при потреблении пока не определена.
- У нас нет независимых данных об эффективности. Источники приводят заявления GitHub, а не тесты на реальном вредоносном ПО, и цифр по ложным срабатываниям не приводится.
- Как напоминает Socket, cooldown не делает вредоносный код безвредным. Необнаруженная версия может оставаться скрытой и после окончания ожидания.
Что это меняет для тех, кто работает с цифровыми технологиями
Практический вывод в том, что безопасность смещается от проверки постфактум к проверке до установки. Для тех, кто разрабатывает с AI-агентами, которые сами пишут код и сами его устанавливают, это значит иметь единое центральное правило вместо доверия каждому агенту по отдельности. Если ты используешь инструменты разработки на основе AI, полезно перечитать риски, которые мы описали в статье о vibe coding для малого бизнеса.
Для итальянских компаний тема касается и соответствия требованиям. Безопасность цепочки поставок ПО входит в то, что мы рассматриваем в руководстве по реестру поставщиков NIS2. Возможность доказать, что пакеты проходят через фильтр с письменными правилами, это весомый аргумент, хотя ни один источник не связывает firewall с NIS2.
Тем, кто много использует open source, стоит помнить, что каждая зависимость это поставщик. Мы говорим об этом в материале про open source в компании. Даже тем, кто не является клиентом Enterprise, можно взять эту идею на вооружение с помощью уже доступных инструментов, например периодов ожидания, которые предлагают некоторые менеджеры пакетов.
Для серверов сборки и продакшена важны еще обновления и изоляция. Если ты хочешь инфраструктуру, которую ведут другие, есть наш сервис хостинга и управляемых серверов. Если же ты оцениваешь индивидуальный проект, путь к нему описан в разделе разработки ПО на заказ.
Наше мнение
Идея верная. Остановить пакет до того, как он запустится на компьютере, эффективнее, чем заметить проблему потом, а делать это в одной точке позволяет не полагаться на дисциплину каждого разработчика или каждого агента. То, что GitHub начинает именно с агентов без присмотра, по-нашему честный взгляд на проблему.
Оговорок две. Первая коммерческая. Такая полезная защита, пока доступная только в тарифе Enterprise и с оплатой по потреблению после превью, рискует оставить без защиты маленькие команды, которые часто самые уязвимые. Вторая техническая. Многие проверки опираются на базу данных GitHub и на время, а время не гарантия, как признает и сама Socket.
Поэтому мы не считаем это окончательным щитом. Это дополнительный уровень, полезный в сочетании с проверкой зависимостей, фиксацией версий и минимальными правами для агентов. Если ты думаешь, что достаточно включить firewall, ты обманываешь себя ложным чувством безопасности.
Частые вопросы
Package firewall от GitHub бесплатный?
Да, но только во время превью. GitHub заявляет, что при общей доступности оплата будет взиматься по измеренному потреблению, примерно как за Actions. Цены пока не объявлены.
Он работает только с npm?
Да, пока поддерживаются только пакеты npm. Источники не называют сроков для других экосистем. Если ты используешь другие языки, защиту придется искать пока другими средствами.
Кто может им пользоваться?
Все клиенты GitHub Enterprise Cloud, включая версию с хранением данных в определенном регионе. Источники не упоминают других тарифов. Администраторы настраивают правила для всей enterprise.
Что будет, если он заблокирует нормальный пакет?
Пользователь может запросить исключение. Согласно The Hacker News, запрос может одобрить администратор или ответственный за безопасность. Процесс, по словам GitHub, похож на тот, что используется в других функциях Advanced Security.
Достаточно ли периода ожидания, чтобы остановить вредоносное ПО?
Нет. Он помогает выиграть время против только что опубликованных версий, но Socket напоминает, что вредоносный код не становится безобидным со временем. Необнаруженный релиз может пережить период ожидания.
Что отслеживать до общей доступности
В ближайшие месяцы стоит следить за три вещи. За ценой при потреблении, которую установит GitHub, за возможным расширением за пределы npm и за появлением минимального периода ожидания в Rust 1.100, запланированным на 12 ноября 2026 года. А уже сейчас можно действовать так.
- Составь список зависимостей, которые используют CI и агенты, и реши, кто может что-то устанавливать без присмотра.
- Оцени период ожидания для новых версий, понимая, что он задерживает и нормальные исправления.
- Подготовь процедуру исключений, где ответственный одобряет быстро, но с письменной фиксацией.
