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

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

secure compiler flags

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

SCA отвечает на вопрос «какие компоненты внутри», но не на вопрос «как защищён сам бинарь». Флаги защитной компиляции (hardening) — это отдельный пласт: они не меняют список зависимостей, зато оставляют в готовом ELF проверяемые следы того, что код собран по требованиям РБПО. Ценность для аудита в том, что эти следы читаются прямо из поставленного артефакта, без доверия словам поставщика: включён ли стек-канарей, есть ли FORTIFY, собран ли бинарь как PIE с полным RELRO. Поэтому в досье поставки hardening стоит рядом с SBOM — это доказательство свойств самого артефакта, а не его состава.

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

Hardening не «детектируется как зависимость» — он верифицируется по самому бинарю. Аудитор не верит build-логу, а читает секции ELF.

# одной командой — сводка защит
checksec --file=./myapp
#   RELRO   STACK CANARY  NX   PIE   FORTIFY
#   Full    Canary found  NX   PIE   Yes

# вручную тем же readelf:
readelf -d ./myapp | grep -E 'BIND_NOW|FLAGS'     # Full RELRO: BIND_NOW + GNU_RELRO
readelf -h ./myapp | grep Type                     # Type: DYN  -> PIE
nm ./myapp | grep __stack_chk_fail                 # есть -> -fstack-protector
nm ./myapp | grep _chk                             # *_chk -> -D_FORTIFY_SOURCE

Соответствующие флаги сборки: -fstack-protector-strong, -D_FORTIFY_SOURCE=2 (или =3) с -O2, -fPIE -pie, -Wl,-z,relro,-z,now, -Wl,-z,noexecstack. Если в бинаре No RELRO, No canary, No PIE — сборка не прошла hardening, и это видно из артефакта.

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

Свойство артефакта, а не состава SBOM может быть идеальным, а бинарь — собран без единой защиты. Hardening и состав компонентов измеряются независимо: пройденный SCA ничего не говорит о RELRO/PIE, и наоборот. Проверять нужно оба, иначе досье поставки неполное.

Слепая зона: вендор присылает «безопасную» библиотеку, но .a/.so собраны без -fstack-protector/FORTIFY. Защита не наследуется автоматически — её надо проверять в каждом поставленном бинаре, а не только в своём коде.

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

  1. Сделать checksec/readelf-проверку hardening обязательной приёмочной операцией над каждым поставляемым ELF.
  2. Зафиксировать целевой профиль флагов (-fstack-protector-strong, -D_FORTIFY_SOURCE=2/3, -fPIE -pie, Full RELRO, noexecstack) и сверять артефакт с ним.
  3. Отдельно проверять hardening в бинарях от соисполнителей — их сборка вне вашего контроля.
  4. Различать «не включено» и «не применимо» (например, FORTIFY требует -O1+); фиксировать обоснование отклонений.
  5. Класть результат проверки в evidence-досье рядом с SBOM как доказательство свойств артефакта.
  6. Не путать с проверкой исходного кода: канарей и RELRO ловят последствия ошибок, но не заменяют статический анализ и инвентаризацию компонентов.

Связь