Билет 10

Теоретический вопрос

Почему в C/C++ строка #include <openssl/ssl.h> не является доказательством зависимости от OpenSSL? Объясните разрыв между тем, что видит препроцессор (заголовок в include-путях), и тем, что реально попадает в продукт (слинкованная библиотека с конкретной версией). Перечислите случаи, когда #include есть, а зависимости нет (header-only, неиспользуемый код, заглушка) и когда зависимость есть, а явного #include не видно (транзитивная линковка, вшитый статический код). Почему полнота состава достигается на этапе сборки, а не чтением исходников?

Практический вопрос

Мини-кейс Аудитор видит в исходниках 12 разных #include сторонних библиотек и предлагает занести все 12 в SBOM. Объясните, почему это породит и ложные записи, и пропуски. Опишите, какой артефакт сборки (build evidence — лог компиляции/линковки, перехват вызовов компилятора) превращает «видимый заголовок» в доказанный факт зависимости с версией.

# заголовок виден — но это ещё не факт линковки:
grep -r "#include <openssl" src/
# факт даёт только сборка с перехватом вызовов компилятора/линкера

Что должен показать ответ

• Источник факта: build evidence (лог компиляции/линковки, occurrences), а не перечень #include.
• Инструмент: build-scan / перехват вызовов компилятора; фиксация occurrences в CycloneDX.
• Владелец решения: трактовка «заголовок без линковки» и пометка слепой зоны — за специалистом композиционного анализа.
• Нормативная опора: ГОСТ Р 56939-2024, NIST SP 800-218 SSDF (PW.4, PS.3.2), BSI TR-03183-2 v2.1.0.
• Evidence: build log как аудиторский артефакт; occurrences, связывающие компонент с местом сборки.

Опорные материалы

• М09. C/C++ legacy без дисциплины пакетного менеджера
• П19. C C++ make build inventory · П20. CMake dependency graph
• include ≠ зависимость · build logs как evidence