1. Введение

1.1 Назначение платформы

Monolit — отечественная ASOC-платформа, предназначенная для организации и автоматизации процесса безопасной разработки программного обеспечения. Платформа обеспечивает выполнение технических требований ГОСТ Р 56939-2024 к анализу качества кода, позволяя проводить статический анализ исходного кода (SAST), анализ зависимостей (SCA), поиск секретов, анализ конфигураций и проверку соблюдения правил кодирования.

1.2 Область применения

Платформа предназначена для корпоративной разработки и сопровождения программных продуктов в организациях, внедряющих практики DevSecOps. Использование платформы позволяет выполнить требования ГОСТ Р 56939-2024 и Приказа ФСТЭК РФ № 117.

1.3 Терминология и сокращения

Термин	Определение
ASOC	Application Security Orchestration and Correlation — оркестрация и корреляция безопасности приложений
SAST	Static Application Security Testing — статический анализ безопасности приложений
SCA	Software Composition Analysis — анализ состава программного обеспечения (зависимостей)
CWE	Common Weakness Enumeration — общий перечень уязвимостей
OWASP	Open Web Application Security Project — открытый проект по безопасности веб-приложений
CI/CD	Continuous Integration / Continuous Delivery — непрерывная интеграция и доставка
VCS	Version Control System — система контроля версий

---

2. Функциональные возможности

2.1 Управление приложениями

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

Для каждого приложения доступна гибкая настройка параметров сканирования. Пользователь может задать минимальный уровень критичности для регистрации SAST-сработок, а также указать общий список glob-паттернов путей (exclude_patterns), которые исключаются из всех типов сканирования (SAST, SCA, Secret, Config, Linters). Поле использует синтаксис pathlib.Path.glob() (*, **, ?, [abc]); валидация выполняется при сохранении настроек. Новое значение применяется при следующем запуске сканирования.

Приложение может быть привязано к репозиторию GitLab, GitHub, Gitea или Bitbucket Data Center / Server для автоматического получения исходного кода. Для работы в изолированных средах без доступа к внешним сетям предусмотрен offline-режим.

2.2 Управление ревизиями исходного кода

Ревизия — версия исходного кода приложения, загруженная для анализа. Платформа поддерживает несколько способов загрузки кода: загрузка ZIP-архива через веб-интерфейс, загрузка через программный интерфейс (API), а также автоматическое получение кода из GitLab, GitHub, Gitea или Bitbucket Data Center / Server по указанной ветке репозитория.

Для каждой ревизии сохраняется контрольная сумма и размер файла, что позволяет отслеживать изменения и обеспечивает воспроизводимость результатов анализа. История ревизий доступна для просмотра, и любую ранее загруженную версию кода можно повторно проанализировать.

2.3 Процесс сканирования

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

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

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

Платформа поддерживает два режима работы: online-режим с доступом к внешним базам уязвимостей (NVD) для получения актуальной информации о CVE, и offline-режим для изолированных сред, где анализ выполняется с использованием локальных баз правил.

2.4 Добавление уязвимостей вне сканирования

В дополнение к автоматическим сканерам Monolit поддерживает добавление уязвимостей вручную и импорт результатов внешних инструментов в формате SARIF (Static Analysis Results Interchange Format).

Ручное добавление. Пользователи с ролью «Инженер ИБ» или «Гл. Инженер ИБ» могут зарегистрировать уязвимость напрямую через интерфейс приложения, указав описание, критичность, тип, путь к файлу, фрагмент кода, идентификаторы CWE/OWASP и параметры impact/likelihood/confidence. Это применяется, когда уязвимость найдена в ручном аудите или получена из внешнего источника без SARIF.

Импорт SARIF. Поддерживается загрузка JSON-файла SARIF v2.1.0, выгруженного любым совместимым сканером. Платформа обрабатывает результаты с уровнями error и warning, пропуская подавленные и неактуальные находки (open, pass). Импортированные уязвимости проходят дедупликацию и обогащаются полями, отсутствующими в SARIF (категория CWE, ML-оценка, классификация по OWASP).

