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

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

CERT MISRA рядом с SCA

Почему это важно для SCA/OSA

CERT C/C++ и MISRA — это стандарты того, как написан ваш собственный код: какие конструкции языка запрещены, как обращаться с памятью, целочисленными переполнениями, указателями. SCA отвечает на ортогональный вопрос — какие чужие компоненты в сборке. Эти два среза не заменяют, а дополняют друг друга, и их легко спутать: «у нас чистый MISRA-отчёт» не означает «у нас нет уязвимой zlib в зависимостях», а полный SBOM ничего не говорит о том, нарушает ли ваш код CERT-правила работы с буферами. Понимать границу важно, чтобы в досье РБПО не выдавать один контроль за другой.

Как это проявляется

Инструменты разные, входы разные, выводы про разное. Статический анализатор правил смотрит исходники вашего кода; SCA смотрит граф компонентов.

# CERT: проверка правил написания кода
clang-tidy -checks='cert-*' src/parser.c --
#   warning: calling 'system' is insecure [cert-env33-c]
#   warning: do not use 'strcpy' [cert-str31-c]

# MISRA: проверка по своду правил
cppcheck --addon=misra --enable=all src/
#   [misra-c2012-21.3] dynamic memory allocation shall not be used

# SCA: это про состав, а не про правила — другой инструмент:
syft dir:. -o cyclonedx-json   # перечислит компоненты, но не нарушения CERT/MISRA

Показательно: clang-tidy с профилем cert-* найдёт небезопасный strcpy в вашем parser.c, но не заметит, что в сборку вкомпилирована уязвимая версия стороннего парсера — это зона SCA. И наоборот.

Слепая зона или приём

Чистый MISRA ≠ безопасный состав Отчёт «0 нарушений MISRA» относится только к проверенному собственному коду. Vendored-библиотеки обычно исключают из MISRA-анализа (чужой код, тонны нарушений), и именно там живёт уязвимая zlib/libpng, которую ловит только SCA. Принимать конформанс правилам за безопасность поставки — ошибка.

Приём: вести два независимых контроля в досье — конформанс CERT/MISRA по собственному коду и инвентаризацию + уязвимости по всем компонентам через SCA, и не закрывать пробел одного отчётом другого.

Что делать на проекте

  1. Развести зоны ответственности: CERT/MISRA — собственный код, SCA — состав и чужие компоненты; в досье это два отдельных раздела.
  2. Запускать clang-tidy -checks=cert-* и cppcheck --addon=misra по своему коду как отдельный gate, не смешивая с генерацией SBOM.
  3. Явно фиксировать, что vendored/third_party выведены из MISRA-анализа, и закрывать их SCA + санитайзерами.
  4. Не засчитывать чистый CERT/MISRA-отчёт как доказательство отсутствия уязвимых зависимостей — это разные метрики.
  5. Сводить оба контроля в нормативную трассировку РБПО: правила написания и композиционный анализ — обязательные, но разные требования.
  6. Спорные нарушения CERT/MISRA документировать с обоснованием (deviation), как и исключения по уязвимостям в SCA.

Связь