Сервис
«РБПО-аудит»

Композиционный анализ программного обеспечения и контроль лицензионной чистоты в распределённом проекте АО МНТЦ МИЭТ.
Соответствие ГОСТ Р 56939-2024 §5.16–5.17 и проекту национального стандарта ГОСТ Р ЗИ КАПО.

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

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

22 мая 2026 г.

Совещание РБПО (еженедельное)

Содержание доклада

8 блоков · 30 слайдов

Контекст и постановка задачи

Слайды 3–6 · текущее состояние Сервиса

Нормативная база

ГОСТ Р 56939-2024 и проект ГОСТ КАПО · слайды 7–11

Почему задача КАПО сложная

Условия МНТЦ МИЭТ · слайды 12–14

Архитектурный ответ Сервиса

Централизованная агрегация · слайды 15–17

Покрытие требований стандартов

Постатейный разбор · слайды 18–21

Польза для участников проекта

4 роли · слайды 22–25

Дорожная карта развития

Phase 2 — Phase 4 · слайды 26–28

Итог и решение для руководства

Что предлагается утвердить · слайды 29–30

Блок 1 · Контекст

Задача специалиста по безопасной разработке ПО АО МНТЦ МИЭТ

ГОСТ Р 56939-2024 §5.16

Наладить композиционный анализ программного обеспечения (КАПО, SCA) в проекте, разрабатываемом головным исполнителем (АО МНТЦ МИЭТ) совместно с 7 соисполнителями.
Обеспечить контроль лицензионной чистоты всех заимствованных компонентов проекта.
Сформировать доказательную базу для регулятора по составу ПО — учётно прослеживаемую, верифицируемую, версионируемую.

Цитата из ТЗ ОКР «В проекте необходимо контролировать заимствованные компоненты, их версии, источники, лицензии и уязвимости, а также вести доказательную историю изменений».

АО МНТЦ МИЭТ

головной исполнитель

Исп. 1

соисполнитель

Исп. 2

соисполнитель

Исп. 3

соисполнитель

Исп. 4

соисполнитель

Исп. 5

соисполнитель

Исп. 6

соисполнитель

Исп. 7

соисполнитель

👉 Без централизованного процесса композиционный анализ распадается на разрозненные Word-документы.

Блок 1 · Контекст

Структура проекта: головной исполнитель + 7 соисполнителей

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

Распределение участников

У каждого соисполнителя — своя toolchain: своя IDE, своя система сборки, свои пакетные менеджеры.
Зрелость DevSecOps у соисполнителей различается — от «нет ничего» до «развитый CI».
Большинство соисполнителей имеют только SAST (SVACE от ИСП РАН) и ничего по SCA / SBOM.
Закупка единого SCA-инструмента «на всех» финансово неподъёмна.

Главное следствие Унификация инструмента у всех соисполнителей операционно невозможна и финансово неподъёмна — нужен другой архитектурный паттерн.

7 соисполнителей + головной

АО МНТЦ МИЭТ

головной исполнитель · приёмочный контур

Исп. 1

соисполнитель

Исп. 2

соисполнитель

Исп. 3

соисполнитель

Исп. 4

соисполнитель

Исп. 5

соисполнитель

Исп. 6

соисполнитель

Исп. 7

соисполнитель

👉 Унификация инструмента у всех соисполнителей операционно невозможна. Решение — единая приёмочная площадка у головного исполнителя.

Блок 1 · Контекст

Композиционный анализ ПО (КАПО) — определение

Проект ГОСТ Р ЗИ КАПО · ТК 362, 2025 · §3 «Термины»

Что входит в КАПО

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

Идентификация заимствованных компонентов (open-source + проприетарные + внутренние).
Формирование перечня программных компонентов (ППК / SBOM).
Анализ лицензий и юридической совместимости.
Контроль уязвимостей (CVE / БДУ ФСТЭК).
Контроль изменений между версиями продукта.

Что НЕ входит в КАПО — путают

Не задача SBOM-агрегатора

