Ваша платформа запускает квартальное сканирование контейнеров, и образы Camunda возвращаются с результатами, как и любой другой образ в реестре. К следующему утру вопросы доходят до вашего поставщика. Какие уязвимости имеют значение? Когда они будут исправлены? Кто несет ответственность за те, что скрыты в сторонних компонентах?
На эти вопросы с каждым кварталом отвечать все сложнее. Программа CVE опубликовала 48 244 распространенных уязвимости и угрозы (CVE) в 2025 году и 35 872 только за первую половину 2026 года, согласно опубликованным ею метрикам. Процесс обнаружения также постоянно ускоряется, поскольку языковые модели делают поиск изъянов дешевле как для защитников, так и для злоумышленников. Любой продукт, созданный на основе компонентов с открытым исходным кодом, в конечном итоге обнаруживается сканером, поэтому скептически относитесь к поставщику, который обещает обратное. То, чего вы можете требовать от поставщика — это меньше шума у источника, честная оценка того, что осталось, исправления для каждой поддерживаемой версии и доказательства, которые вы можете проверить самостоятельно.
Меньше находок, начиная с базового образа
Большинство результатов сканирования контейнерных образов исходят не от самого приложения. Они происходят из нижележащих слоев: пакетов операционной системы, сред выполнения языков и утилит, поставляемых в базовом образе независимо от того, использует их приложение или нет.
Начиная с конца 2025 года, Camunda перевела свои основные образы контейнеров на усиленные минимальные базовые образы, начиная с версии 8.9 с бэкпортом для 8.8 и 8.7. По результатам измерения с помощью сканера с открытым исходным кодом Grype, этот переход устранил 354 известных CVE на базовом уровне и оставил три. В последующие месяцы было обнаружено 147 новых CVE для старых базовых образов, и только три из них затронули усиленные образы, что составляет снижение на 97,9%. Ничего из этого не было достигнуто путем подавления результатов или изменения настроек сканера, как показывает полная разбивка.
Camunda 8.10 идет дальше. Оркестрационный кластер (Orchestration Cluster), который выполняет ваши процессы, теперь поставляется только в виде одного унифицированного образа, а отдельные образы компонентов уходят в прошлое, поэтому теперь есть только один артефакт для сканирования и отслеживания. Этот релиз также завершает отказ от поставляемых в комплекте инфраструктурных образов сторонних разработчиков. В августе 2025 года Bitnami перенесла многие публичные образы в устаревший репозиторий, который больше не получает патчи безопасности. Camunda предложила пропатченные корпоративные образы для PostgreSQL, Elasticsearch и Keycloak в версии 8.8, отключила эти субчарты по умолчанию в 8.9 и удалила их из чарта Helm в 8.10, поэтому каждая из этих служб работает на инфраструктуре, поддерживаемой ее собственным разработчиком.
Релиз также ужесточает настройки по умолчанию. Фильтр секретов коннекторов теперь работает в строгом режиме «из коробки», поэтому коннектор разрешает секрет только в том поле, которое объявило его во время моделирования. Аутентификация для Orchestration Cluster, Camunda Hub и Optimize теперь проходит через единую общую библиотеку безопасности вместо отдельных стеков идентификации. А устаревшие API компонентов, признанные устаревшими в версии 8.8, удалены и заменены аутентифицированным REST API Orchestration Cluster.
Обнаружение уязвимостей раньше кого бы то ни было
Camunda непрерывно сканирует свой исходный код, зависимости с открытым исходным кодом и выпущенные образы контейнеров, а обновления зависимостей поступают в виде автоматических пулл-реквестов. Мониторинг охватывает каждую выпущенную версию, включая более старые, которые все еще работают в окружениях клиентов.
Тестирование на проникновение добавляет точку зрения злоумышленника. В Центре доверия Camunda (Camunda Trust Center) хранятся управленческие резюме недавних тестов, охватывающих Camunda 8, коннекторы, инфраструктуру SaaS (Software as a Service) и функции искусственного интеллекта, среди прочего.
Внешние отчеты получают такое же внимание. Исследователи и клиенты могут отправить тикет с отчетом о безопасности в Jira компании Camunda, который виден только автору отчета и сотрудникам Camunda, как описано на странице безопасности Camunda.
Команда информационной безопасности Camunda не стала ждать, пока сканеры или сторонние исследователи найдут следующий изъян. В 2026 году она по собственной инициативе начала проводить проверки безопасности с помощью ИИ для собственного кода Camunda. Модели проверяют исходный код, запускают динамические тесты и пишут концептуальные прототипы (PoC), в то время как инженеры по безопасности определяют объем каждой проверки, проверяют каждую находку и решают, что передать разработчикам.
Инженеры также тестируют раньше. Проверка уязвимостей зависимостей запускается при создании пулл-реквестов, поэтому изменение, которое подтягивает библиотеку с известной уязвимостью, помечается до того, как оно будет объединено, и команды могут привлечь отдел информационной безопасности еще на этапе создания функции. Исходный код Camunda является публичным, и любой, у кого есть мощная модель, может искать в нем уязвимости. Цель состоит в том, чтобы найти их первыми — до релиза, а не после него.
Отделение важных уязвимостей от остальных
CVE в библиотеке не делает Camunda уязвимой через нее. Часто уязвимый код никогда не выполняется или выполняется только в конфигурации, которую вы не используете. Каждый отчет проходит анализ первопричин и оценку реального риска и воздействия до того, как ему присваивается приоритет. Модели теперь помогают составлять такие оценки, а инженер по безопасности проверяет каждую из них до того, как она попадет к клиенту.
Вы можете увидеть эту оценку в уведомлениях. Когда в сентябре Camunda исправила две уязвимости Eclipse Jetty в Optimize, в уведомлении было указано, что конфигурация Optimize по умолчанию не была уязвима для одной из них, поскольку она применялась только при явно включенном HTTP/2. Уведомление о FEEL четко разъясняло, какие именно разрешения понадобятся злоумышленнику. Благодаря таким деталям ваша команда безопасности может ранжировать находку за считанные минуты вместо того, чтобы начинать расследование.
Когда ваш собственный сканер что-то обнаруживает, начните со сканирования текущего патч-релиза, так как многие уязвимости в старых сборках уже исправлены. Затем отправьте отчет о сканировании в службу поддержки Camunda вместе с используемой вами версией. Команда безопасности Camunda оценивает каждую находку и сообщает вам, влияет ли она на Camunda и когда ждать исправления.
Исправления для каждой поддерживаемой версии
Корпоративные клиенты получают 18 месяцев стандартной поддержки для каждого минорного релиза, что охватывает как минимум три последних минорных версии. Политика релизов Camunda нацелена на выпуск патча каждый месяц для каждой поддерживаемой версии, включая исправления безопасности, а срочные исправления выпускаются вне этого цикла при необходимости. Пользователи сообщества получают исправления в следующем альфа- или минорном релизе. Мы проактивно сканируем CVE в версиях, находящихся на расширенной поддержке (ESUP), и выпускаем уведомления о безопасности, если они затронуты. В случае, если клиент сообщает об уязвимости, Camunda рассматривает ее как баг в соответствии с уровнями обслуживания, согласованными в контракте этого клиента.
То, как исправление доставляется вам, зависит от того, как вы используете Camunda. В Camunda 8 SaaS компания Camunda сама исправляет парк систем. В случае с уязвимостью в FEEL каждый кластер SaaS на любой поддерживаемой версии был обновлен 12 и 13 сентября, а публичное уведомление последовало 21 сентября, как только патч-релизы для Self-Managed были готовы. Для критических проблем Camunda может обновлять кластеры SaaS немедленно, без предварительного уведомления. При включенных автообновлениях плановые патч-релизы попадают в ваши кластеры без каких-либо действий с вашей стороны.
В Self-Managed ваша команда самостоятельно применяет исправления, что делает своевременное обновление до поддерживаемой версии самым эффективным средством обеспечения безопасности, находящимся в вашем распоряжении. Исправление уязвимости FEEL было выпущено для версий 8.9, 8.8 и 8.7. Версии, вышедшие за пределы периода поддержки, остаются уязвимыми.
Прозрачность, на которую можно опираться
На странице безопасности Camunda четко сформулирована главная цель: укрепление доверия посредством прозрачности. На практике это означает публикацию открытого уведомления о безопасности сразу после того, как готово исправление или практический обходной путь. В каждом уведомлении указаны затронутые компоненты и версии, исправленные релизы и степень критичности, а также приведена ссылка на CVE или рекомендацию по безопасности GitHub, если таковая существует. RSS-лента доставляет уведомления по мере их публикации, а для Camunda 7 предусмотрена отдельная страница уведомлений.
Для проведения собственного анализа Camunda публикует спецификации состава ПО CycloneDX (SBOM), в которых перечислены все прямые и транзитивные сторонние зависимости для компонентов Camunda 8. Исходный код Camunda 8 и коннекторов находится в открытом доступе на GitHub.
Уверенность, которую можно проверить
Практика создания продуктов является частью корпоративной программы безопасности, которую проверяют независимые аудиторы. Компания Camunda имеет сертификаты ISO 27001 и ISO 27018, а также отчет по стандарту SOC 2 Type II для Camunda 8 SaaS. При условии подписания соглашения о неразглашении (NDA) Центр доверия (Trust Center) также предоставляет процедуру управления уязвимостями, политику разработки программного обеспечения, сводки учений по реагированию на инциденты, результаты тестирования непрерывности бизнеса, модель разделения ответственности для SaaS, а также опросник CAIQ (Consensus Assessments Initiative Questionnaire) от Cloud Security Alliance — стандартный опросник, с которого начинается большинство проверок безопасности.
Безопасность того, что работает на платформе
Установка патчей защищает платформу. Агентам необходимы средства контроля, которые действуют внутри процесса, а не только на уровне запросов. Camunda управляет агентами как извне — в качестве участников сквозного процесса, так и изнутри — с помощью обязательных к исполнению шагов между рассуждениями агента и его действиями. Прежде чем агент вызовет API платежной системы, процесс может потребовать проверки политик или одобрения человека. Camunda автоматически записывает каждое действие и решение, поэтому, когда регулятор спросит, почему произошло то или иное событие, у вас будет ответ.
Поскольку компании перестраивают свои процессы с учетом ИИ, команды безопасности также хотят знать, что платформа позволяет делать ИИ-агентам. Согласно отчету 2026 Camunda State of Agentic Orchestration and Automation Report, 71% организаций используют ИИ-агентов, однако в прошлом году до стадии промышленной эксплуатации дошло лишь 11% сценариев использования. Чтобы перевести остальные сценарии в production, необходимо ответить на вопросы команды безопасности о том, к чему эти агенты имеют доступ.
Camunda дает ответы на эти вопросы на уровне самого процесса. Внешняя оркестрация (вне агента) координирует действия агентов, людей и систем в рамках сквозного процесса. Внутренняя оркестрация (внутри агента) добавляет обязательные шаги между рассуждениями агента и его действиями, поэтому перед вызовом платежного API процесс может запросить проверку политик или подтверждение человека. Camunda автоматически фиксирует каждое действие и решение, что предоставляет аудиторам ту же цепочку доказательств для агентов, которой они ожидают и для остального бизнеса.
Количество уязвимостей CVE будет продолжать расти. Оценивайте вендора по тому, какую часть этого информационного шума он устраняет до того, как она дойдет до вас, и по тому, как быстро он закрывает оставшиеся проблемы. Готовы к оркестрации? Начните проверку с Центра доверия Camunda, а любые вопросы, оставшиеся без ответа, задайте своей команде по работе с клиентами Camunda.