2.5 Управление уязвимостями

Каждая обнаруженная уязвимость представлена в виде карточки, содержащей полную информацию о проблеме: описание, классификацию по CWE и OWASP, источник обнаружения (название сканера), сработавшее правило, путь к файлу с указанием номеров строк и столбцов, фрагмент исходного кода, а также уровень критичности и оценку достоверности от ML-модели.

Платформа использует единый статус жизненного цикла уязвимости с ограниченной матрицей переходов (FSM): от первичного «На проверке» через промежуточные («Подтверждена», «В работе», «Требует проверки», «Отклонили правки») к конечным состояниям («Исправлена», «Ложное срабатывание», «Риск принят», «Дубликат»). Допустимые переходы определены ролевой моделью; часть переходов требует обязательного обоснования.

Все события по уязвимости — обнаружение сканером, изменения статуса и критичности — фиксируются в журнале активности с привязкой к пользователю и времени. Журнал отделён от пользовательских комментариев: комментарии служат для свободного обсуждения, активность — машинная лента событий, доступная в отдельной вкладке карточки уязвимости.

Шкала критичности содержит шесть уровней: критический (Critical), высокий (High), средний (Medium), низкий (Low), «Неопределён» (Undefined) и информационный (Info). Уровень «Неопределён» платформа присваивает находкам, для которых сканер не вернул распознаваемое значение критичности. На шкале он стоит выше информационного и ниже низкого, в том числе когда используется как порог минимальной критичности.

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

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

2.6 Аналитика и отчётность

Платформа предоставляет дашборд с агрегированной статистикой: распределение уязвимостей по уровням критичности и статусам, недельная динамика изменений и статистика триажа (соотношение истинных и ложных срабатываний). Аналитика доступна как по всем приложениям организации, так и по каждому приложению в отдельности (графики распределения уязвимостей, триаж, исправленные уязвимости, оценка по критичности).

Платформа позволяет формировать отчёты в формате PDF по выбранному приложению. При создании отчёта задаются фильтры уязвимостей: по статусу анализа, статусу устранения и уровню критичности. Сформированные отчёты сохраняются в списке; доступны скачивание и удаление.

2.7 Интеллектуальная оценка достоверности

Платформа поддерживает подключение AI-сервиса, который автоматически оценивает достоверность обнаруженных уязвимостей, помогая отличить реальные проблемы безопасности (True Positive) от ложных срабатываний (False Positive). AI-сервис подключается как отдельная интеграция (внешняя или собственная) и привязывается к приложению — это позволяет использовать разные модели для разных приложений и разворачивать модель внутри контура организации.

По каждой подходящей уязвимости AI-интеграция возвращает три результата: вердикт — True Positive (реальная уязвимость) или False Positive (ложное срабатывание), текстовый анализ и рекомендации по устранению. Вердикт и развёрнутый анализ доступны в карточке уязвимости; в списке уязвимостей вердикт отображается отдельным столбцом, и по нему можно фильтровать находки (TP / FP).

На анализ отправляются уязвимости, для которых рядом есть исходный код, — находки типов SAST и Secret. Модель получает извлечённый фрагмент функции вокруг места срабатывания, название сработавшего правила, тип уязвимости по классификации CWE и метаданные находки. Анализ выполняется асинхронно и устойчив к сбоям: при временной недоступности AI-сервиса обработка повторяется автоматически, а остальные результаты сканирования сохраняются без задержек. Если для приложения активная AI-интеграция не выбрана, уязвимости сохраняются без вердикта.

2.8 Управление соответствием ГОСТ Р 56939-2024

Платформа включает встроенный модуль управления соответствием, позволяющий отслеживать выполнение требований ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения».

