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

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

П33. AppSec и CodeScoring: сравнение по задаче

Цель

Научиться сравнивать два класса инструментов не по маркетинговой таблице фич, а по одной конкретной боли Организации — достоверной инвентаризации C/C++ legacy-сборок без полной дисциплины пакетного менеджера. Проверяемый результат — заполненная решающая таблица, где по каждому критерию указано не «есть/нет», а тип evidence (документация / устно на демо / не подтверждено) и кто является первичным источником данных о составе C/C++ продукта. Зачёт — обоснованный вывод «кого берём в пилот как основного кандидата и почему», который выдержит вопрос «а это где подтверждено?».

Команда или действие

Это аналитическая практика без запуска инструмента (tools: []). «Действие» — структурированная процедура из четырёх шагов:

  1. Сформулировать решающий вопрос одной строкой. Не «какой инструмент лучше», а «кто является первичным источником истины о составе C/C++ продукта там, где нет Conan/манифеста». Всё, что не отвечает на этот вопрос, идёт во второстепенные критерии.
  2. Развести классы инструментов. ASPM/ASOC-платформа (оркестрация и корреляция результатов чужих сканеров, дашборды, дефекты, Jira) — это надстройка над данными. SCA/OSA с build-level анализом — это источник данных. Платформа-агрегатор не восстановит C/C++ компоненты, если первичный сканер их не извлёк.
  3. Заполнить таблицу с колонкой evidence. По каждому критерию: что заявлено, чем подтверждено (публичная документация / устно на демо / не подтверждено), и статус по четырёхзначной шкале модуля.
  4. Вынести вердикт по своей боли, а не по сумме галочек.

Заготовка решающей таблицы (заполнять по фактическим материалам, обезличенно):

Критерий Инструмент-агрегатор (ASPM + OSA/SCA) Инструмент build-level (кандидат пилота) Тип evidence Вывод по нашей боли
C/C++ без пакетного менеджера фактически сведено к Conan; build-level не подтверждён заявлен build scan через агент/eBPF устно на демо / документация ключевое для нас
Legacy make/CMake/qmake без манифеста источник слаб подход через анализ сборки, требует пилота устно / требует пилота проверять П31. Пилот CodeScoring make CMake qmake
Готовые бинарники (.a/.so, stripped) не подтверждено ограничено, акцент на сборке не подтверждено / устно риск у обоих
Кто первичный источник данных надстройка над чужими сканерами сам извлекает состав из CI/CD — решающий критерий
SBOM CycloneDX/SPDX есть есть, импорт/экспорт + граф документация паритет
Политики/блокировки сильная сторона есть в CI/CD документация паритет
Единая витрина (ASPM) сильная сторона не основной акцент документация агрегатор как будущая надстройка
Контроль качества/авторства (TQI) не профильно отдельный модуль документация плюс кандидата по расширенному ТЗ

Самая частая ошибка сравнения Сравнивать по числу «закрытых» фич в таблице. Платформа-агрегатор закроет много строк — но если она живёт поверх результатов других сканеров, то по C/C++ без манифеста источник данных у неё остаётся слабым, сколько бы галочек ни стояло. Один правильно поставленный критерий («кто первичный источник истины о составе») весит больше, чем десять второстепенных совпадений.

Что вы должны увидеть

Заполненная таблица, в которой видно расслоение evidence: часть критериев подтверждена публичной документацией, часть — только устным «да» на демо, часть — не подтверждена. Ключевой строкой должна стать «C/C++ без пакетного менеджера»: именно здесь два класса инструментов расходятся. Вывод формулируется в один абзац примерно так (ориентир, не шаблон для копирования):

Основной кандидат на пилот — инструмент с build-level анализом, потому что наша боль не агрегация чужих отчётов, а первичное извлечение состава C/C++ из сборки; агрегатор-платформу оставляем как возможную будущую надстройку ASPM, но не как первичное решение, пока build-level анализ без обязательного Conan не подтверждён пилотом.

Признак, что практика выполнена правильно: в выводе нет ни одного «лучше вообще» — каждое утверждение привязано к конкретной задаче и к типу подтверждения.

Если не получилось

Критерий зачёта

Предъявить преподавателю заполненную решающую таблицу (минимум 6 критериев, обязательно строка «C/C++ без пакетного менеджера» и «кто первичный источник данных») с колонкой типа evidence по каждому пункту, и вердикт в один абзац: кто берётся основным кандидатом на пилот и какие 2–3 приёмочных риска остаются открытыми. Вывод должен опираться на задачу Организации, а не на общую зрелость продукта. Гейт — none: это решение перед пилотом, а не CI-проверка.

Нормативная связка