Пиков / КАПО
Библиотека
Как читать авторский курс и нормативные материалы

Это учебные материалы, а не заключение о соответствии конкретного продукта. Организационные модели курса отделяйте от терминов стандарта: ППК в опубликованном проекте — машиночитаемый перечень, а живой реестр его версий является практикой сопровождения. Термин OSA в разных материалах имеет разный охват. Статус и обязательность нормативного документа проверяются отдельно; проект КАПО опубликован как проект первой редакции.

Матрица соответствия CodeScoring требованиям ТЗ OSA/SCA

Назначение Рабочая матрица для подготовки пилота. Сопоставляет требования ТЗ OSA/SCA/TQI с подтверждёнными возможностями CodeScoring. База анализа: ТЗ OSA‑SCA, материалы демонстрации поставщика, опросник и бюджетная оценка, публичная документация CodeScoring.

Это обезличенная рабочая выжимка. Любой статус «соответствует» по спорным пунктам не считается закрытым до демонстрации или письменного подтверждения поставщика.

Короткий вывод CodeScoring в целом соответствует базовой цели ТЗ: OSA/SCA, контроль цепочки поставки, анализ зависимостей, SBOM, политики, интеграция с GitLab/CI/CD и on‑premise поставка. Но соответствие нельзя признать полным и безусловным: часть языков из ТЗ не подтверждена как SCA‑экосистемы; OSA Proxy не покрывает весь список пакетных менеджеров; C/C++ без пакетного менеджера требует пилота на make/cmake/qmake и статической линковке; анализ готовых бинарников ограничен; требования к исполнителю (ФСТЭК, ISO 9001) не подтверждены представленными материалами.

Легенда статусов

Статус Значение
✅ Соответствует (подтверждено документацией/демо)
🟡 Частично соответствует / требует подтверждения в пилоте
🔴 Риск несоответствия / не подтверждено
⚪ Не техническая проблема — нужно управленческое решение

Итоговый вердикт

Вопрос Вывод
Подходит ли CodeScoring под ТЗ? 🟡 Частично. Как кандидат для закупки/пилота — да; до признания полного соответствия нужно закрыть подтверждения и уточнить формулировки ТЗ.
Можно ли считать требования OSA/SCA закрытыми? 🔴 Нет. Большая часть закрывается, но есть рискованные пункты: OSA Firewall для всех пакетных менеджеров, qmake / C++ без пакетного менеджера, анализ готовых бинарников, языки Bash/Perl/SQL‑семейства, требования к исполнителю.
Главная рекомендация Пилот с приёмочными сценариями по спорным требованиям; в ТЗ разделить требования на: подтверждённые продуктом / требующие демонстрации / требующие договорной гарантии / уточняемые.

Главные разрывы и риски

5 зон, которые надо закрыть до признания соответствия Это смысловой центр анализа соответствия. Остальные таблицы — детализация.

# Требование / зона Что проверено Вывод
1 Языки из п. 3.3 ТЗ требует Java, Kotlin, JS, TS, Python, C, C++, Go, PHP, Ruby, C#, Objective‑C, Swift, Rust, Scala, Bash, Perl, SQL, PLSQL, PGSQL. Документация подтверждает широкий набор package/ecosystem‑сканирования, но не даёт явного подтверждения Bash, Perl, SQL/PLSQL/PGSQL как SCA‑экосистем. 🟡 Уточнить: SCA анализирует зависимости/пакеты, а не произвольный синтаксис всех языков.
2 OSA Firewall/Proxy для всех пакетных менеджеров Документация OSA Proxy явно указывает Maven, NPM, PyPI, NuGet V3, Go, Debian, Alpine/APK, RPM, Docker Registry. Conan/Conda/RubyGems — через плагины Nexus/JFrog, что не равно универсальному Proxy Firewall. 🔴 Риск. Если ТЗ требует именно Proxy‑перехват для Conan, Conda, RubyGems без Nexus/JFrog — не подтверждено.
3 C/C++ без пакетного менеджера: make, cmake, qmake Документация и материалы демонстрации подтверждают C/C++ build scan через агент/eBPF, GCC/Clang, CMake/Make. qmake прямо не подтверждён. Полнота инвентаризации достигается на этапе сборки. 🟡 Для qmake и конкретных сборок — демонстрация в пилоте.
4 Готовые бинарники и статическая линковка ТЗ требует binary analysis архивов и артефактов. Документация подтверждает сканирование архивных форматов. По подтверждённым материалам анализ уже собранных бинарников, особенно stripped и статически слинкованных, надёжно не решается. 🟡 Архивы/контейнеры — да; идентификация native binary/.a/.so без сборочного контекста — риск.
5 Требования к исполнителю ТЗ требует лицензию ФСТЭК на ТЗКИ/мониторинг ИБ, опыт 10 лет, ISO 9001, выделенное ИБ‑подразделение. В представленных материалах не подтверждено. 🔴 Запросить у поставщика/дистрибьютора подтверждающие документы.