Реестр требований. В модуль предзагружены 25 требований (коды 5.1–5.25), сгруппированных по шести этапам жизненного цикла безопасной разработки: планирование и управление, проектирование, разработка, анализ безопасности, тестирование, выпуск и эксплуатация.

Статусы соответствия. Каждое требование может иметь один из четырёх статусов: «Выполнено», «Частично», «Не выполнено», «Неприменимо». Начальный статус по умолчанию — «Не выполнено».

Управление статусом. Статус устанавливается вручную через механизм ручного override: пользователь выбирает новый статус и обязательно указывает причину изменения. Все ручные изменения статуса фиксируются в журнале override'ов с привязкой к пользователю, дате и причине.

Свидетельства соответствия. К каждому требованию можно прикрепить произвольное количество свидетельств трёх типов: загруженный документ (файл в объектное хранилище), гиперссылка, текстовый комментарий.

Дашборд. Сводная страница отображает общий процент соответствия (Выполнено / применимые требования), распределение по статусам с визуальной полосой и карточки всех требований, сгруппированные по этапам разработки.

---

3. Поддерживаемые инструменты анализа

3.1 SAST (Static Application Security Testing)

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

Сканер	Языки	Описание
Semgrep	C, C++, C#, Go, Java, JavaScript, JSX, Kotlin, PHP, Pascal, Fortran, Python, Ruby, Rust, Swift, TypeScript, ASP.NET	Универсальный паттерн-ориентированный анализатор
Bandit	Python	Специализированный анализатор безопасности Python
Bearer	Go, Java, JavaScript, PHP, Python, Ruby, TypeScript	Анализатор безопасности и приватности данных
CodeQL	C#, Java, C/C++, Python, JavaScript/TypeScript, Go, Ruby, Swift	Семантический анализатор от GitHub
Gosec	Go	Специализированный анализатор для Go
MobSFScan	Java, Kotlin, Objective-C, Swift	Анализатор для мобильной разработки
PMD	Java, JavaScript	Анализатор качества и безопасности кода
ABAP Code Scanner	ABAP	Анализатор для SAP ABAP

Опционально поддерживается интеграция с внешними сканерами PT AI (Positive Technologies Application Inspector) и Solar appScreener.

3.2 SCA (Software Composition Analysis)

Анализ зависимостей на наличие известных уязвимостей.

Сканер	Назначение
Trivy	Анализ зависимостей, контейнеров, IaC-конфигураций
OWASP Dependency-Check	Анализ JAR-файлов и зависимостей Java-проектов

Опционально поддерживается интеграция с внешними сканерами CodeScoring и Solar appScreener.

3.3 Secret Scanning

Поиск секретов, токенов и ключей в исходном коде.

Сканер	Назначение
TruffleHog	Поиск секретов с высокой энтропией и по паттернам
Trivy	Поиск секретов в коде и конфигурациях

3.4 Config Scanning

Анализ конфигурационных файлов на уязвимости и некорректные настройки.

Сканер	Назначение
Trivy	Анализ Dockerfile, Kubernetes YAML, Terraform и других конфигураций

3.5 Linters

Проверка качества кода и соблюдения правил кодирования.

Линтер	Язык
Ruff	Python
golangci-lint	Go
PMD	Java, JavaScript
PHPMD	PHP

3.6 DAST (Dynamic Application Security Testing)

Динамическое тестирование безопасности работающего приложения по URL.

Сканер	Назначение
OWASP ZAP	Автоматизированное сканирование веб-приложений: обнаружение инъекций, XSS, мисконфигураций и других уязвимостей через HTTP-запросы

Опционально поддерживается интеграция с внешним сканером Solar appScreener.

---

4. Поддерживаемые языки программирования

Платформа поддерживает 19 языков программирования с различным набором типов анализа.

