Архитектура
Микросервисы, распределение задач по воркерам, сканеры в контейнерах и варианты развёртывания.
ScanSuite построен на микросервисах. Каждый компонент работает самостоятельно, в собственном контейнере, поэтому при росте нагрузки достаточно добавить нужные компоненты, не трогая остальные.
Задачи сканирования распределяются по пулу рабочих узлов (воркеров) и выполняются параллельно. Свободный воркер берёт из очереди следующую задачу и запускает для неё один или несколько сканеров в изолированных Docker-контейнерах. Чтобы очередь разбиралась быстрее, добавьте воркеров: сама платформа число одновременных сканирований не ограничивает.
Результаты AI-сканирований ScanSuite разбирает, приводит к единому виду, очищает от дубликатов и сохраняет в разделе «Уязвимости». Там уязвимости разбирают, назначают ответственного и ведут до закрытия. Отчёты о сканировании можно скачать. Большинство классических сканеров выгружает найденное только в эти отчёты и в DefectDojo, поэтому, если вы ими пользуетесь, DefectDojo рекомендуется подключить. Исключения — Nessus, чьи уязвимости тоже попадают в «Уязвимости», а также Semgrep, KICS, Trivy, Nuclei, ZAP, Wapiti, SSLyze, Dastardly, Acunetix и OpenVAS: их уязвимости тоже сохраняются там, если команда не выключила это в своих настройках.
К платформе можно подключить внешние инфраструктурные сканеры. Тогда все проверки безопасности вы запускаете и контролируете из одной консоли, а не из пяти разных интерфейсов.
Топология развёртывания
Серверные компоненты можно развернуть в облаке, on-premise или в смешанной среде — как удобнее для вашей инфраструктуры. Пример развёртывания:
Здесь ScanSuite работает на одном сервере (Сервер 1). Воркеры ScanSuite ведут каждое сканирование: запускают локальные сканеры, входящие в платформу, управляют внешними сканерами (Nessus, OpenVAS, Acunetix) по HTTPS и обращаются к облачному или локальному LLM-провайдеру, который выполняет AI-анализ. Внешние сканеры и LLM-провайдер могут работать на том же узле, на отдельных серверах или вообще за пределами площадки — главное, чтобы они были доступны по HTTPS. Код и данные об уязвимостях при этом не покидают периметр.
DefectDojo на схеме стоит на Сервере 1. Он нужен прежде всего для классических сканеров: без него бо́льшая часть найденного ими остаётся только в отчётах. DefectDojo можно развернуть на том же узле или на отдельном сервере, доступном ScanSuite по HTTPS.
ServiceNow на схеме намеренно не связан с платформой по сети: ScanSuite к нему не подключается. Уязвимости уходят в ServiceNow файлом ServiceNow XLSX, который вы загружаете вручную, а статусы из ServiceNow возвращаются тоже файлом. Учётные данные нигде не хранятся, порты не открываются, а данные покидают периметр только по действию человека. Поэтому такую интеграцию согласуют даже там, где исходящие вызовы API не разрешат никогда.
По умолчанию PostgreSQL работает в контейнере самой установки. Для промышленной эксплуатации разверните отдельный кластер PostgreSQL и подключите к нему ScanSuite, а также DefectDojo, если вы им пользуетесь. Подключение ScanSuite задают параметры PS_DATABASE_* в файле .env, см. Параметры настройки и сервисы.
Ту же архитектуру можно развернуть и в Google Cloud, где каждому компоненту соответствует управляемый сервис. Консоль и воркеры работают в Cloud Run (или GKE), роль PostgreSQL выполняет Cloud SQL, очередей Redis — Memorystore. Артефакты сканирования хранятся в Cloud Storage, учётные данные — в Secret Manager, образы контейнеров загружаются из Artifact Registry. AI-анализ выполняет Vertex AI, внешние сканеры и DefectDojo доступны по HTTPS. Docker здесь нет, поэтому сканеры в контейнерах не запускаются: такое развёртывание выполняет статический анализ силами AI. С ServiceNow по-прежнему нет сетевого соединения: выгрузка и возврат статусов идут файлами. Код и результаты сканирований не выходят за пределы VPC вашего проекта:
В Microsoft Azure та же архитектура работает на Azure Container Apps. Консоль и воркеры оркестрации запущены как приложения Container Apps, а каждое сканирование выполняется отдельным запуском задания Container Apps: он стартует вместе со сканированием и исчезает, когда оно заканчивается. Роль PostgreSQL выполняет Azure Database for PostgreSQL (Flexible Server, доступный только изнутри сети), очередей — Redis. Артефакты сканирования хранятся в Blob Storage, учётные данные — в Key Vault, образы контейнеров загружаются из собственного Container Registry развёртывания. К хранилищу, Key Vault и реестру сервисы обращаются через управляемые удостоверения, без хранимых ключей. AI-анализ может выполнять Azure OpenAI через OpenAI-совместимый интерфейс или любой другой поддерживаемый провайдер. Входной шлюз пропускает только разрешённые вами диапазоны адресов, а код и результаты сканирований не выходят за пределы виртуальной сети группы ресурсов:
Развёртывание в Azure создаётся конфигурацией Terraform из папки azure репозитория установки: одна команда создаёт всё в единой группе ресурсов, другая удаляет. В Container Apps нет Docker, поэтому сканерам, которые работают в собственных контейнерах, нужен Docker-хост. В Azure ScanSuite выполняет статические виды анализа (код, зависимости, инфраструктура как код, секреты и AI-ревью кода), а внешние сканеры остаются доступны по HTTPS.
Развёртывание в Google Cloud создаётся так же, из папки gcp. Как развернуть любое из них, с примерами установки, описано в разделах Установка в Google Cloud и Установка в Microsoft Azure.
Проверено: 2026-09-30