Сервис
SBOM-аудита

Компонентный анализ и лицензионный аудит для процесса разработки безопасного ПО (РБПО): что умеет сервис, как он устроен и как он сделан.

Виталий А. Пиков

Специалист по безопасной разработке ПО · АО МНТЦ МИЭТ · vitaly@pikov.expert

27 мая 2026 г.

Доклад коллегам

Постановка задачи

Зачем нужен сервис

Процесс РБПО · ГОСТ Р 56939-2024

Продукт собирается из вкладов нескольких организаций-соисполнителей; каждая привносит свой набор зависимостей.
Сторонних open-source компонентов — сотни; у каждого свои авторы, версии, лицензии и потенциальные уязвимости.
Свести их вручную по десяткам Excel-таблиц — трудоёмко и ненадёжно: данные расходятся, истории решений теряются.

Что мы хотим получить Единую прослеживаемую картину состава продукта, его лицензионной чистоты и базы для оценки безопасности — с историей и доказательствами по каждому решению.

сотни

сторонних open-source компонентов в продукте

организаций: головной исполнитель + 7 соисполнителей

единый каталог компонентов и лицензий

∞

история и доказательная база решений

Альтернатива, которой мы избегаем У каждого соисполнителя своя таблица. Версии расходятся. Лицензионные оценки не привязаны к компонентам. Доказательность теряется при первой ротации кадров.

👉 Сервис автоматизирует сбор состава, лицензий и базы для оценки безопасности — и даёт единую прослеживаемую картину по всему проекту.

Назначение

Что делает сервис: отвечает на три вопроса

§1 справки по проекту

Вопрос 1 · состав

Из чего собран продукт?

Полный состав компонентов (SBOM) с версиями
Авторы, происхождение, путь в исходном архиве
Контрольная сумма (SHA-256) каждого артефакта
Связь компонент ↔ соисполнитель, кто прислал

Вопрос 2 · лицензии

Чисто ли с лицензиями?

Какие открытые лицензии у компонентов
Нет ли запрещённых или конфликтующих
Юридическое заключение и вердикт
PDF подписанных заключений в каталоге

Вопрос 3 · безопасность

Безопасно ли?

Основа для сопоставления с известными уязвимостями
Координаты компонентов в стандарте CPE
Совместимость с отечественными базами
Готовность к подключению БДУ ФСТЭК

SBOM — что это Software Bill of Materials — опись программных компонентов продукта; как «состав» на упаковке: что и какой версии входит в поставку.

👉 Один сервис закрывает три ключевых вопроса РБПО — состав, лицензии, безопасность — и связывает их между собой.

Возможности

Что умеет сервис

§1 справки · обзор функций

01 · приём данных

Конвейер обработки загрузок

ZIP-выгрузка соисполнителя разбирается автоматически: bom.json + реестр компонентов → база данных.

02 · история

Полная история и неизменяемость данных

Каждая выгрузка — отдельный неизменяемый снимок. Прошлые оценки и заключения не переписываются.

03 · доступ

Ролевая модель и изоляция соисполнителей

Каждый соисполнитель видит только свои компоненты. Каталог лицензий — общий проектный ресурс.

04 · юр. контур

Юридический процесс с вердиктами и PDF

Четыре вердикта, lifecycle заключения, обязательный PDF на «Утверждено», постоянная история комментариев.

05 · риски

Управление рисками компонентов

Светофор по компонентам и лицензиям; решения RiskDecision с эскалацией к руководителю проекта.

06 · динамика

Календарь и сравнение «день к дню»

Видно, что изменилось между выгрузками: новые компоненты, ушедшие версии, новые лицензии.

07 · совместимость

Единый отраслевой SBOM в формате CycloneDX

На выходе — машиночитаемый SBOM проекта в стандарте CycloneDX, который без доработок принимается внешними системами анализа уязвимостей (например, Dependency Track).

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

Как это устроено

Конвейер обработки загрузок

bom.json — первичный источник

Шаг 1 · вход

Архив сборки

ZIP-выгрузка от соисполнителя: исходники + артефакты сборки + два файла-описания.

→

Шаг 2 · первичный источник

bom.json

SBOM (CycloneDX), генерируется инструментом cdxgen.

Шаг 2 · дополнение

SBOM-Registry.xlsx

