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

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

cross-compilation

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

Кросс-компиляция ломает самое надёжное допущение C/C++ SCA: что библиотеки лежат в системе, на которой ведётся анализ. При сборке под другую архитектуру (ARM, MIPS, aarch64) код линкуется не с хостовыми /usr/lib, а с библиотеками из целевого --sysroot — отдельного дерева с заголовками и .so под целевую платформу. Поэтому маппинг «.so → пакет» нельзя делать инструментами хоста: dpkg -S и ldd на хосте дадут координаты не того окружения либо вообще откажутся работать с чужой архитектурой.

Это самая чистая слепая зона группы: аудитор по привычке снимает ldd на своей машине, получает правдоподобный список и не замечает, что версии и пакеты относятся к хосту, а не к тому, что реально слинковано под целевую платформу.

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

Архитектуру артефакта и источник его зависимостей определяет не хост, а заголовок ELF и sysroot:

Сначала определите целевую платформу

readelf -h app | grep Machine        # Machine: AArch64  → это НЕ хостовый x86-64
file app                             # ELF 64-bit LSB, ARM aarch64
ldd app
#  → "not a dynamic executable" или ошибка: хостовый ldd не умеет чужую архитектуру

ldd на хосте бесполезен. Резолвить зависимости нужно против sysroot цели.

Действие На хосте (неверно) Против sysroot цели (верно)
Список .so ldd app (ошибка/чужие пути) readelf -d app → DT_NEEDED + поиск в sysroot
Маппинг на пакет dpkg -S /usr/lib/... (хостовый пакет) dpkg-query в chroot/sysroot цели
Версия библиотеки версия хоста версия из sysroot/package DB цели

DT_NEEDED архитектурно-нейтрален readelf -d app читает секцию .dynamic любого ELF независимо от своей архитектуры и печатает DT_NEEDED (libssl.so.3, libc.so.6). Это даёт имена библиотек; версии и пакеты ищите в sysroot цели, а не на хосте.

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

Слепая зона — «правдоподобный, но хостовый» результат. Инструменты не падают, отдают список, и его принимают за состав, хотя версии относятся к машине аналитика. Усугубляет дело то, что toolchain-файл CMake (CMAKE_TOOLCHAIN_FILE с CMAKE_SYSROOT) и переменные --sysroot/PKG_CONFIG_SYSROOT_DIR задают целевое окружение в стороне от привычных системных путей — их легко не заметить.

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

  1. Определите целевую архитектуру артефакта: readelf -h (поле Machine) и file. Не доверяйте ldd хоста.
  2. Найдите sysroot сборки: CMAKE_SYSROOT в toolchain-файле, --sysroot в командах компилятора, PKG_CONFIG_SYSROOT_DIR.
  3. Снимите DT_NEEDED через readelf -d — это работает на любой архитектуре и даёт имена .so.
  4. Резолвите версии и пакеты против package DB целевого окружения (chroot/sysroot, dpkg-query/rpm в нём), а не хоста.
  5. Зафиксируйте версию кросс-toolchain и sysroot в provenance: один и тот же исходник под разные sysroot даёт разный состав.
  6. Если sysroot собран вручную из вендоренных библиотек — каждая такая .so идёт в worklist доразметки, координат у неё нет.

Связь