Статический анализ собственного кода — это SAST (SVACE, Coverity).
Динамический анализ — DAST.
Антивирусное сканирование — это §5.17, отдельная тема.
Reachability уязвимых методов — задача SAST с call-graph.

👉 КАПО — это управление составом ПО, а не качеством собственного кода. Это разные классы инструментов и разные ответственности.

Блок 1 · Контекст

Сервис «РБПО-аудит» — что уже работает в продуктиве

Состояние на 22.05.2026

1 839

компонентов проекта в едином SBOM

CVE найдено через Dependency Track

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

~130

лицензий в каталоге Сервиса

Архитектура

REST API

51 endpoint

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

4 дашборда

Backend-тесты

655 passed

SBOM-стандарт

CycloneDX 1.6

Безопасность

Аутентификация

JWT

Изоляция

Row-level

Audit-log

Append-only

Internal audit

0 leaks

Покрытие стандартов

ГОСТ §5.16

95%

Проект КАПО §7

65%

Проект КАПО §8

70%

ГОСТ §5.17

не наш

👉 Сервис — рабочая площадка, не концепт. 1 839 компонентов уже в едином SBOM проекта.

Блок 2 · Нормативная база

Нормативная база КАПО в Российской Федерации

3 уровня документов

Документ	Статус	Применение к Сервису «РБПО-аудит»
ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения»	Действующий с 24.10.2024 Приказ Росстандарта № 1504-ст	§5.16 (композиционный анализ) и §5.17 (supply-chain malware) — две основные опорные точки
Проект ГОСТ Р ЗИ КАПО «Композиционный анализ программного обеспечения»	Первая редакция ТК 362, 2025 публичное обсуждение	§7 — требования к инструменту (25 пунктов), §8 — требования к ППК (13 пунктов)
СТО АО МНТЦ МИЭТ «Регламент композиционного анализа»	В разработке Phase 2 дорожной карты	Внутренний регламент организации — закрывает 5.16.2.1 и 5.16.3.1

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

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

Блок 2 · Нормативная база

ГОСТ Р 56939-2024 §5.16 — что требует от организации

§5.16 · стр. 32–35

5 ключевых требований

5.16.2.1 Разработать регламент композиционного анализа.
5.16.2.2 Формировать перечень зависимостей ПО.
5.16.2.3 Контролировать и актуализировать перечень на уязвимости.
5.16.2.4 Анализировать заимствованные компоненты, составляющие поверхность атаки.
5.16.2.5 Применять корректирующие воздействия при выявлении проблем.

п. 5.16.1.1 ГОСТ Р 56939-2024 «Использование инструментов композиционного анализа — обязательное мероприятие для снижения рисков наследования уязвимостей и недекларированных возможностей от заимствованного кода». — цитата нормативного документа

Покрытие требований Сервисом

5.16.2.1–5.16.2.5

95%

👉 5 требований — ядро регламентной части КАПО. Все в скоупе Сервиса, полное покрытие — 95% (кроме намеренного архитектурного исключения 5.16.2.4).

Блок 2 · Нормативная база

ГОСТ §5.17 — проверка цепочки поставок на вредоносное ПО

§5.17 · стр. 35–37 · вне скоупа Сервиса

§5.17 шире SBOM и лицензий

Требует антивирусного сканирования компонентов цепочки поставок.
Требует контроля договоров с поставщиками компонентов.
Требует аудита инфраструктуры разработки соисполнителей.
Требует контроля целостности готовых бинарников — подписи, хэши.
Требует проверки репутации поставщиков (OSA, БДУ ФСТЭК).

Принципиальная позиция «§5.17 — другой класс инструментов: антивирус, infrastructure scanner, договорный контур. Сервис «РБПО-аудит» принципиально не закрывает §5.17 — это нужно говорить честно, чтобы не обещать регулятору невозможное».

Покрытие §5.17 Сервисом

5.17 supply-chain malware

~20%

Сервис может быть источником данных для §5.17, но не закрывает раздел сам по себе.

👉 Для полного покрытия §5.17 нужна параллельная программа: антивирусный pre-scan + договорный контур + аудит инфраструктуры соисполнителей.

