Архитектура

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

Задачи сканирования распределяются по пулу рабочих узлов (воркеров) и идут параллельно — это даёт и скорость, и отказоустойчивость. Каждый свободный воркер динамически забирает задачу и выполняет её, вызывая один или несколько сканеров, работающих в изолированных Docker-контейнерах. Такая архитектура поддерживает неограниченное масштабирование параллельных сканирований, повышая скорость выполнения и стабильность системы.

Результаты сканирования разбираются, приводятся к единому виду, дедуплицируются и сохраняются в собственном разделе ScanSuite «Уязвимости». Там по ним ведут разбор, назначают ответственного и сопровождают до закрытия — учёт дефектов встроен, и сканирования на базе AI полностью ведутся внутри платформы. Отчёты о сканировании доступны для скачивания, а уязвимости, найденные классическими сканерами, можно по желанию экспортировать в DefectDojo для команд, которые уже используют его как баг-трекер.

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

Топология развёртывания

Серверные компоненты можно разворачивать в облаке, on-premise или в гибридных средах, что позволяет подстроиться под разные инфраструктурные требования. На следующей схеме показан пример развёртывания архитектуры ScanSuite:

zoom_inУвеличить

Здесь ScanSuite работает на одном сервере (Сервер 1). Воркеры ScanSuite оркестрируют каждое сканирование: они запускают локальные сканеры, входящие в состав платформы, управляют внешними сканерами (Nessus, OpenVAS, Acunetix) как вызываемыми инструментами по HTTPS и обращаются к облачному или локальному LLM-провайдеру для AI-анализа, стоящего за каждым агентом. Внешние сканеры и LLM-провайдеры могут находиться на том же узле, на отдельных серверах или за пределами площадки — где угодно, куда есть доступ по HTTPS, — при этом ваш код и уязвимости остаются внутри периметра.

Необязательный баг-трекер DefectDojo показан размещённым на Сервере 1. Он не обязателен: всё найденное, включая результаты AI-сканирований, ведётся в собственном разделе «Уязвимости» ScanSuite — но если команда его использует, он может работать на том же узле или на отдельном сервере, доступном ScanSuite по HTTPS.

ServiceNow изображён на схеме без сетевой связи, и в этом весь смысл: ScanSuite к нему никогда не подключается. Уязвимости уходят выгрузкой ServiceNow XLSX, которую вы загружаете вручную, а назначенные в ServiceNow статусы возвращаются файлом, который читает ScanSuite. Учётные данные не хранятся, порты не открываются, и ничто не покидает периметр, пока этого не сделает человек, — именно поэтому такая интеграция применима там, где исходящий вызов API никогда бы не согласовали.

Та же архитектура работает и как облачное развёртывание в Google Cloud, где каждый компонент отображается на управляемый сервис. Консоль и воркеры сканирования работают в Cloud Run (или GKE), опираясь на Cloud SQL для PostgreSQL, Memorystore для очередей Redis, Cloud Storage для артефактов сканирования и Secret Manager для учётных данных, а образы контейнеров поставляются из Artifact Registry. AI-анализ использует Vertex AI в качестве LLM-провайдера, а внешние сканеры и необязательный DefectDojo остаются доступны по HTTPS. ServiceNow вообще не требует соединения: выгрузка уходит файлами таблиц и статусы возвращаются так же — ваш код и результаты сканирований остаются внутри VPC проекта:

zoom_inУвеличить

Сервисы платформы

Установка на одном узле поднимает перечисленные ниже контейнеры. Зная, за что отвечает каждый, проще читать команды просмотра журналов в разделе «Устранение неполадок».