Практическая работа: динамическая vs статическая линковка и полнота SBOM

Цель

На одном и том же C/C++ проекте увидеть, как состав ПО меняется в зависимости от способа линковки, и почему сырой cdxgen SBOM неполон без бинарного анализа. Результат — таблица «факт против SBOM» и заполненный реестр unresolved libraries.

Входные данные (зафиксировать)

Перед началом запишите: путь к тестовому проекту, commit/tag, версии gcc, cdxgen, readelf (--version), дистрибутив (cat /etc/os-release), дату анализа. Без этого результат невоспроизводим.

Порядок выполнения

Шаг 1. Собрать проект динамически

Тестовый проект линкуется с OpenSSL и zlib. Соберите с verbose-выводом линковки:

make VERBOSE=1            # или: cmake --build build --verbose

В строке линковки должны быть видны -lssl -lcrypto -lz. См. П19. C C++ make build inventory, П20. CMake dependency graph.

Шаг 2. Снять динамические зависимости из ELF

readelf -d ./app | grep NEEDED
ldd ./app

Выпишите все .so из DT_NEEDED. См. П22. ELF dynamic dependencies.

Шаг 3. Смаппить .so на DEB-пакеты

dpkg -S /usr/lib/x86_64-linux-gnu/libssl.so.3
apt-cache policy libssl3        # версия пакета для PURL

Для каждой .so получите пакет и версию → координата pkg:deb/<distro>/<pkg>@<version>.

Шаг 4. Пересобрать статически и сравнить

Соберите тот же проект со статической линковкой (например -static или -l:libssl.a -l:libcrypto.a), затем:

readelf -d ./app-static | grep NEEDED     # OpenSSL/zlib здесь НЕ появятся
readelf -s ./app-static | grep -i SSL     # символы остаются, если не stripped

Зафиксируйте: что пропало из DT_NEEDED по сравнению с шагом 2. См. П23. Статическая линковка как слепая зона.

Шаг 5. Сгенерировать cdxgen SBOM и сравнить с фактом

cdxgen -t cpp -o cdxgen-bom.json .

Сравните список компонентов из cdxgen-bom.json с фактом из шагов 2–4. См. П04. Генерация SBOM через cdxgen для C C++. Если есть Conan — добавьте conan graph info . --format=json (П21. Conan graph и package identity).

Шаг 6. Оформить реестр unresolved и вывод

Каждую .so без DEB-координаты и каждый статически вшитый/vendored компонент занесите в реестр unresolved libraries с ответственным.

Что вы должны увидеть

• Динамический бинарь: DT_NEEDED содержит libssl.so.3, libcrypto.so.3, libz.so.1; каждая маппится на DEB-пакет с версией.
• Статический бинарь: тех же записей в DT_NEEDED нет — OpenSSL/zlib «исчезли», хотя код в бинаре присутствует.
• cdxgen-bom.json: компонентов меньше, чем фактических зависимостей; у части нет версии/PURL — это и есть пробел, который закрывает обогащение (бинарный анализ ELF + маппинг на DEB).

Если не получилось

• ldd пишет not a dynamic executable → собрали статически (это ожидаемо на шаге 4) либо перепутали бинарь.
• dpkg -S отвечает no path found → библиотека не из системного пакета (vendored или ручная сборка) — это кандидат в unresolved, а не ошибка.
• cdxgen нашёл 0 компонентов → нет conanfile/CMakeLists с зависимостями; именно поэтому и нужен бинарный анализ.
• readelf -s пуст на статическом бинаре → бинарь stripped, символы вырезаны (слепая зона усилилась).

Критерий зачёта

Показать преподавателю: (1) таблицу «динамика vs статика» с DT_NEEDED для обоих бинарей; (2) минимум одну .so, смапленную на DEB-пакет с версией; (3) заполненный реестр unresolved libraries с ответственным; (4) одно предложение, почему сырой cdxgen SBOM здесь неполон и что должен дать build-scan.

Нормативная связка

ГОСТ Р 56939-2024 (управляемость работ), NIST SP 800-218 SSDF (PS.3.2, PW.4, RV.1), BSI TR-03183-2 v2.1.0 (качество SBOM).