Обзор CICADA8 Dependency Firewall, системы контроля безопасности сторонних компонентов

1. Введение
2. Функциональные возможности CICADA8 Dependency Firewall
   1. 2.1. OSA- / SCA-анализ
   2. 2.2. Гибкое внедрение
   3. 2.3. Работа с цепочкой артефактов
3. Архитектура CICADA8 Dependency Firewall
4. Примеры внедрения CICADA8 Dependency Firewall в инфраструктуру
5. Системные требования и лицензирование CICADA8 Dependency Firewall
6. Сценарии использования CICADA8 Dependency Firewall
7. Выводы

Введение

Последние годы одним из самых популярных способов атаки на организацию является атака на цепочку поставок (supply chain). Однако не менее популярной является атака через цепочки поставок программного обеспечения (software supply chain). 

В соответствии с докладом Sonatype, компании специализирующейся на управлении компонентами программного обеспечения с открытым исходным кодом и их безопасностью, начиная с ноября 2023 года, в течение года были зарегистрированы более 500 тыс. вредоносных пакетов с открытым кодом. В соответствии с другой информацией этого источника, в 2024 году, спустя 3 года с обнаружения уязвимости Log4Shell, 13% загрузок Log4j оставались уязвимыми.

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

Для снижения риска от использования уязвимых компонентов программного обеспечения, CICADA8 выпустила продукт Dependency Firewall, основное назначение которого — контроль безопасности программных зависимостей.

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

CICADA8 Dependency Firewall попадает в сегмент рынка Software Composition Analysis и Supply Chain Security (SCA / SCS). Таких разработок в России пока не очень много, в отличие от более распространённых систем классов SAST и DAST. Значимость процессов DevSecOps, где используются такие продукты, обусловливает их востребованность.

Разберемся в этом продукте подробнее.

Функциональные возможности CICADA8 Dependency Firewall

Рассмотрим функциональные возможности продукта, использование которых помогает предотвратить попадание уязвимых компонентов в инфраструктуру. Отметим, что файрвол ставится перед платформой CI / CD и, таким образом, проверяет компоненты не реактивно, а проактивно — до их попадания в неё.

OSA- / SCA-анализ

Задачей этой функциональности является анализ артефактов, проходящих через файрвол. CICADA8 Dependency Firewall поддерживает все свободно распространяемые потоки данных об угрозах, а также фиды российских вендоров: Kaspersky OSS TDF, БДУ ФСТЭК России. Также имеется интеграция с EPSS для возможности оценки эксплуатации уязвимостей в инфраструктуре на основании истории их использования в «дикой природе».

Гибкое внедрение

Система является мультитенантной, за счет чего возможна вариативность ее внедрения в компании. При внедрении CICADA8 Dependency Firewall не зависит от существующей инфраструктуры заказчика. В том числе, для работы системы в CI / CD не требуется создания отдельных стадий для работы продукта. В этом случае достаточно указать адрес межсетевого экрана в конвейерах разработчика.

Работа с цепочкой артефактов

Продукт может связывать между собой и визуализировать входные и выходные артефакты. Таким образом, владелец CICADA8 Dependency Firewall может видеть, из чего созданы образы его приложений, и понимать, какие зависимости содержатся в образах, находящихся в продуктиве.

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

В рамках анализа образов контейнеров поддерживается более 12 языков, включая такие как C / C++, Dart, Swift, бинарные файлы и проводится анализ системных зависимостей самих контейнеров.

В системе есть 6 модулей обнаружения: npm, Pip, Go, Git, Docker, PHP Composer. Покрытие планируется расширять по мере развития продукта.

Рисунок 1. Функциональные возможности CICADA8 Dependency Firewall

Архитектура CICADA8 Dependency Firewall

CICADA8 Dependency Firewall состоит из трех частей: межсетевого экрана, движка политик безопасности и модуля композиционного анализа программного обеспечения (SCA).

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

В системе реализован механизм точечного доступа к конкретным репозиториям и применения гранулярных политик безопасности для разных команд разработки.

Рисунок 2. Архитектура CICADA8 Dependency Firewall

Продукт поддерживает разные режимы работы:

• Режим прокси, когда он работает как стандартный Forward MitM Proxy, при этом он указывается в компонентах инфраструктуры, перехватывает трафик, расшифровывает и передает далее на целевые репозитории.
• Режим реестра, когда CICADA8 Dependency Firewall предоставляет API для взаимодействия с реестром контейнеров.

Рисунок 3. Режимы работы CICADA8 Dependency Firewall

Идентификация клиентов происходит по двум сценариям:

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

CICADA8 Dependency Firewall работает по принципу «что не разрешено, то запрещено». Например, если у клиента есть  доступ к DF, но нет соответствующей политики безопасности, система будет блокировать его запросы.

Примеры внедрения CICADA8 Dependency Firewall в инфраструктуру

CICADA8 Dependency Firewall устанавливается между внутренними потребителями (корпоративными репозиториями, CI / CD, K8s-кластерами, разработчиками) и репозиториями из которых получаются образы Docker-контейнеров, Cargo-пакетами, NPM-пакетами и другими артефактами.

Рисунок 4. Принципиальная схема работы CICADA8 Dependency Firewall 

Рассмотрим реальный кейс внедрения продукта в инфраструктуру заказчика. Межсетевой экран устанавливается перед корпоративным репозиторием и проверяет элементы, загруженные из Интернета. Далее CICADA8 Dependency Firewall используется для проверки артефактов из корпоративного репозитория в CI / CD. Далее систему можно использовать перед публикацией приложений в репозитории продуктивного окружения. 

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