Язык	SAST	SCA	Linters	Secret	Config
ABAP	ABAP Code Scanner	—	—	TruffleHog, Trivy	Trivy
ASP.NET	Semgrep	—	—	TruffleHog, Trivy	Trivy
C	Semgrep, CodeQL	—	—	TruffleHog, Trivy	Trivy
C#	Semgrep, CodeQL	—	—	TruffleHog, Trivy	Trivy
C++	Semgrep, CodeQL	—	—	TruffleHog, Trivy	Trivy
Fortran	Semgrep	—	—	TruffleHog, Trivy	Trivy
Go	Semgrep, Gosec, Bearer, CodeQL	Trivy	golangci-lint	TruffleHog, Trivy	Trivy
Java	Semgrep, MobSFScan, Bearer, PMD, CodeQL	OWASP DC, Trivy	PMD	TruffleHog, Trivy	Trivy
JavaScript	Semgrep, Bearer, PMD, CodeQL	Trivy	PMD	TruffleHog, Trivy	Trivy
JSX	Semgrep	Trivy	—	TruffleHog, Trivy	Trivy
Kotlin	Semgrep, MobSFScan	Trivy	—	TruffleHog, Trivy	Trivy
Objective-C	MobSFScan	—	—	TruffleHog, Trivy	Trivy
Pascal	Semgrep	—	—	TruffleHog, Trivy	Trivy
PHP	Semgrep, Bearer	Trivy	PHPMD	TruffleHog, Trivy	Trivy
Python	Semgrep, Bandit, Bearer, CodeQL	Trivy	Ruff	TruffleHog, Trivy	Trivy
Ruby	Semgrep, Bearer, CodeQL	Trivy	—	TruffleHog, Trivy	Trivy
Rust	Semgrep	Trivy	—	TruffleHog, Trivy	Trivy
Swift	Semgrep, MobSFScan, CodeQL	—	—	TruffleHog, Trivy	Trivy
TypeScript	Semgrep, Bearer, CodeQL	Trivy	—	TruffleHog, Trivy	Trivy

Trivy и TruffleHog работают для всех языков программирования.

Solar appScreener доступен для приложений на любом языке. Набор языков, которые он анализирует, определяется лицензией сканера.

---

5. Веб-интерфейс

5.1 Основные разделы

Раздел	Что в нём делают
Аналитика	Дашборд с общей статистикой по всем приложениям организации
Приложения	Список приложений: создание новых, управление существующими
Уязвимости	Глобальный список уязвимостей со всех приложений, фильтрация и поиск
Рабочая зона	Работа с уязвимостями конкретного выбранного приложения
Отчёты	Создание PDF-отчётов с фильтрами, список отчётов, отмена генерации, скачивание и удаление
Соответствие	Реестр 25 требований ГОСТ Р 56939-2024: статусы, свидетельства, журнал изменений
Инструменты	Подключения к системам контроля версий (GitLab, GitHub, Gitea, Bitbucket), внешние сканеры, AI- и Jira-интеграции
Пользователи	Учётные записи и роли
Настройки приложения	Параметры сканирования конкретного приложения

5.2 Работа с приложениями

Список приложений отображается в табличном виде с индикаторами статуса сканирования. Для каждого приложения показывается количество уязвимостей по уровням критичности, индикатор прогресса текущего сканирования и быстрый переход к списку уязвимостей.

5.3 Работа с уязвимостями

Уязвимости представлены в виде таблицы с возможностью сортировки по любому столбцу. Доступна многокритериальная фильтрация по критичности, статусу жизненного цикла, типу (SAST, SCA, DAST, Linters, Secret, Config) и принадлежности к приложению. Поддерживается полнотекстовый поиск по описанию и другим полям.

При выборе уязвимости открывается карточка с тремя вкладками: «Описание», «Комментарии» и «Активность». В описании пользователь может изменить критичность и выполнить переход статуса по матрице допустимых переходов (для ряда переходов запрашивается обоснование). Все изменения автоматически фиксируются во вкладке «Активность» с указанием автора и времени. Поддерживаются массовые операции: массовый перевод статуса с проверкой допустимости перехода и массовое изменение критичности.

