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

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

sanitizers in CI

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

Санитайзеры (ASan, UBSan, TSan, MSan) — это динамические, тест-время проверки: они ловят ошибки памяти и неопределённое поведение во время выполнения тестов, а не описывают состав поставки. Связь с SCA непрямая, но важная: SCA говорит «в сборку входит vendored libfoo версии X», а санитайзер в CI отвечает на следующий вопрос — действительно ли этот код не падает на heap-overflow и use-after-free на ваших данных. Особенно это ценно для C/C++-кода, который SBOM перечисляет, но за который никто не отвечает: вкомпилированные third_party, форки, копипаста. Санитайзеры превращают «компонент присутствует» в «компонент проверен под нагрузкой тестов».

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

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

# отдельная сборка для CI, не для production:
cmake -DCMAKE_BUILD_TYPE=Debug \
      -DCMAKE_CXX_FLAGS="-fsanitize=address,undefined -fno-omit-frame-pointer -g" ..
cmake --build . && ASAN_OPTIONS=detect_leaks=1:abort_on_error=1 ctest

# типичный вывод ASan на ошибку в vendored-коде:
# ==1234==ERROR: AddressSanitizer: heap-buffer-overflow
#   READ of size 4 at 0x... thread T0
#     #0 in parse_header third_party/libfoo/parser.c:88

Важно: -fsanitize=address несёт overhead по памяти и скорости и не предназначен для production — это режим CI/тестов. В релиз идёт обычная сборка (см. hardening-флаги), санитайзеры остаются в пайплайне тестов.

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

Покрытие = покрытию тестов Санитайзер находит баг только на том пути, который реально исполнили тесты. Непокрытый код vendored-библиотеки останется без проверки, даже если он в SBOM. «ASan зелёный» означает «на прогнанных входах чисто», а не «кода без ошибок».

Слепая зона: запуск ASan только на unit-тестах при пустом фаззинге и отсутствии негативных входов — самые опасные пути парсеров так и не выполняются. Приём: сочетать санитайзеры с фаззингом (libFuzzer/AFL под ASan) на компонентах, разбирающих недоверенные данные.

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

  1. Завести отдельную CI-сборку с -fsanitize=address,undefined (Debug, -fno-omit-frame-pointer), не смешивая её с релизной.
  2. Никогда не тащить санитайзеры в production-бинарь — там hardening-флаги, а не ASan.
  3. Гонять санитайзеры в том числе по vendored/third_party-коду, который перечисляет SBOM, — это код без явного владельца.
  4. Подключить фаззинг под ASan для парсеров и обработчиков недоверенного ввода, чтобы покрыть опасные пути.
  5. Падение санитайзера в CI трактовать как блокирующее: настроить abort_on_error, фиксировать стек как evidence.
  6. Различать роли: санитайзер — runtime-проверка поведения, SCA — инвентаризация состава, статический анализ (CERT/MISRA) — соответствие правилам написания.

Связь