Что может Kaspersky Container Security

В портфолио «Лаборатории Касперского», помимо всего прочего, есть платформа для обеспечения безопасности контейнерных сред. Но в этом посте я хочу рассказать о Kaspersky Container Security (KCS) не как представитель вендора, а скорее как член команды, активно использующей это решение в повседневной работе. Наша команда Product Security Team отвечает за выстраивание процессов безопасной разработки в компании. Мы вовлечены в этапы разработки продукта на всем жизненном цикле ПО, и для нас важно помогать продуктовым командам находить проблемы безопасности заранее, чтобы они могли обеспечить плановый выход релизов. Для этого мы выстроили ряд процессов, одним из которых является процесс обеспечения безопасности контейнеров. В рамках него мы активно используем собственный продукт Kaspersky Container Security.

Решения, обеспечивающие безопасность контейнеров, как правило, воспринимаются в первую очередь как сканер образов в реестре (container registry). Но Kaspersky Container Security (KCS) — это скорее платформа для защиты контейнерной среды, которая закрывает сразу несколько задач, встраиваясь в контейнерный контур целиком. Да, сценарий сканирования контейнерных образов у него, несомненно, есть, и он важен. Но за время использования продукта мы пришли к выводу, что реальная ценность становится заметной, когда продукт встроен в несколько точек процесса сразу:

• в регулярную сборку продукта;
• в проверку артефакта перед релизом или деплоем;
• в контроль уже запущенного контейнера в кластере.

Базовый сценарий: как KCS сканирует образы

В основе все стандартно. KCS обеспечивает проверку образов на типовые для контейнеров проблемы: известные уязвимости, вредоносные объекты, забытые в коде секреты и ошибки конфигурации. Но результат сканирования не сводится к одному абстрактному вердикту. Система считает критичность (risk rating) на основе найденных проблем и дает понятную картину по объекту. В практической эксплуатации это удобно, потому что команды видят не просто сообщение «образ плохой», а четкую картину, показывающую, из чего именно складывается риск и что нужно чинить в первую очередь.

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

Более сложный сценарий: режим работы в CI/CD

Одна из функций KCS, о которой знают не все, — полноценное сканирование в пайплайнах CI/CD. Для нашей команды это наиболее подходящий режим работы продукта. Логика здесь следующая: сканер можно встроить в пайплайн, при этом результаты сканирования будут видны прямо в логах исполнения. Они также отправляются в центральную консоль продукта, где попадают в отдельный раздел CI/CD с привязкой к имени артефакта, времени сканирования, пайплайну и критичности.

В CI/CD можно сканировать образ из tar-архива или Git-репозитория. Из коробки описаны сценарии для GitLab, Jenkins, TeamCity и GitHub CI/CD, однако фактически KSC можно встроить в любой оркестратор пайплайнов.

Еще один важный момент в использовании KSC в CI/CD-сценарии связан с политиками. В нашем решении есть модель, где политики позволяют не просто собирать результаты, но и управлять поведением самого пайплайна. Это удобно для поэтапного внедрения. Можно начать с режима аудита и затем постепенно начинать останавливать сборки при обнаружении секретов, критичных мисконфигураций, уязвимостей и так далее. Такая эволюционная модель обычно работает лучше, чем включение жесткой блокировки на все подряд.

Чем KCS полезен в наших сценариях

У нас работает своя система композиционного анализа, поэтому мы не смотрим на KCS как на единственный источник истины. В наших сценариях он работает как хорошее дополнение. И именно в этом качестве продукт нам особенно интересен.

Если внутренняя система композиционного анализа решает часть задач по учету компонентов, зависимостей и оценке риска в коде — KCS хорошо закрывает то, что лежит ближе к контейнерному периметру: обеспечивает техническое сканирование образов, CI/CD-контура, собирает отчетность по контейнерным артефактам. То есть он не спорит с внутренним контуром композиционного анализа, а усиливает его там, где начинается практическая работа с контейнером.

Для нас это особенно полезно в двух сценариях. Первый — ранний контроль артефакта в процессе разработки. Второй — релизная приемка продуктовой сборки. Мы уже не обсуждаем риски «когда-нибудь после релиза», а ловим их в том месте, когда команда еще может быстро исправить Dockerfile, чарты или набор конфигов без длинной цепочки согласований.

Отдельно стоит сказать про работу с перечнем программных компонентов (SBOM). Наша система в первую очередь основывается на актуальных и релевантных SBOM продуктов. В KCS есть режимы работы, основанные на обработке SBOM, а также выдача результатов в виде того же SBOM. На этом участке KCS хорошо дополняет внутренние процессы, особенно в том плане, что процессы не нужно подстраивать под продукт, а можно, наоборот, встроить продукт в процессы.

Почему мы смотрим на KCS не только как на сканер

Еще один сильный слой у продукта — обеспечение безопасности кластера. Здесь KCS уже перестает быть инструментом только для проверки образов. У него есть runtime-политики для контейнеров и нод, режимы аудита и блокировки, а также перечень профилей безопасности. На практике это означает, что продукт можно использовать не только для поиска проблем в образе, но и для контроля того, что контейнер реально делает после запуска. Политики могут учитывать происхождение образа, цифровые подписи, ограничения по capabilities и volumes, а также процессы и сетевые соединения внутри контейнера.

При обнаружении проблемы есть возможность не сразу блокировать процесс, а сначала собрать результаты в аудит-режиме. В продакшен-средах это всегда правильнее. Также важным инструментом является контроль доверенного происхождения образов. KCS поддерживает проверку цифровых подписей образов, и это уже история не только про «найти CVE», а про контроль цепочки поставок в компании.

Работа с отчетами

KCS умеет не только показывать найденные проблемы в интерфейсе, но и работать в качестве источника отчетности. В продукте можно формировать отчеты по образам, принятым рискам, а также по бенчмаркам Kubernetes.

Сгенерированные отчеты доступны в форматах HTML, PDF, CSV, JSON и XML, а для детализированных отчетов отдельно поддерживается SARIF, что удобно для встраивания в AppSec-процессы. Отдельно я уже упоминал работу с SBOM: в сценариях сканирования можно получать артефакты и результаты в форматах CycloneDX и SPDX для упрощенного встраивания в существующие процессы.

Почему мы продолжаем использовать KCS

Если коротко, KCS отлично дополняет наши процессы. Не потому, что он решает вообще все проблемы, а потому, что хорошо встраивается в инженерные сценарии.

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

Если подвести итог: Kaspersky Container Security в правильной интеграции помогает закрывать несколько участков сразу — от базового сканирования контейнеров до CI/CD и кластерной безопасности. По нашему опыту, в живом контейнерном процессе от него действительно есть польза. Узнать о продукте больше можно на официальной странице KCS.