Брандмауэр зависимостей: блокировка рискованных пакетов до сборки

Источник: GitLab•

Брандмауэр зависимостей: блокировка рискованных пакетов до сборки

Брандмауэр зависимостей GitLab помогает автоматически защищать сборку от вредоносных и уязвимых пакетов, позволяя командам и их агентам быстро выпускать ПО с проверенными зависимостями.

Злоумышленники маскируют вредоносные пакеты под те, которым вы доверяете. В июне 2026 года исследователи GitLab обнаружили пять вредоносных пакетов PyPI (четыре из них были тайпсквотами для Flask, Requests и NumPy), которые запускаются во время установки и похищают учетные данные CI/CD. Кроме того, ИИ-ассистенты для написания кода теперь самостоятельно добавляют зависимости с открытым исходным кодом, зачастую без проверки, из-за чего у разработчиков нет контроля над тем, какие пакеты могут загрязнить вашу сборку.

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

Брандмауэр зависимостей GitLab (GitLab Dependency Firewall), представленный сегодня на конференции Transcend в рамках раннего доступа, позволяет блокировать пакеты, соответствующие вашим политикам (включая вредоносные, уязвимые и несоответствующие требованиям), до того, как они попадут в сборку. Встроенные механизмы управления устраняют риски до момента установки, поэтому вашей команде не придется отслеживать, удалять или пересобирать то, что было заблокировано политикой. Разработчики и их ИИ-ассистенты могут продолжать получать необходимые зависимости, не дожидаясь ручной проверки безопасности, а пакеты, удовлетворяющие требованиям вашей политики, становятся частью вашей официальной сборки.

Посмотрите запись нашего мероприятия Transcend, чтобы увидеть демонстрации новых возможностей платформы и узнать, что требуется для того, чтобы внедрить скорость агентного ИИ во весь жизненный цикл ПО.

Посмотрите запись нашего мероприятия Transcend, чтобы увидеть демонстрации новых возможностей платформы и узнать, что требуется для того, чтобы внедрить скорость агентного ИИ во весь жизненный цикл ПО.

Блокируйте вредоносные пакеты без нарушения процесса сборки

Без политики на этапе установки вредоносный пакет сначала попадает в сборку и обнаруживается позже. Инструменты анализа состава программного обеспечения (SCA) сканируют то, что вы уже загрузили, поэтому к моменту, когда они фиксируют вредоносный пакет, уязвимость высокой степени критичности или лицензию, которую ваша юридическая служба не одобряет, зависимость уже установлена и могла быть отправлена в составе артефакта. Отслеживание пути пакета, его удаление и пересборка превращают рутинный запуск пайплайна в непредвиденную работу для вашей инженерной команды.

С помощью Брандмауэра зависимостей вы определяете, что разрешено в ваших сборках до момента установки, настраивая политики для:

  • Статуса вредоносности — пакеты, отмеченные в базе данных рекомендаций по вредоносному ПО от GitLab
  • Серьезности уязвимостей — уровень серьезности, который вы задаете (критический, высокий, средний или низкий), и количество допустимых срабатываний на этом уровне, включая ноль
  • Типа лицензии — разрешенные или запрещенные лицензии, указанные по полному названию, а также правила обработки пакетов, лицензию которых не удалось определить
  • Возраста пакета — минимальный возраст, которого должен достичь пакет перед попаданием в сборку (чтобы версия, опубликованная несколько минут назад, не попала туда напрямую до того, как кто-либо ее проверил)

Внедрение контроля не обязательно должно ставить под угрозу поставку. Начните в режиме предупреждения, когда брандмауэр фиксирует, что именно поймала бы политика, но позволяет сборке продолжаться. При этом создается событие аудита, запись в панели мониторинга и строка в сводке CI, что позволяет проанализировать, стоит ли блокировать сборку.

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

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

Брандмауэр, осуществляющий контроль только на уровне реестра, навязывает всем единую политику, что редко подходит для реальных условий работы команд. Платежный сервис и внутренний прототип имеют совершенно разные риски, и ваша политика должна относиться к ним по-разному.

С помощью Брандмауэра зависимостей вы задаете единую политику для группы верхнего уровня, и каждый подчиненный проект наследует те же правила. Когда команде требуется что-то иное, вы можете задать политику для этой конкретной группы или проекта.

Вы также можете применять политику на уровне реестра, чтобы проверялся каждый запрос на получение, а не только запросы из пайплайна. Правила хранятся в виде кода в проекте политик безопасности, поэтому их проверка и изменение осуществляются через merge request, как и остальная часть вашей конфигурации. Они наследуются от группы верхнего уровня до каждого проекта, и в случае пересечения правил применяется наиболее строгое. Критически важный сервис может быть защищен строже базового уровня организации, и ни один проект не опускается ниже него.

Проверьте пакет до того, как загрузить его

Разработчик или действующий от его имени ИИ-ассистент обычно узнает о том, что пакет запрещен, только в момент сбоя пайплайна. Это приводит к потере цикла сборки и потере концентрации именно тогда, когда работа движется вперед.

Вы получаете ответ от Брандмауэра зависимостей GitLab еще до добавления зависимости, прямо в привычной рабочей среде, что позволяет выбрать пакет, который пройдет проверку с первого раза.

Используя интерфейс командной строки GitLab в терминале или в скрипте, можно выполнить проверку из командной строки, чтобы определить, пройдет ли пакет проверку или будет заблокирован вашей политикой, без необходимости открывать отдельную консоль. Поддерживаются популярные менеджеры пакетов, такие как npm, pip, Poetry, Maven, Gradle и Bundler, а скоро появятся и новые.

Просматривайте и подтверждайте каждое решение

Руководитель отдела безопасности должен иметь возможность доказать аудитору эффективность работы элемента контроля. Элемент контроля, который блокирует скрытно, без какой-либо записи, не отвечает на вопросы аудитора и не формирует доверие у команд, которыми он управляет.

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

Панель мониторинга Брандмауэра зависимостей отображает активность и результаты для всех проектов в зоне действия. Каждое предупреждение, блокировка и обход записывают событие аудита с указанием сработавшего правила, стоящей за ним политики и задействованного пакета.

Получите ранний доступ к Брандмауэру зависимостей GitLab

Вы можете останавливать вредоносные, уязвимые и несоответствующие требованиям пакеты до того, как они попадут в сборку. Он совместим с GitLab Artifact Central и внешними реестрами от Sonatype Nexus Repository и JFrog Artifactory, и не требует развертывания отдельного инструмента рядом с вашей инсталляцией GitLab. Брандмауэр зависимостей теперь доступен по программе раннего доступа для клиентов GitLab.com и GitLab Self-Managed с тарифами Premium или Ultimate. Запросите ранний доступ сегодня!

О чём эта статья

Ещё в разделе «Разработка ПО»

Все →

Ещё от GitLab