5.4 Настройки сканирования

В настройках приложения можно выбрать источник кода (загрузка ZIP-архива или получение из GitLab, GitHub, Gitea, Bitbucket Data Center / Server), задать минимальную критичность SAST и список общих исключений путей (glob-паттерны, применяемые ко всем типам сканирования).

5.5 Дополнительные возможности

Интерфейс поддерживает переключение между светлой и тёмной темой оформления, локализацию на русский и английский языки, выбор языка отчёта (RU/EN) при формировании PDF, а также генерацию API-токенов для интеграции с внешними системами.

---

6. Интеграционные возможности

6.1 Интеграция с CI/CD

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

Имеются готовые интеграции для GitLab CI и Jenkins. Благодаря универсальному API платформа может быть интегрирована с любой другой системой CI/CD.

6.2 Интеграция с системами контроля версий

Платформа поддерживает интеграцию со следующими VCS-провайдерами: GitLab, GitHub, Gitea, Bitbucket (Data Center / Server). Подключение выполняется по URL хостинга и Personal Access Token через раздел «Инструменты». После настройки пользователь может просматривать список репозиториев и веток, привязывать приложения к конкретным репозиториям и автоматически получать код для сканирования. Для каждого типа провайдера создаётся отдельное именованное подключение; одновременно можно использовать несколько подключений разных типов.

6.3 Интеграция с внешними сканерами

Помимо встроенных инструментов анализа, платформа поддерживает интеграцию с внешними сканерами: PT AI (Positive Technologies Application Inspector) для SAST, CodeScoring для SCA, Solar appScreener для SAST, SCA и DAST. Код отправляется на анализ во внешний сканер, а результаты автоматически импортируются и нормализуются наравне с результатами встроенных инструментов.

Solar appScreener подключается одной интеграцией и покрывает три типа сканирования: SAST и SCA выполняются по загруженному архиву исходного кода, DAST — по URL приложения из его настроек. Проект во внешнем сканере создаётся под именем SDL-<идентификатор приложения> и переиспользуется при повторных сканированиях, поэтому дубли проектов не появляются. Правила анализа настраиваются в самом appScreener; платформа запускает сканирование с текущими настройками проекта.

6.4 Интеграция AI-сервисов

Платформа поддерживает подключение внешних или собственных AI-сервисов для оценки достоверности уязвимостей. Подключение выполняется в разделе «Инструменты» по URL сервиса (или паре IP и порт); при сохранении проверяется доступность сервиса. Одну интеграцию можно привязать к нескольким приложениям, при этом у каждого приложения используется одна активная интеграция. Платформа отправляет сервису находки страницами в формате SARIF 2.1.0 и забирает по каждой находке вердикт TP/FP, текстовый анализ и рекомендации, когда задача готова. Такая модель позволяет разворачивать AI-сервис внутри контура организации, обновлять или заменять модель без изменения платформы и использовать разные модели для разных приложений.

6.5 HTTP API

Платформа предоставляет полнофункциональный REST API для автоматизации всех операций: управления приложениями и ревизиями, запуска сканирований, получения и обработки уязвимостей, работы с комментариями и интеграциями, а также работы с отчётами. API документирован в формате OpenAPI/Swagger.

Для аутентификации используется OAuth 2.0 с выдачей JWT-токена. Для интеграций с внешними системами можно сгенерировать долгоживущий API-токен.

6.6 Интеграция с системами управления задачами (Jira)