Блок 2 · Нормативная база

Проект ГОСТ КАПО §7 — 25 требований к инструменту

Первая редакция ТК 362, 2025

«Должен» · обязательные

5требований

7.1 формат CycloneDX / SPDX
7.2 авто-обогащение CVE и лицензиями
7.5 отчёты + журналы операций
7.7 минимум полей по CVE
7.19 регистрация всех операций

Сервис: 4 ✅ + 1 ⚠ = 80%

«Рекомендуется»

15требований

7.14 граф зависимостей
7.17 политики по лицензиям + совместимость
7.18 многопользовательский доступ, RBAC
7.6 email-оповещения

Сервис: 6 ✅ + 5 ⚠ + 4 ❌

«Может» · опциональные

5требований

Дедупликация уязвимостей
Свои базы CVE
Reachability-анализ
Внутренний CVE-feed

Сервис: 3 ✅ + 1 ⚠ + 1 ❌

👉 Из 5 обязательных требований Сервис закрывает 4 полностью + 1 в дорожной карте. Обязательная часть = 80%.

Блок 2 · Нормативная база

Откуда Сервис берёт каноны классификации лицензий

Раздел 7 conformance документа

✓ Permissions · 5

commercial-use
modifications
distribution
private-use
patent-use

⚠ Conditions · 8

include-copyright
document-changes
disclose-source
same-license
network-use-disclose
… всего 8

✕ Limitations · 4

liability
warranty
trademark-use
patent-use

Closed-loop Сервис не обращается к choosealicense в runtime — каноны вшиты в код один раз при разработке. Никаких сетевых запросов из закрытого контура наружу.

Источники канонов

Источник	Что даёт
choosealicense.com GitHub, MIT	Теги 5 + 8 + 4 классификации
SPDX License List Linux Foundation	~600 SPDX-идентификаторов
OSI	Флаг «OSI-approved»
FSF	Флаг «FSF libre»
CycloneDX 1.6 OWASP	Стандарт SBOM

👉 Российских аналогов классификации 5 + 8 + 4 не существует. Минцифры РФ ведёт реестр запрещённых компонентов, но не классифицирует лицензии по permissions / conditions / limitations.

Блок 3 · Почему задача сложная

Проблема №1: C/C++ legacy-сборки

Почему КАПО — нетривиальная задача в условиях МНТЦ МИЭТ

Кодовая база проекта

Основная задача МНТЦ МИЭТ — навести управляемость в сложном C/C++ продукте, не в типовом web/npm/maven-проекте.
Legacy-сборки: make, cmake, qmake, системные библиотеки, форкнутые компоненты.
Не все зависимости описаны в пакетных менеджерах (Conan и т.п.).
Широко используются статически линкованные внутренние библиотеки.
Главный критерий выбора инструмента: «кто лучше достаёт фактический состав C/C++ продукта», а не «кто красивее агрегирует».

Аналитическая справка AppSec vs CodeScoring «Не типовой web/npm/maven проект — большая часть кодовой базы на C/C++ с legacy-сборками. Нет универсального инструмента, который бы решил это автоматически».

Источники состава ПО — реальная картина

Conan / package manager

~35%

Внутренние библиотеки

~30%

Системные / форкнутые

~25%

Бинарные включения

~10%

👉 Это не «просто загрузить package.json» — это глубокая инвентаризация с учётом форков, статической линковки и бинарных артефактов.

Блок 3 · Почему задача сложная

Даже лидеры рынка осторожны: ограничения CodeScoring и AppSec

Проблема №2: технические ограничения коммерческих SCA-инструментов

Демонстрация 21.04.2026

CodeScoring

Сборочный контекст + eBPF

Анализ C/C++ через сборочный контекст + eBPF на Linux ядро ≥ 5.8.
Не видит статические зависимости и форки без явных метаданных.
Эвристика через сигнатуры — ~70% точности (помощь, не решение).

AppSec.Track

Требует Conan-манифеста

