СICADA8
Dependency Firewall

Превентивный фаервол для защиты цепочки поставок ПО
Новое поколение управления уязвимостями во внутреннем периметре компании
Проблема

Атаки, которые пропускает проверка по CVE

Через зависимости приходят атаки четырёх классов. Злоумышленник выкладывает в публичный реестр вредоносный пакет или вредоносную версию известного пакета, и сборка может скачать их раньше, чем появится CVE. У пакетов‑двойников и пакетов, которые подменяют внутреннее имя, CVE, как правило, нет. Пока записи нет, проверка по CVE такие пакеты пропускает.
Account takeover
захват аккаунта мейнтейнера
npm: chalk, debug — опубликованы вредоносные версии, 2025
Typosquatting
пакет-двойник
npm: crossenv вместо cross-env — крал переменные окружения, 2017
Dependency confusion
подмена внутреннего имени
npm, PyPI: публичный пакет с внутренним именем — ставится вместо вашего
Protestware
саботаж автора
npm: node-ipc — перезаписывал файлы по геолокации, 2022

Транзитивные зависимости

Прямые зависимости тянут за собой транзитивные. Их подбирает менеджер пакетов, и команда их не выбирает. Проверка собственного кода эти пакеты не покрывает, хотя они попадают в сборку. Вредоносный код в npm и PyPI может исполниться уже при установке пакета, на раннере CI, где лежат токены.
Транзитивные зависимости CICADA8 DF
Окно после скачивания CICADA8 DF

Окно после скачивания

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

Как устроен Dependency Firewall

DF стоит между публичными реестрами и потребителями пакетов и образов: корпоративными репозиториями (Nexus, Artifactory, Harbor), CI, командами разработки и Kubernetes. Каждый пакет и образ проверяется до выдачи: запрещённая версия не выдаётся, разрешённая уходит потребителям.
Для менеджеров пакетов и Docker DF выглядит как ещё один внутренний реестр со своим адресом и учётными записями.
Схема как устроен CICADA8 Dependency Firewall
Схема как устроен CICADA8 Dependency Firewall
запрет 403
до сборки не дошёл
1
DF на границе контура
2
Запрос идёт через DF
3
Запрещённый пакет остаётся за DF
4
Проверенные пакеты уходят потребителям
Проверка на входе
Вредоносные версии, уязвимости, лицензии, секреты в образах
На пути запроса
Пакет или образ получает запрет или пропуск до выдачи клиенту
Скачивание и публикация
Пакеты и образы проверяются при скачивании, образы ещё и при публикации
Видео

Путь сборки через DF

Короткий ролик о сборке: DF отклоняет вредоносный пакет, уязвимую версию и образ с секретами, затем после обновления базы угроз перепроверяет состав сборки.
Сценарии

Четыре точки контроля в вашей инфраструктуре

DF контролирует четыре точки: вход в контур, путь от корпоративного репозитория к командам разработки и CI, публикацию образа и его выдачу в продуктив. Точки контроля передают состав сборок и находки в платформу DF, она выгружает их в системы SecOps.
Ваш контур
Точка 1
Точка 2
Точка 3
Точка 4
Secops
Практики
схема сценарии DF ваш контур
схема сценарии DF ваш контур
Ваш контур
Пакеты и образы из публичных реестров идут в корпоративный репозиторий, к командам разработки и в CI, собранные образы уходят в продуктив. Дальше на схеме показано, где на этом пути встаёт DF.
схема сценарии DF точка 1
схема сценарии DF точка 1
1
Вход в контур
Корпоративный репозиторий получает пакеты из интернета через DF. Здесь действуют общие политики компании: они запрещают пакеты с недопустимыми лицензиями, малоизвестные и заброшенные проекты, а также вредоносные версии, в том числе известные пакеты-двойники. В кеш репозитория попадает только проверенное.
Пример
crossenv не попадёт ни в кеш, ни в сборку billing-api
схема сценарии DF точка 2
схема сценарии DF точка 2
2
Команды и CI
Команды и CI скачивают пакеты через DF под своими учётными записями, и к этим учётным записям применяются политики команды. К логину CI добавляется номер сборки, поэтому DF связывает каждый скачанный пакет со сборкой.
Пример
lodash 4.17.11 получает 403 с номером политики и ссылкой на карточку блокировки в логе сборки
схема сценарии DF точка 3
схема сценарии DF точка 3
3
Публикация образа
CI публикует образ через DF, и DF проверяет каждый слой: уязвимости, секреты и лицензии. Образ, который запрещает политика, в реестр не попадает.
Пример
billing-api:1.4.2 с ключом AWS отклонён, тега в реестре нет. Версия 1.4.3 опубликована
схема сценарии DF точка 4
схема сценарии DF точка 4
4
Выдача в продуктив
Кластер продуктива скачивает образы через DF под своей учётной записью и по своим политикам.
Пример
продуктив получает billing-api:1.4.3, прошедший проверку при публикации
схема сценарии DF Secops
Состав и перепроверка
Платформа DF хранит состав сборок из CI и при обновлении базы угроз перепроверяет последние сборки без пересборки. Если появилась новая уязвимость, сборка получает отметку «Есть изменения», а пользователям платформы приходит уведомление. SBOM и находки платформа передаёт в системы SecOps.
Пример
платформа DF хранит состав сборок из CI и при обновлении базы угроз перепроверяет последние сборки без пересборки. Если появилась новая уязвимость, сборка получает отметку «Есть изменения», а пользователям платформы приходит уведомление. SBOM и находки платформа передаёт в системы SecOps
схема сценарии DF Практики
схема сценарии DF Практики
Анализ кода (SAST)
не DF
Контроль open source на входе (OSA)
DF, точки 1 и 2
Анализ состава сборок (SCA)
платформа DF; ваш SCA в CI остаётся
Контроль образов
DF, точки 3 и 4
Среда исполнения
не DF
Один экземпляр DF на все точки или несколько: решаете вы. Точки разделяются группами фаервола: у каждой группы свои псевдонимы реестров и учётные записи.
В закрытый контур база угроз CICADA8 приходит файлом.
Возможности

