Как читать авторский курс и нормативные материалы
Это учебные материалы, а не заключение о соответствии конкретного продукта. Организационные модели курса отделяйте от терминов стандарта: ППК в опубликованном проекте — машиночитаемый перечень, а живой реестр его версий является практикой сопровождения. Термин OSA в разных материалах имеет разный охват. Статус и обязательность нормативного документа проверяются отдельно; проект КАПО опубликован как проект первой редакции.
План занятия (90 минут)
Цели
К концу занятия слушатель умеет:
1. объяснить, почему #include не равен зависимости и где между исходником и бинарём теряется информация о компоненте;
2. отличить динамическую линковку (.so, DT_NEEDED) от статической (.a, слепая зона) и снять обе картины инструментами ldd/readelf;
3. смаппить динамические библиотеки на DEB-пакеты через apt/dpkg -S и получить координаты (PURL);
4. оценить, чего не хватает в сыром cdxgen SBOM для C/C++, и сформулировать, что должен дозаполнить build-scan и ручная разметка.
Материалы и подготовка
- Стенд: Debian-based окружение (см. П01. Стенд WSL2 Docker и базовая гигиена), установленные
gcc,binutils(readelf,objdump),cmake,cdxgen; по возможностиconan. - Тестовый C++ проект, линкующийся с OpenSSL/zlib двумя способами: динамически и статически.
- Заметки справочника: ELF и DT_NEEDED, статическая линковка, dpkg/apt metadata.
- Шаблон: Реестр unresolved libraries.
Ход занятия
| Время | Блок | Формат | Содержание |
|---|---|---|---|
| 0–10 | Вводный кейс | лекция | C/C++ проект без Conan: cdxgen нашёл 3 компонента, реально их десятки. Где делась истина? Тезисы Census III о риске C/C++ и слабой идентичности. |
| 10–30 | Три слоя состава | лекция + доска | #include → исходная зависимость → динамика (.so) → статика (.a). Почему статика и stripped — слепые зоны. Роль build-scan и Conan. |
| 30–50 | Демо «бинарь не врёт» | демо | Сборка проекта дважды; readelf -d ./app (видим DT_NEEDED); ldd ./app; dpkg -S → DEB-координаты; затем статический бинарь — в DT_NEEDED пусто, ищем символы readelf -s. |
| 50–55 | Перерыв | — | — |
| 55–80 | Практика в парах | ПЗ | cdxgen -t cpp на проекте; сравнить с фактом из readelf/ldd; выписать unresolved .so; показать, как обогащение мапит ELF→DEB. См. 03 Практическая работа. |
| 80–90 | Рефлексия и регламент | обсуждение | Что заносим в реестр unresolved; какой gate в CI безопасен; что закрепить в регламенте Организации по приёмке C/C++ компонентов. |
Демонстрация (опорные команды)
make VERBOSE=1 # видим строки линковки (-lssl -lcrypto / -l:libssl.a)
readelf -d ./app | grep NEEDED
ldd ./app
dpkg -S /usr/lib/x86_64-linux-gnu/libssl.so.3
cdxgen -t cpp -o cdxgen-bom.json .
Контрольная точка
Слушатель на своём бинаре показывает: какие зависимости видны через DT_NEEDED, какие смаппились на DEB-пакеты, и какие компоненты остаются слепой зоной (статика/vendored/unresolved) — то есть отделяет доказанный факт от того, что требует build-scan или ручной разметки.
Темп Если группа слабее в Linux-инструментах, сократите Conan и расширьте блок
readelf/dpkg: главное — чтобы каждый своими руками увидел разницу между динамикой и статикой на одном и том же проекте.