Для C/C++ требуется обязательный переход на Conan.
Часть соисполнителей МНТЦ МИЭТ это сделать пока не может.
Без Conan — нет манифеста — нет извлечения.

Цитата · встреча 21.04.2026 «Никакой готовый коммерческий инструмент не решает задачу exhaustive автоматического извлечения компонентов для такого продукта. Все доступные инструменты дают частичное покрытие и требуют либо preparatory работ, либо человеческого обогащения».

👉 Покупка одного инструмента задачу не решит. Нужна связка: внешние SCA-источники + внутренний приёмочный контур.

Блок 3 · Почему задача сложная

Проблема №3: разная зрелость DevSecOps у 7 соисполнителей

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

Уровень зрелости	Что есть	Чего нет
Базовая большинство соисполнителей	SVACE (SAST от ИСП РАН)	SCA, SBOM, лицензионный аудит, CVE-management
Развитая отдельные соисполнители	SVACE + Conan + базовый CI	Лицензионная политика, единый SBOM по версии
Целевая АО МНТЦ МИЭТ как Общество	SAST + SCA + SBOM + лицензии + риски + аудит-журнал	— достигнута через Сервис

Финансовая реальность Унификация инструмента через закупку лицензии на 7 организаций — финансово неподъёмна. Каждый соисполнитель работает в своём темпе и своим toolchain.

Архитектурное следствие Сервис позволяет соисполнителю сдать минимальный SBOM без покупки дорогого инструмента — это и есть «бесплатная для соисполнителей» точка входа.

👉 Архитектурный ответ — не «единый инструмент у всех», а «единая приёмочная площадка у головного исполнителя».

Блок 4 · Архитектурный ответ Сервиса

Централизованная агрегация — основной паттерн

Архитектура верхнего уровня

Соисполнители

Исп. 1SBOM →

Исп. 2SBOM →

Исп. 3SBOM →

Исп. 4SBOM →

Исп. 5SBOM →

Исп. 6SBOM →

Исп. 7SBOM →

Сервис «РБПО-аудит»

Единая приёмочная площадка

Парсинг и нормализация SPDX
Юридический аудит лицензий
Журнал решений по рискам
Единый CycloneDX 1.6 SBOM проекта
RBAC + row-level изоляция

Внешние контуры

Dependency Track

CVE: 26 / 1 839

Юристы Общества

Каталог ~130 лицензий

Отчёты регулятору

PDF / CycloneDX / Excel

Руководство

Светофор + тренды

👉 Принципиально — не «волшебный сканер», а централизованная организационная площадка для сдачи, нормализации и юридической экспертизы SBOM проекта.

Блок 4 · Архитектурный ответ Сервиса

Pipeline обработки SBOM — от ZIP до единого CycloneDX

End-to-end автоматизация

Соисполнитель формирует ZIP по канону
YYYY/MM/DD/<contractor>/<component>/<archive>.zip
ZIP содержит SBOM-Registry.xlsx (обязательно) + bom.json CycloneDX (provenance) + исходные SBOM-файлы соисполнителя.
Оператор Общества загружает архив через веб-форму или REST API.
Сервис парсит Excel, создаёт Component, Dependency, License.
PURL-генерация для компонентов с известным ecosystem.
Нормализация лицензий через SPDX List + choosealicense теги.
Формирование единого CycloneDX 1.6 SBOM проекта по дате загрузки.
Экспорт в Dependency Track через REST API.

Pipeline · схема