Рисунок 5. Пример интеграции CICADA8 Dependency Firewall в инфраструктуру

Другой кейс: у заказчика имеется конвейер сборки образов. В этом случае CICADA8 Dependency Firewall установлен в режиме прокси. В реестре для хранения Docker-образов Harbor был внедрен «золотой образ». Поступающие образы сверяются с ним перед публикацией в Harbor, откуда их в дальнейшем могут забрать продуктовые команды с дополнительной проверкой. Это позволяет снизить риск использования уязвимых образов в связи с тем, что ежедневно происходит обновление базы угроз. 

Рисунок 6. Пример интеграции CICADA8 Dependency Firewall в инфраструктуру в режиме Proxy

Системные требования и лицензирование CICADA8 Dependency Firewall

Минимальные требования к аппаратной платформе для функционирования CICADA8 Dependency Firewall приведены в таблице 1. Рекомендуемые системные требования рассчитываются исходя из целевых нагрузок.

Таблица 1. Системные требования к серверу CICADA8 Dependency Firewall

Стоимость лицензии CICADA8 Dependency Firewall зависит от количества межсетевых экранов и хостов, с которых на него обращаются. Лицензия является срочной, годовой. В случае, если требуется интеграция с Kaspersky OSS TDF, право на его использование приобретается отдельно.

Рисунок 7. Схема лицензирования CICADA8 Dependency Firewall

Сценарии использования CICADA8 Dependency Firewall

Стартовое окно системы представляет собой набор дашбордов, приводящих статистику используемых артефактов в разрезе лицензий, уязвимостей, наличия секретов и т.д.

Рисунок 8. Панель дашбордов CICADA8 Dependency Firewall

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

Рисунок 9. Регистрация межсетевых экранов в CICADA8 Dependency Firewall

После регистрации следует этап конфигурирования созданных межсетевых экранов, загрузки сертификатов, присвоения алиасов для репозиториев и т.д.

Рисунок 10. Конфигурирование межсетевых экранов в CICADA8 Dependency Firewall

После конфигурации требуется создание сущности Identity — группы хостов, которая определенным образом идентифицируется. Сущностью Identity может быть IP-адрес, диапазон IP-адресов, подсеть или токен.

Рисунок 11. Создание Identity в CICADA8 Dependency Firewall

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

Рисунок 12. Безуспешная попытка скачивания образа в CICADA8 Dependency Firewall

Политика создается в отдельной вкладке «Policy». При создании можно сразу указать правила, которые будут использоваться при анализе артефактов на соответствие. Внутри одной политики правила работают по принципу логического «И», в случае необходимости применения логического «ИЛИ» создается еще одна политика.

Рисунок 13. Создание политики в CICADA8 Dependency Firewall

Рисунок 14. Создание правила в CICADA8 Dependency Firewall

После того как была создана политика и добавлено правило, скачивание образа проходит успешно.

Рисунок 15. Успешная попытка скачивания образа в CICADA8 Dependency Firewall

Информация о скачанных файлах попадает в раздел «Активность брандмауэра», в котором находится краткое описание полученных артефактов. 

Рисунок 16. Информация о скачанных файлах в CICADA8 Dependency Firewall

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

Наведя мышку на описание или кликнув по конкретной уязвимости, можно получить её подробное описание, с указанием рейтинга по CVSS, EPSS, идентификаторами и т.д.

Рисунок 17. Подробное описание скачанных файлов в CICADA8 Dependency Firewall

Рисунок 18. Описание уязвимостей в CICADA8 Dependency Firewall

Функциональные возможности CICADA8 Dependency Firewall позволяют проводить анализ Git-репозитория. В этом случае карточка образа выглядит иначе. В системе реализована карточка скоринга, которая оценивает, насколько репозиторий безопасен с точки зрения информационной безопасности. Система скоринга по уязвимостям рассчитывается исходя из рейтинга эксплуатабельности (EPSS).

Рисунок 19. Описание уязвимостей в CICADA8 Dependency Firewall

Информацию о проведенном анализе образов можно скачать с помощью модуля отчетов в формате CSV.

Выводы

CICADA8 Dependency Firewall предназначен для непрерывного обнаружения и анализа артефактов на этапе загрузки. Система поддерживает обнаружение образов контейнеров, Pip, npm, Go, Git, PHP Composer, бинарных файлов и более 10 языков программирования. CICADA8 Dependency Firewall имеет возможность гибкого внедрения в инфраструктуру, организации наблюдаемости цепочки поставок, OSA / SCA в реальном времени. Использование продукта позволяет минимизировать вероятность использования уязвимых компонентов в продуктивном окружении. 

До конца года разработчик планирует внедрить ряд функций. Во-первых, генерацию обогащенного перечня программных компонентов (SBOM) для публикуемого образа приложения исходя из связанных артефактов на этапе загрузки и их транзитивных зависимостей. Во-вторых, отложенный анализ зависимостей PyPI, Npm, RubyGems в песочнице с помощью ИИ. Еще одной внедряемой функцией является анализ достижимости зависимостей в исходном коде с помощью ИИ.

Достоинства:

• Гибкое внедрение.
• Оценка актуальности угроз.
• Наблюдаемость цепочки поставок.
• Не требует изменений в работе разработчика.
• Обнаружение секретов.

Недостатки:

• Малое количество интеграций.
• Отсутствует повторная проверка уязвимостей (планируется внедрение в июле 2025 г.).
• Отсутствие сертификата ФСТЭК России (в планах его получение в 2025 г.).