Как читать авторский курс и нормативные материалы

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

Кейс-задачи

Контрольные вопросы

Базовый уровень 1. Почему #include <openssl/ssl.h> не позволяет определить версию OpenSSL и факт линковки? Что в принципе можно узнать из заголовка, а что — нет? 2. Чем динамическая линковка (.so) отличается от статической (.a) с точки зрения видимости компонента в SBOM? 3. Какая запись в ELF-секции .dynamic перечисляет динамические зависимости и какими командами её прочитать? 4. Как путь к .so превращается в координаты компонента (имя пакета, версия, PURL)? Какие утилиты для этого нужны?

Средний уровень 5. Почему статическая линковка называется слепой зоной композиционного анализа? Куда «уходит» код libfoo.a после линковки? 6. Чем поздний скан готового бинаря хуже build-scan для полноты инвентаризации C/C++? Какую роль играет stripping? 7. Чем внутренний форк OSS опаснее для анализа, чем чистый апстрим той же библиотеки? Что меняется в профиле риска? 8. Когда в проекте есть Conan/vcpkg, что именно они дают для идентичности компонента по сравнению с pkg:generic/...? 9. Что такое unresolved library в C/C++ контексте и почему такой случай нельзя молча выбрасывать из SBOM?

Продвинутый уровень 10. Сырой cdxgen SBOM для C/C++ проекта нашёл 3 компонента, а readelf -d показывает 9 DT_NEEDED. Как объяснить расхождение и чем его закрыть? 11. Какие данные C/C++ проекта (исходники, бинарники, build-логи) допустимо отправлять во внешний облачный сервис без отдельного решения, а какие — нет? 12. Как enrichment-утилита («генератор фактов») повышает полноту: какие источники она объединяет и почему именно она, а не сервис вердиктов, отвечает за факты?

Кейс-задачи

Кейс 1. Тихий SBOM Соисполнитель прислал C++ компонент и cdxgen SBOM с двумя записями. ldd ./service выдаёт not a dynamic executable. Опишите, что именно произошло, почему SBOM пуст, и какие шаги (команды, артефакты, реестр) вы предпримете, чтобы восстановить состав и зафиксировать слепую зону.

Кейс 2. Неопознанная .so В readelf -d есть libcustomcrypto.so.1, но dpkg -S и apt-cache policy её не находят. Что это может быть (vendored, внутренний форк, ручная сборка)? Как доказать версию и происхождение, куда занести компонент и кто отвечает за доразметку? Сошлитесь на нужный шаблон.

Кейс 3. Динамика против статики Один и тот же релиз собирается в двух конфигурациях: динамической (для разработки) и статической stripped (для поставки). По SBOM поставочного бинаря OpenSSL «отсутствует». Объясните заказчику, почему это не значит, что OpenSSL не используется, и предложите процессное решение, дающее полный состав именно для поставочной сборки.