Реестр из Excel: лицензии, авторы, метод детектирования.

→

Шаг 3 · хранение

База данных с историей

PostgreSQL: журналы только на добавление, нельзя переписать задним числом.

→

Шаг 4 · выход

Единый SBOM CycloneDX

Машиночитаемый отчёт проекта, принимаемый внешними системами анализа уязвимостей.

Происхождение каждого артефакта Для каждой записи сохраняется путь в исходном архиве и контрольная сумма SHA-256. Любой компонент можно найти и проверить «откуда он взялся».

Неизменяемость Загруженная выгрузка — это снимок. Ничего нельзя переписать задним числом; новые данные становятся следующим снимком, прошлые остаются.

👉 Конвейер из четырёх шагов: каждый шаг проверяем, каждый артефакт прослеживается.

Юридический контур

Юридический процесс и вердикты

Lifecycle заключения · обязательный PDF

Четыре вердикта по лицензии

🟢 Безопасно

можно использовать в поставке

🟡 Риск

с условиями / атрибуцией

🔴 Небезопасно

в поставку нельзя

⚪ Не оценено

ждёт решения юриста

Жизненный цикл юридического заключения

Шаг 1

Черновик

Юрист готовит оценку, комментарий, прикладывает материалы. В каталоге — предварительный вердикт.

→

Шаг 2 · финальный

Утверждено

Обязательно приложение PDF юридического заключения. С этого момента вердикт — финальный.

→

Шаг 3 · опц.

Заменено

Когда выходит новая редакция лицензии или меняются обстоятельства. Старая запись и PDF не удаляются.

Worst-verdict-wins Вердикт компонента = худший из вердиктов его лицензий. Один 🔴 у любой из лицензий компонента делает 🔴 весь компонент.

Изоляция Каждый соисполнитель видит только свои компоненты. Каталог лицензий — общий проектный ресурс; одно решение юриста работает на весь проект.

👉 Решение юриста фиксируется с документом и историей — это и есть доказательная лицензионная чистота.

Как сделан сервис

Технологический стек

§2 справки по проекту

Слой	Технологии
Бэкенд	`Python` `FastAPI` `SQLAlchemy` `Pydantic` `Alembic`
База данных	`PostgreSQL`
Фронтенд	`TypeScript` `Next.js` `React` `Tailwind CSS`
Аутентификация	`JWT` `bcrypt` `защита от перебора`
Работа с SBOM	`CycloneDX` `PURL` `CPE 2.3` `SPDX`
Контроль качества	`pytest` `Vitest` `статический анализ` `типизированный клиент API`
Инфраструктура	`Docker` `развёртывание на двух серверах`

Восемь языков в проекте Python · TypeScript · JavaScript · SQL · HTML · CSS · Bash · PowerShell

Что значат термины CycloneDX — открытый формат SBOM. PURL — единая координата пакета. CPE 2.3 — стандарт идентификации продукта для уязвимостей. SPDX — стандарт идентификаторов лицензий.

👉 Стек из проверенных открытых технологий; на каждом слое — отраслевые стандарты, а не вендорные привязки.

Как строится сервис

Инженерные принципы

§3 справки по проекту

Принцип 1

Документация-первой

Сначала ТЗ → схема БД и контракт API → только потом код. Никакой кодинг «вслепую».

Принцип 2

Архитектурные решения фиксируются

Каждое значимое решение — отдельный документ (ADR) с контекстом, альтернативами и последствиями.

Принцип 3

Контрактная типизация

Бэкенд и фронтенд не расходятся: типы API генерируются автоматически, расхождения ловит компилятор.

Принцип 4

Неизменяемость данных

Журналы только на добавление; снимки выгрузок не переписываются — история всегда полная.

Принцип 5

Один коммит = одно изменение

Каждый коммит представляет ровно одно логическое изменение — историю легко читать и откатывать.

Принцип 6

Контракт API — источник истины

OpenAPI-описание — единственная официальная версия. И клиент, и тесты собираются из него.

Главный эффект Сервис собирается воспроизводимо: новый разработчик читает ТЗ и ADR — и понимает не только «что делать», но и «почему именно так».

👉 Документация — это не побочный продукт, а несущая конструкция проекта.

Организация работ

Роли и цикл одного инкремента