┌─ ZIP-архив соисполнителя ─────────────────┐ │ YYYY/MM/DD/<contractor>/<component>/ │ │ ├ SBOM-Registry.xlsx (обязат.) │ │ ├ bom.json (CycloneDX 1.6) (provenance)│ │ └ source/* (исходные SBOM) │ └───────────────────┬───────────────────────┘ ▼ Парсинг + нормализация │ ▼ PURL + SPDX + теги 5+8+4 │ ▼ Единый CycloneDX 1.6 проекта │ ┌───────────┴────────────┐ ▼ ▼ Dependency Track Юр. экспертиза (CVE-mapping) (вердикты юриста)

UI: страница «Загрузки» с историей upload'ов и SHA-256 хэшами

👉 End-to-end процесс автоматизирован — от загрузки ZIP до отображения CVE в Dependency Track.

Блок 4 · Архитектурный ответ Сервиса

Доказательная база Сервиса — что хранится и зачем

Compliance evidence

Сущность	Содержание	Зачем для compliance
`Upload`	ZIP-архив, SHA-256, дата, статус, оператор	§5.16.3.3 — журналы регистрации событий
`Component`	Имя, версия, PURL, лицензия, источник, соисполнитель	§5.16.3.2 — перечень зависимостей с поставщиком
`Dependency`	Транзитивные связи между компонентами	§7.14 проекта КАПО — граф зависимостей
`License`	SPDX-id, 5+8+4 теги, OSI-approved, FSF-libre, copyleft	§7.17 — политики по лицензиям
`LicenseVerdict`	Вердикт юриста + история изменений + PDF заключения	§5.16.3.5 — корректирующие воздействия
`RiskDecision`	Управленческое решение по риску + обоснование	§5.16.2.5 — корректирующие воздействия
`AuditLog`	Append-only журнал всех действий пользователей	§7.19 — регистрация операций
`SecurityEvent`	События безопасности (попытки cross-tenant доступа)	§7.19 + изоляция данных

👉 Всё, что регулятор может попросить — есть в системе и связано журналами. Каждая сущность привязана к конкретному пункту стандарта.

Блок 5 · Покрытие требований

Сводка покрытия требований стандартов

Главная таблица для руководства

Стандарт / раздел	✅	⚠	❌	Покрытие
ГОСТ 56939 §5.16 регламент КАПО	9	1	0	🟢 95%
ГОСТ 56939 §5.17 supply-chain malware	0	3	2	🔴 20% не наш скоуп
Проект ГОСТ КАПО §7 требования к инструменту	12	8	5	🟡 65%
Проект ГОСТ КАПО §8 требования к ППК / SBOM	7	3	3	🟢 70%

Покрытие по разделам

ГОСТ §5.16

95%

ГОСТ §5.17

20%

Проект КАПО §7

65%

Проект КАПО §8

70%

полное частичное не закрыто

👉 Регламентная часть КАПО — 95%. Инструментальная — 65–70%. §5.17 принципиально не наш скоуп.

Блок 5 · Покрытие требований

ГОСТ §5.16 — покрытие 95% по 10 пунктам

Постатейный разбор

Пункт	Требование	Статус	Чем закрыто
5.16.2.1	Регламент КАПО	✅	`docs/runbooks` + `docs/user-guides`
5.16.2.2	Перечень зависимостей	✅	`GET /api/v1/sbom/unified/{date}`
5.16.2.3	Контроль актуализации	✅	Сравнение дат + Dependency Track
5.16.2.4	Анализ при сборке	⚠	У соисполнителей (CodeScoring / AppSec вне Сервиса)
5.16.2.5	Корректирующие воздействия	✅	`RiskDecision` + audit-trail
5.16.3.1	Содержание регламента	✅	`docs/user-guides`
5.16.3.2	Содержание перечня	✅	CycloneDX 1.6 с PURL / version / supplier
5.16.3.3	Журналы регистрации	✅	`audit_log` + `security_events`
5.16.3.4	Результаты анализа	✅	Dependency Track: CVSS3, EPSS, severity
5.16.3.5	Корректирующие меры	✅	`RiskDecision` + PDF юр.заключений

👉 Регламентная часть КАПО — полное покрытие, кроме намеренного архитектурного решения 5.16.2.4 (анализ при сборке — у соисполнителей).

Блок 5 · Покрытие требований

Проект ГОСТ КАПО §7 — детально по 25 пунктам

25 требований · 3 категории

«Должен» · обязат. (5)

4 ✅ + 1 ⚠

«Рекомендуется» (15)

6 ✅ + 5 ⚠ + 4 ❌

«Может» · опц. (5)

3 ✅ + 1 ⚠ + 1 ❌

🟢 Сильные стороны

7.14 Граф зависимостей — полностью.
7.17 Политики по лицензиям + совместимость — главная сильная сторона.
7.18 Многопользовательский доступ + изоляция.
7.19 Регистрация операций (audit-log).

🔴 Не закрывается

7.4 Анализ контейнеров (Docker / OCI) — вне скоупа.
7.10 Авто-построение ППК — Phase 2.
7.15 Идентификация в исходниках — внешние SCA.
7.22 Свои базы CVE — используем Dependency Track.
7.25 Reachability уязвимых методов — SAST.

👉 Обязательная часть — 80% реализации; полная — за 1 квартал по дорожной карте.

Блок 5 · Покрытие требований

Проект ГОСТ КАПО §8 — требования к ППК (SBOM)

13 пунктов

Пункт	Требование	Статус	Комментарий
8.1	Формат CycloneDX или аналог	✅	CycloneDX 1.6 — международный стандарт
8.2	Минимум полей: Автор, Имя, Версия, PURL, Автор ППК, Дата	✅	Все 6 полей в каждом компоненте
8.3	Отдельный ППК на каждую версию	✅	Один SBOM на одну дату загрузки
8.4	Экспорт по Приложению А (РФ-канон)	⚠	CycloneDX 1.6 сейчас; миграция в дорожной карте
8.5	Поверхность атаки	❌	Вне скоупа SBOM-агрегатора
8.6	Взаимозависимости	✅	`bom.dependencies` в unified SBOM
8.7	Уязвимости (id, CVSS, дата)	✅	Через Dependency Track
8.8	Лицензии (SPDX)	✅	`spdx_id` + валидация
8.9	Цифровая подпись ППК	❌	КриптоПро / Госключ в Phase 3
8.10	Хэш-коды компонентов	⚠	SHA-256 для `bom.json`; per-component в Phase 2
8.11	Отметка о компрометирующих конструкциях	❌	Антивирус извне
8.12	Расширенные метаданные	✅	type, description, purl, license, text
8.13	ML-модели	❌	В проекте нет ML-компонентов

👉 Из 4 обязательных пунктов закрыто 3 полностью + 1 частично (per-component хэши — Phase 2). Покрытие обязательной части = 88%.

Блок 6 · Польза для участников · роль 1/4

Польза для Руководителей проекта

Верхнеуровневое управление рисками и эскалация

Топ-менеджмент АО МНТЦ МИЭТ

Что видит руководитель

Светофор по проекту: 🟢 безопасно / 🟡 риск / 🔴 критично — по каждому соисполнителю и компоненту.
Сводка по CVE: количество, распределение по severity, тренд по неделям.
Сводка по лицензиям: сколько copyleft, сколько проприетарных, сколько без вердикта.
Открытые риск-решения — требующие управленческой эскалации.

Что даёт

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

🟢 5

соисполнителей в зелёной зоне

🟡 2

в жёлтой — требуют внимания

🔴 1

критичный — есть открытый риск

10 мин

времени в неделю на контроль проекта

👉 Руководитель работает 10 минут в неделю и видит все ключевые риски проекта.

Блок 6 · Польза для участников · роль 2/4

Польза для Специалистов РБПО Общества

Контроль безопасности всего проекта из одной системы

Головной исполнитель

Что видит специалист РБПО

Полный состав ПО проекта — 1 839 компонентов от 7 соисполнителей.
Лицензионная карта проекта — какие лицензии где, конфликты.
CVE-mapping — какие компоненты затронуты, какие соисполнители должны исправить.
Журнал решений по рискам — что эскалировано, что принято.
История изменений между датами загрузки.

Что даёт

Единая точка контроля — не нужно обращаться к каждому соисполнителю.
Сравнение версий — /api/v1/uploads/compare показывает дельту.
Управление приоритетами — фокус на критичных компонентах.
Интеграция с Dependency Track — CVE-сопоставление одной кнопкой.

Аудит изоляции — 22.05.2026 Independent audit verified: 0 cross-tenant leaks. 51 REST endpoint для интеграции с внешними системами.

👉 Специалист РБПО Общества управляет безопасностью всего проекта из одной системы.

Блок 6 · Польза для участников · роль 3/4

Польза для Юристов Общества

Лицензионная чистота — юридическая экспертиза в едином контуре

Лицензионный аудит

Что видит юрист

Каталог ~130 лицензий — все встречающиеся в проекте.
Карточка каждой лицензии с тегами 5 + 8 + 4.
Список компонентов с этой лицензией — на каких соисполнителях, в каких версиях.
PDF юр.заключения — прикреплённые к лицензиям.
История вердиктов — кто, когда, что менял.

Что даёт

Не нужно вручную классифицировать каждую лицензию — каноны уже вшиты.
Сценарный анализ: «совместима ли X с Y» — встроенный мастер.
PDF-экспорт для архива и договорного контура.
История вердиктов — защита от спора «а кто это решал?».
Загрузка legal-opinion PDF — связь с экспертизами.

Phase 2 · обсуждено с юристами 22.05.2026 Endpoint /api/v1/licenses/{id}/legal-opinion?format=html|pdf — печатные юридические заключения в каноне юристов АО МНТЦ МИЭТ + расширение модели лицензий с учётом ГК РФ и Минцифры compliance.

👉 Юрист работает с агрегатом — централизованно, с историей, с международными канонами.

Блок 6 · Польза для участников · роль 4/4

Польза для Специалистов РБПО соисполнителей

Свои компоненты — свой изолированный контур

Исп. 1 · Исп. 2 · Исп. 3 · Исп. 4 · Исп. 5 · Исп. 6 · Исп. 7

Что видит соисполнитель

Только свои компоненты — данные других не видны (row-level isolation).
Вердикты юриста по своим компонентам — что разрешено / запрещено.
CVE на свои компоненты — через единый SBOM в Dependency Track.
Рекомендации по обновлению версий.
Журнал изменений — что менялось в его поставках.

Что получает в обмен на свой SBOM

Уверенность в compliance с ГОСТ 56939 §5.16.
Лицензионная экспертиза от юристов Общества — бесплатно, в рамках проекта.
CVE-tracking — без покупки Dependency Track лицензии.
Простой канон поставки: ZIP YYYY/MM/DD/<contractor>/<component>/.

Изоляция данных · independent audit 22.05.2026 «Independent audit verified: 0 cross-tenant leaks. Соисполнитель видит только свои данные, ни одного байта чужих компонентов».

👉 Соисполнитель получает в 10× меньше работы за счёт централизации и в 100× меньше рисков compliance.

Блок 7 · Дорожная карта

Phase 2 — следующие 30–60 дней

Юридический контур + Artifactory + оповещения

Q2 2026

ADR-0019 — расширение модели лицензий (ГК РФ + Минцифры). Обсуждено с юристами 22.05.2026.
Endpoint /api/v1/licenses/{id}/legal-opinion?format=html|pdf — печатные юридические заключения в каноне юристов АО МНТЦ МИЭТ.
JFrog Artifactory poller — закрытие 7.10 и 7.11 проекта ГОСТ КАПО.
Email-оповещения — закрытие 7.6.
Per-component хэши в unified SBOM — закрытие 8.10.

Ожидаемый эффект на покрытие

Проект КАПО §7

65 → 75%

Проект КАПО §8

70 → 80%

Зона ответственности Phase 2 Закрытие большей части Phase-1 долгов по проекту ГОСТ КАПО + юридический контур для юристов.

👉 Phase 2 закрывает большую часть Phase-1 долгов по проекту ГОСТ КАПО.

Блок 7 · Дорожная карта

Phase 3 (квартал) и Phase 4 (после)

Q3 2026 — Q1 2027

Phase 3 · квартал

SSO через FreeIPA — централизованная аутентификация (упрощение подключения соисполнителей без выдачи паролей).
Цифровая подпись ППК через КриптоПро / Госключ — закрытие 8.9.
Расширенный compliance-отчёт за период.

Phase 4 · после

Интеграция с CodeScoring / AppSec — приём их extraction-результатов как доп. источника SBOM.
ClamAV / Kaspersky pre-scan архивов — частичное покрытие §5.17.
БДУ ФСТЭК интеграция.
Attack-surface marking (GOST:attack_surface) — приближение к 5.16.2.4.

Стратегическая цель «Phase 4 — закрытие §5.16.2.4 (анализ при сборке) и приближение к §5.17 (supply-chain malware). После этого АО МНТЦ МИЭТ — одна из первых соответствующих организаций по полному комплекту нормативной базы РФ в части КАПО».

👉 Через 1–2 квартала — покрытие 80%+ по проекту ГОСТ КАПО.

Блок 7 · Дорожная карта

Что Сервис принципиально не закрывает — и почему это нормально

Честная позиция для регулятора

Не закрывается Сервисом	Чем закрывается	Куда обращаться
Auto-extraction компонентов из C/C++ сборки	CodeScoring / AppSec.Track	У соисполнителей
Анализ malware в цепочке поставок (§5.17)	ClamAV / Kaspersky / OSA-репутация	Phase 4 + отдельная программа
Анализ контейнерных образов	Trivy / Grype / Anchore	Внешний контур
Reachability уязвимых методов	SAST с call-graph (CodeQL / Coverity)	Внешний контур
Контроль договоров с поставщиками	Юридический процесс	Юристы Общества + договорной контур
Аудит инфраструктуры соисполнителей	Infrastructure audit	Отдельная программа РБПО

Корректная формула для регулятора Сервис закрывает ядро КАПО (учёт / лицензии / SBOM) и является доказательным контуром для требований §5.16. Разделы §5.17 и advanced SCA закрываются отдельными мерами.

👉 Не пытаемся сделать «всё в одном». Делаем то, что делаем — правильно.

Блок 8 · Итог

Итог: что предлагается руководству

Решения, требуемые от руководства

Продолжать развивать Сервис «РБПО-аудит» — он закрывает регламентную часть КАПО, лицензионный аудит и единый SBOM проекта.
Не заявлять полное соответствие ГОСТ Р 56939-2024. Корректная формула: «закрывает ядро КАПО и является доказательным контуром для §5.16; §5.17 закрывается отдельными мерами».
На ближайшие 30 дней — оформить регламент КАПО, утвердить формат сдачи SBOM соисполнителями, связать загрузки с релизными версиями, закрепить DT-отчёт как CVE-evidence.

Главный аргумент «Без Сервиса в условиях АО МНТЦ МИЭТ задача КАПО не решается ни закупкой одного коммерческого инструмента, ни передачей соисполнителям требований "делать у себя SBOM". Нужен централизованный приёмочный контроль с лицензионной экспертизой и журналом изменений».

Чек-лист решений руководства

Утвердить роль Сервиса как внутреннего корпоративного контура композиционного анализа.
Утвердить обязательную сдачу SBOM для всех соисполнителей.
Утвердить формат поставки (CycloneDX 1.6 + Excel-реестр).
Назначить владельца регламента КАПО организации.
Поддержать Phase 2 + Phase 3 дорожной карты.

👉 АО МНТЦ МИЭТ может быть одной из первых соответствующих организаций по проекту ГОСТ КАПО в РФ.

Спасибо.

Композиционный анализ ПО — централизованно, юридически чисто, доказательно.

Готов к вопросам

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

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

v.pikov@istc-miet.ru
+7 (963) 782-92-78

Внутренние документы

docs/compliance/
2026-05-22-gost-56939-kapo-conformance.md
docs/compliance/
2026-05-22-gost-56939-kapo-strict-checklist.md
docs/runbooks/
prepare-sbom-from-artifactory.md
docs/user-guides/ — гайды по 4 ролям

Нормативные документы

ГОСТ Р 56939-2024 — Росстандарт № 1504-ст от 24.10.2024
Проект ГОСТ Р ЗИ КАПО — ТК 362, первая редакция 2025
CycloneDX 1.6 — OWASP
SPDX License List — Linux Foundation

Сервис«РБПО-аудит»

Сервис
«РБПО-аудит»