Матрица по общим требованиям (3.1–3.3)

Пункт ТЗ Требование Подтверждение Статус
3.1 ПО в Едином реестре российских программ Указано включение в реестр (запись № 13008); ссылка в бюджетной оценке ✅ Проверить актуальную карточку реестра при закупке
3.1 OSA: защита цепочки поставки, пакеты/образы, уязвимости, ВПО, лицензии Контроль пакетов, политики, блокировка, работа с репозиториями/registry; malware/protestware заявлены ✅ Перечень package‑manager режимов уточнить
3.1 SCA: кодовая база и контейнеры из CLI/CI, инвентаризация, граф связей, уязвимости, ВПО, лицензии CLI/агент: project/manifest/build scan, docker/image, архивы, SBOM, уязвимости, лицензии ✅
3.2 Дистрибутив, русская документация, лицензия Поставка + лицензия 12 мес + гарантийное сопровождение; русская документация ✅ Проверить комплект при приёмке
3.3 GitLab, GitHub, Bitbucket, Azure DevOps, git Интеграции с VCS и GitLab подтверждены; в опроснике выбран GitLab ✅ Прочие VCS — демо только если нужны в объёме
3.3 Docker‑образы Анализ Docker/OCI images и registry ✅
3.3 SBOM и отчётность: CycloneDX/SPDX/JSON/CSV SBOM, CycloneDX/SPDX, экспорт JSON и CSV/табличные выгрузки ✅ В основной части
3.3 Политики на локальных/proxy‑репозиториях, CI/CD, VCS Политики, агент в CI/CD, VCS‑проверки, OSA‑политики в репозиториях ✅ Описать архитектуру применения
3.3 Email, Jira, события в интерфейсе Notification integrations, задачи, уведомления; не все каналы демонстрировались 🟡 Проверить SMTP/Jira в пилоте
3.3 RBAC, встроенная аутентификация, LDAP/AD/OIDC Пользователи/группы, OpenID Connect, LDAP/AD ✅ С настройкой
3.3 Аудит‑логи + выгрузка в ELK/Syslog/SIEM Audit log подтверждён; выгрузка всех логов в SIEM — нужно подтвердить архитектурно 🟡 Проверить способ выгрузки логов

Матрица по OSA

Требование OSA Подтверждение Статус
Политики по метаданным, CVSS, лицензиям, blacklist, malware/protestware Покрыты параметры пакетов, уязвимости, лицензии, блокировки, blacklists, вредоносные/протестные зависимости ✅ CVSS 4.0 и поля проверить в UI/пилоте
Группировка правил И/ИЛИ, правила игнорирования Policy conditions, groups/sets, исключения ✅ Проверить сценарии
Блокировка компонента при загрузке в контур OSA Proxy/плагины блокируют небезопасные пакеты по policy ✅ Для поддерживаемых режимов
Отложенная блокировка на интервал Прямого подтверждения delayed blocking не найдено 🔴 Запросить демо/письменное подтверждение
Перехват запросов ПМ, проксирование, модификация ответов OSA Proxy — ограниченный набор endpoints; Nexus/JFrog — часть use cases 🟡 Полный список ТЗ не подтверждён
Firewall для Maven, NPM, NuGet, PyPI, Go, APT, RPM, Conan, Conda, RubyGems Публичная докум. OSA Proxy не подтверждает Conan/Conda/RubyGems в proxy‑firewall; возможно через repo‑manager плагины (Nexus/JFrog) 🔴 Риск несоответствия
Работа с нестандартными хранилищами и без хранилищ Репозитории, registry, CLI/agent без artifact repository; нестандартные — проверять по факт. архитектуре 🟡 Архитектурная проверка
Источники: NVD, GitHub Advisory, OSS Index, OSV, БДУ ФСТЭК Указаны NVD/GitHub/OSV/OSS Index/БДУ и др. ✅ В основной части
Экспорт CSV, классификация уязвимостей Exports и классификация/статусы уязвимостей ✅

Матрица по SCA