§3 справки · разделение обязанностей

Роль	Чем занимается
Архитектор и руководитель Виталий Пиков	Архитектура, ключевые решения (ADR), приоритеты, приёмка инкрементов.
Разработчик	Код, ТЗ, миграции базы данных, автотесты по каждому инкременту.
Независимый аудитор кода	Проверяет каждый инкремент; не правит код сам, выдаёт вердикт «готово / на доработку».
Тестировщик E2E	Проверка готовых сценариев в реальном браузере: пользовательские пути, регрессии, граничные случаи.

Цикл одного инкремента

Техзадание / ADR

формулируем, что и зачем делаем

→

Ревью замысла

проверяем подход до кода

→

Реализация + тесты

код, миграции, автотесты

→

Независимое ревью

аудитор: «готово / на доработку»

→

E2E в браузере

сценарии глазами пользователя

→

Развёртывание

обновление двух серверов

👉 Тот, кто пишет, и тот, кто проверяет, — разделены. Это снимает «слепые пятна» и сохраняет качество на каждом инкременте.

Метрики проекта

Темп разработки и объём кода

§4 справки по проекту

Темп разработки

Всего коммитов587

Средняя скорость≈ 45 / день

Пиковый день92 коммита

Объём кода

Исходный код, всего≈ 79 500 строк

— Python≈ 49 900

— TypeScript / React≈ 19 400

— Прочее≈ 10 000

Автотесты

Автотесты, всего≈ 22 700 строк

Соотношение к коду≈ 1 : 3,5

Документация

Документация, всего≈ 108 600 строк

Документации больше кодав ≈ 1,4 раза

👉 Документации больше, чем кода — проект строился так, чтобы быть воспроизводимым, а не «понятным только автору».

Метрики проекта

Структура продукта в цифрах

§4 справки по проекту

Тестирование

Автотестов1 023

+ в CLI-ядре+ 91

API

Эндпоинтов79

OpenAPI-контракт✓ актуален

База данных

Таблиц19

Миграций14

Интерфейс

Страниц интерфейса17

UI-компонентов35

Архитектура

Архитектурных решений (ADR)25

Разделов ТЗ16

Документация

Файлов документации432

Покрывают весь продукт✓

👉 Более тысячи автоматических проверок; каждый инкремент закрывается «зелёным» прогоном тестов.

Контроль качества

Качество и надёжность

§5 справки · многоконтурная проверка

Независимое ревью кода

На каждом инкременте: тот, кто проверяет, не пишет код. Вердикт — «готово / на доработку».

Полный прогон автотестов + статический анализ

Перед каждым развёртыванием прогоняются все 1 023+ тестов и статические анализаторы по бэку и фронту.

E2E в реальном браузере

Тестировщик прогоняет ключевые сценарии глазами пользователя — а не только «по контракту».

Изоляция данных проверяется отдельно

Специальные тесты убеждаются, что соисполнители не видят чужих компонентов; роли работают корректно.

Неизменяемость на уровне правил БД

Не «договорённость», а ограничение базы данных: переписать прошлый снимок физически нельзя.

Совместимость по стандартам

CycloneDX, выгружаемый сервисом, принимается внешними системами без доработок — это и есть критерий совместимости.

👉 Качество — это несколько независимых контуров, а не один «общий взгляд» автора кода.

Где мы сейчас

Текущий статус и направление развития

§6 справки по проекту

Готово · в эксплуатации

Базовая функциональность реализована и развёрнута

Конвейер обработки SBOM-выгрузок
Каталог компонентов и каталог лицензий
Юридический контур: вердикты + PDF + история
Ролевая модель и изоляция соисполнителей
Календарь выгрузок и сравнение «день к дню»
Экспорт единого SBOM в формате CycloneDX

→

В активной разработке

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

Обогащение координат компонентов в стандарте CPE
Курирование справочника соответствий PURL ↔ CPE
Подключение отечественной базы БДУ ФСТЭК
Вкладка «Уязвимости» в интерфейсе сервиса
Та же модель работы — инкрементами с независимым ревью

Принцип развития Новое направление строится теми же инкрементами с тем же независимым ревью кода: качество не «снижается ради скорости».

👉 Базовый каркас закрыт; следующий шаг — превратить «список компонентов» в живую карту уязвимостей проекта.