Платформа поддерживает интеграцию с трекером задач Jira для переноса жизненного цикла уязвимостей во внешнюю систему. Подключение настраивается в разделе «Инструменты» по URL сервера и персональному токену доступа (PAT); при создании проверяется сетевая доступность Jira и корректность прав токена. Одну интеграцию можно привязать к нескольким приложениям, указав для каждого проект Jira и тип задачи. После включения баг-трекинга тикеты создаются вручную из карточки уязвимости, изменения полей и комментарии синхронизируются с трекером автоматически; в карточке уязвимости отображается ссылка на тикет.

---

7. Безопасность и доступ

7.1 Аутентификация и авторизация

Доступ к платформе защищён аутентификацией по протоколу OAuth 2.0 с выдачей JWT-токена. Платформа использует двухуровневую модель управления доступом: тип учётной записи на уровне платформы и роль в рамках конкретного приложения.

Типы учётных записей.

Тип	Описание
Суперадминистратор (super_admin)	Полный доступ ко всем функциям, включая управление пользователями, лицензией и настройками платформы
Администратор (admin)	Управление приложениями и их участниками, настройка интеграций, работа с отчётами и уязвимостями
Пользователь (regular)	Доступ к приложениям, в которых состоит участником; возможности ограничены ролью в каждом приложении

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

Роль	Описание
Гл. Инженер ИБ (super_security_engineer)	Полные права инженера ИБ + возможность совершать любые переходы по жизненному циклу уязвимостей в обход стандартной матрицы (FSM bypass)
Инженер ИБ (security_engineer)	Управление сканированиями и уязвимостями, формирование отчётов, изменение статуса уязвимостей в рамках разрешённых переходов
Разработчик (developer)	Просмотр приложения и уязвимостей; разрешены переходы статуса в зоне ответственности разработки
Аудитор (auditor)	Просмотр приложения, уязвимостей и отчётов; полное управление отчётами

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

7.2 Защита данных

Пароли пользователей хранятся в виде криптографических хешей. Данные между клиентом и сервером передаются по HTTPS. Загруженный исходный код хранится в изолированном объектном хранилище.

7.3 Лицензирование

Платформа использует лицензирование на основе JWT-токена. Лицензия определяет срок действия, максимальное количество приложений и доступные функции. Импорт лицензии выполняется через веб-интерфейс или API.

---

8. Варианты развёртывания

8.1 Docker Compose

Основной способ развёртывания. Все компоненты платформы поставляются в виде Docker-контейнеров и запускаются с помощью единого файла конфигурации. Данные сохраняются в персистентных томах.

Минимальные требования: Docker Engine 20.10 или выше, Docker Compose v2 или выше, 8 ГБ оперативной памяти, 50 ГБ дискового пространства.

8.2 Kubernetes / Helm

Масштабируемый вариант развёртывания для высоконагруженных сред и крупных организаций. Установка автоматизирована с помощью Helm Chart. Поддерживается горизонтальное масштабирование компонентов сканирования, интеграция с Kubernetes Secrets для управления секретами и настройка Ingress для внешнего доступа.

8.3 Изолированные среды (Air-gap)

Платформа поддерживает развёртывание в полностью изолированных средах без доступа к интернету. Все образы поставляются из приватного Docker Registry организации. Режим offline-сканирования позволяет выполнять анализ с использованием локальных баз правил и уязвимостей без обращения к внешним источникам.

8.4 SaaS

Платформа доступна в режиме SaaS (Software as a Service). В этом случае инфраструктура размещается и обслуживается поставщиком, а заказчик получает доступ к платформе через веб-интерфейс и API без необходимости развёртывания собственных серверов. Режим SaaS подходит для организаций, которые хотят начать использовать платформу без затрат на инфраструктуру и администрирование.

---

9. Технические характеристики

9.1 Требования к системе

Параметр	Значение
Операционная система	Linux (Ubuntu 24.04.1 LTS или выше)
Процессор	4 ядра
Оперативная память	8 ГБ
Свободное место на диске	50 ГБ
Сетевое подключение	Требуется для установки и получения обновлений

9.2 Масштабирование

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