Требование SCA Подтверждение Статус
Индивидуальные политики для этапов ЖЦ Policies в IDE/VCS/CI/CD/registry ✅ Описать этапы
Распознавание зависимостей: ecosystem/name/version, manifest, транзитивные, metadata manifest scan, dependency resolution, package metadata, build scan ✅
Разделение прямых/транзитивных, environments/scopes Для многих ecosystems; отображается в SBOM/graph ✅ Проверить для C/C++ build scan
Граф зависимостей, трассировка транзитивных Граф зависимостей и SBOM ✅
Лицензионная чистота, совместимость, ручная конфигурация License policies и compatibility controls ✅
Мониторинг новых уязвимостей в проде Повторное/регулярное сканирование; регламент production monitoring настроить ✅ При настройке
Рекомендации по устранению remediation/fixed versions/upgrade в карточках ✅ В основной части
SBOM CycloneDX и SPDX в JSON Оба формата ✅
Binary analysis архивов: jar, war, zip, whl, nupkg и др. CLI сканирует archives/package artifacts; native .a/.so/executable — ограничено по подтверждённым материалам 🟡 Уточнить границу binary analysis
Пакетные менеджеры: Maven, Gradle, NPM, NuGet, Pip, Poetry, Go, RubyGems, Cocoapods, Packagist, CONAN, Yarn, Composer, Conda, Cargo Широкое покрытие для SCA; для OSA Proxy режимов — ограничения ✅ SCA да; OSA Proxy отдельно
Универсальный агент: GitLab, Jenkins, TeamCity CI integration подтверждён; в опроснике GitLab ✅ Jenkins/TeamCity проверить при необходимости
IDE plugins: VS Code, IntelliJ Подтверждено. Qt Creator не подтверждён 🟡 Qt Creator не входит — важно для C++/Qt контура
Релентность уязвимостей анализом вызовов (Java, Python, Go) reachability/call analysis для отдельных технологий 🟡 При наличии модуля + проверка в пилоте

Поставка и коммерческое соответствие

Требование Факт по материалам Вывод
Лицензия на 1 год с гарантийным сопровождением Лицензия 12 мес + расширенное гарантийное сопровождение ✅
Аналитика на 50 активных авторов Опросник и бюджетная оценка: 50 авторов ✅
Поставка on‑premise ТЗ требует on‑premise; опросник — Offline; оценка содержит Offline и Core on‑premise ⚪ Выбрать целевой вариант
Докупка пакетов авторов кратно 50 Прямого подтверждения не найдено 🔴 Запросить у поставщика
Обновления в течение абонентского периода Указано получение обновлений в рамках сопровождения ✅

Требования к исполнителю

Требование Подтверждение Вывод
Лицензия ФСТЭК на ТЗКИ, включая мониторинг ИБ Не найдено 🔴 Запросить копию лицензии
Опыт на рынке ИБ ≥ 10 лет Не подтверждено материалами 🔴 Запросить подтверждение
ISO 9001:2015 Не подтверждено материалами 🔴 Запросить сертификат
Выделенное подразделение по ИБ Не подтверждено материалами 🔴 Запросить подтверждение

Проверочные сценарии для пилота

Что прогнать на реальных сборках 1. On‑premise/Offline инсталляция в тестовом контуре; зафиксировать архитектуру: серверы, БД, сеть, доступы, обновление базы знаний. 2. Подключить GitLab + один CI/CD пайплайн C/C++ без Conan; build scan на make, cmake и отдельно qmake. 3. C/C++ статическая линковка: проект с .a/.so, stripped binary, внутренний форк; зафиксировать что видит автоматически, а что требует ручной разметки. 4. Conan flow: прямые/транзитивные зависимости, SBOM, граф, license/security policy. 5. OSA‑блокировка в фактическом режиме: через Nexus/JFrog plugin либо OSA Proxy. Отдельно Maven, NPM, NuGet, PyPI, Go, APT/RPM, Conan, Conda, RubyGems — если остаются обязательными. 6. SBOM export/import: CycloneDX JSON, SPDX JSON, CSV; совместимость с результатом стороннего OSS‑инструмента. 7. Уведомления: SMTP, Jira, UI events; audit log и отправка логов во внешнюю систему. 8. LDAP/AD или OIDC, RBAC, роли админ/ИБ/разработчик/наблюдатель. 9. Запросить документы: ФСТЭК, ISO 9001, опыт, структура ИБ‑подразделения.

Рекомендуемые уточнения ТЗ

Связанные заметки