Политики, проверки и интеграции

Как DF принимает решение по запросу, что проверяет в пакетах и образах и куда передаёт результаты.
Политики
Мягкая блокировка
Контекст сборки
Образы по слоям
База угроз и фиды
Экосистемы и интеграции
схема Dependency Firewall угрозы и критерии
схема Dependency Firewall угрозы и критерии
Политика состоит из правил, правило собирается из условий по 44 параметрам: фид угроз Kaspersky OSS (отдельная лицензия), стоп-листы имён, версий и хешей, уязвимости, лицензии, секреты и метаданные пакета. Условия внутри правила объединяются по «И», правила объединяются по «И» или «ИЛИ», в том числе группами.
схема Dependency Firewall первоя подходящая политика
схема Dependency Firewall первоя подходящая политика
Запрос проходит политики компании, затем политики команды, сверху вниз, и решает первая подходящая. Если не подошла ни одна, действует запрет по умолчанию с записью в журнале активности.
схема Dependency Firewall контекст сборки
схема Dependency Firewall контекст сборки
К логину CI добавляются номер сборки и проект: 4812---billing-api---ci, пароль прежний. DF связывает со сборкой каждый скачанный пакет, включая транзитивные и опубликованный образ. Если адреса в клиентах пока не меняли, CI загружает в DF SBOM или lock-файл npm, PyPI или Composer тем же логином.
GitLab CI
GitHub Actions
Azure DevOps
Jenkins
схема Dependency Firewall образы по слоям
схема Dependency Firewall образы по слоям
При публикации через DF Docker- и OCI-образ проверяется слой за слоем: уязвимости, секреты и лицензии. При запрете клиент получает отказ с текстом политики и ссылкой на карточку блокировки, и тег в реестре не появляется. DF публикует разрешённый образ в целевой реестр. Образы из внешних реестров при скачивании проверяются так же.
схема Dependency Firewall база угроз и фиды
схема Dependency Firewall база угроз и фиды
CICADA8 собирает базу угроз ежедневно из более чем 30 источников, в том числе БДУ ФСТЭК и EPSS. Фид Kaspersky OSS подключается по отдельной лицензии. Политика по категории угрозы запрещает версии, которые фид относит к вредоносным, хакерским инструментам или саботажу автора (protestware), в том числе без CVE.
схема Dependency Firewall экосистемы и интеграции
схема Dependency Firewall экосистемы и интеграции
DF работает с npm, PyPI, Maven и Gradle, Go, Cargo, RubyGems, NuGet, Composer, Docker- и OCI-образами и системными пакетами APK, DEB и RPM. Подключается к корпоративным репозиториям Nexus, Artifactory и Harbor. Выгружает SBOM и находки во внешние системы, поддерживает вход через SSO (OpenID Connect) и интеграцию по REST API. Экспорт SBOM доступен по пакету и по сборке.
Преимущества

Почему Dependency Firewall

Три свойства DF, которые можно увидеть на демо и проверить на пилоте.
01
Образ по слоям
При публикации Docker-образ проверяется по слоям, в том числе на секреты. Образ с ключом в слое в реестр не попадает.
02
Состав сборки
Состав сборки складывается из её фактических скачиваний через DF. Отдельный шаг сканирования в пайплайне для этого не нужен.
03
Вердикт в контуре
Фаервол проверяет запросы по локальной копии базы угроз внутри контура, с интернетом и без. Обращений к CICADA8 и телеметрии в нём нет. Обновления базы загрузчик берёт из реестра CICADA8 или получает файлом.

Запишитесь на пилот

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

Ответы на частые вопросы

Разбор вашей схемы и план пилота

Оставьте заявку: покажем DF на созвоне, разберём вашу схему и предложим план пилота.
Что будет после заявки
1
Созвон: покажем DF
2
Разбор вашей схемы: какие точки нужны и с какой начать
3
План пилота: критерии и программа испытаний