Как читать авторский курс и нормативные материалы

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

Конспект: CodeScoring и подготовка пилота

Зачем модуль

Организация формирует закупку SCA/OSA-системы по собственному ТЗ, и кандидат — CodeScoring (включён в Единый реестр российских программ). Соблазн прост: поставщик отвечает «да» почти на каждый пункт, а закупка фиксирует «полное соответствие». Проблема в том, что ТЗ написано как единый список, а продукт состоит из разных режимов с разными границами: OSA Proxy (firewall пакетных менеджеров), плагины к Nexus/JFrog, CLI/агент сборочного анализа, IDE-плагины. Одно и то же требование может быть закрыто в одном режиме и невозможно в другом. Если этого не разделить, ТЗ начинает требовать от Proxy того, что умеет только агент, и приёмка спотыкается уже после оплаты.

Второй движок модуля — профиль самой Организации: преобладают C/C++ legacy-сборки (make, CMake, qmake), статическая линковка, внутренние форки, отсутствие или неполнота манифестов. Именно здесь любой SCA-инструмент проверяется на честность, и именно сюда нужно целить пилот.

Ключевые идеи

1. Методика «требование → evidence → статус». Каждое требование ТЗ разбирается на три типа подтверждения и один из четырёх статусов:

Evidence: (а) официальная публичная документация продукта; (б) материалы поставки — опросник, бюджетная оценка, протокол демо; (в) устный ответ поставщика на демонстрации.
Статус: соответствует · частично / требует подтверждения · не подтверждено · риск несоответствия.

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

2. Спорные зоны называются поимённо, а не «есть нюансы». Для разбираемого кандидата это:

OSA Proxy ≠ все пакетные менеджеры. Документация Proxy подтверждает Maven, NPM, PyPI, NuGet V3, Go, Debian, Alpine/APK, RPM, Docker Registry. А ТЗ дополнительно требует Conan, Conda, RubyGems в режиме Firewall — в proxy-режиме это не подтверждено (закрывается частично через плагины к Nexus/JFrog, что не то же самое). Статус: риск несоответствия.
C/C++ без пакетного менеджера. Build scan через агент/eBPF на GCC/Clang, CMake и make заявлен и обсуждался на демо; qmake прямо не подтверждён. Статус: частично, нужна демонстрация.
Готовые бинарники. Архивы (.jar, .whl, .nupkg, .tar.gz и пр.) и контейнеры — да; полноценная идентификация stripped-бинарей, .a/.so без сборочного контекста — ненадёжна (поставщик заявил это прямо). Статус: частично, граница термина «binary analysis» должна быть зафиксирована.
Reachability (проверка релевантности уязвимостей анализом вызовов) только Java/Python/Go; IDE-плагины — VS Code и IntelliJ-based, Qt Creator не покрыт.
Требования к исполнителю (лицензия ФСТЭК, ISO 9001, опыт, ИБ-подразделение) техникой не закрываются — это документы участника конкурса, их выносят в отдельный чек-лист.

Как выглядит на практике

Фрагмент рабочей матрицы (тот же приём, что в Матрица соответствия требованиям OSA SCA):

Требование ТЗ	Тип evidence	Подтверждение	Статус
Firewall для Conan/Conda/RubyGems	документация Proxy	в proxy-режиме не подтверждено; возможно через плагин Nexus/JFrog	риск несоответствия
Build scan C/C++ на qmake	устно на демо	make/CMake обсуждались, qmake — нет	частично → пилот
SBOM CycloneDX/SPDX в JSON	документация	форматы поддержаны, импорт/экспорт	соответствует
Анализ stripped `.a`/`.so`	устно на демо	поставщик: надёжно не решается	частично → зафиксировать границу

Слепые зоны именно этой темы - «Поддерживается» без указания режима. Поддержка Conan в SCA-манифестах не равна Conan в OSA Proxy Firewall — это разные подсистемы. - «Поддержка языка» ≠ «SCA-экосистема». ТЗ перечисляет Bash, Perl, SQL/PLSQL/PGSQL в одном списке с пакетными экосистемами. SCA анализирует зависимости и пакеты, а не произвольный синтаксис — требование надо уточнить, иначе статус заведомо «не подтверждено». - Offline vs on-premise. Опросник может быть заполнен как Offline, а ТЗ требует on-premise; в бюджетной оценке оба варианта. Это управленческий выбор, а не дефект — но не разрешив его, нельзя считать поставку соответствующей. - Демо-«да» без артефакта. Устный ответ — слабейший тип evidence; его нельзя оставлять как финальный статус по обязательному требованию.

Связь с нормативкой

Пилот — это не «потрогать продукт», а доказательная процедура. ГОСТ Р 56939-2024 (РБПО) и NIST SSDF (практики PW.4, RV.1) требуют использования и проверки инструментов анализа состава и происхождения компонентов; Проект ГОСТ Р КАПО прямо адресует композиционный анализ. Источники уязвимостей из ТЗ (NVD, GitHub Security Advisory, OSS Index, OSV, БДУ ФСТЭК) тоже проверяются как evidence, а не принимаются на слово.

Что уносим в работу

Разобрать ТЗ по строкам и расставить статусы по четырёхзначной шкале — без «в целом соответствует».
Каждое частично/риск превратить в конкретный сценарий пилота: Приемочные сценарии пилота.
Спорные C/C++ зоны проверять сборкой, а не исходниками: П31. Пилот CodeScoring make CMake qmake, C C++ build scan make cmake qmake.
Сравнение с альтернативой вести по своей боли (C/C++ build-level), а не по красоте витрины: П33. AppSec и CodeScoring сравнение по задаче.
Требования к исполнителю и комплект поставки оформить отдельно: Документы поставщика для закупки, Шаблон протокола пилота SCA инструмента.