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

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

dpkg apt metadata

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

Динамическая зависимость C/C++ видна как файл .so без имени компонента, версии и лицензии — голый путь вроде /usr/lib/x86_64-linux-gnu/libssl.so.3. Метаданные пакетного менеджера дистрибутива — это мост от этого пути к полноценной координате: dpkg/apt знают, какой deb-пакет владеет файлом, какая у него версия, из какого Source-пакета он собран и под какой лицензией поставлен. Без этого моста системная библиотека остаётся безымянным артефактом, который не матчится ни на что.

Для Debian/Ubuntu и совместимых (в т.ч. отечественных deb-сборок) это основной способ обогатить ELF-зависимость до уровня, пригодного для SBOM и матчинга. Связка «файл → пакет → версия → Source → лицензия» восстанавливает ровно те поля, которых требуют минимальные элементы SBOM, и делает это из данных, уже лежащих в системе сборки.

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

Полная цепочка от .so к координате идёт через несколько команд dpkg/apt:

$ ldd ./service | grep ssl
        libssl.so.3 => /usr/lib/x86_64-linux-gnu/libssl.so.3
$ dpkg -S /usr/lib/x86_64-linux-gnu/libssl.so.3
libssl3:amd64: /usr/lib/x86_64-linux-gnu/libssl.so.3
$ dpkg-query -W -f='${Package} ${Version} ${Source}\n' libssl3
libssl3 3.0.11-1~deb12u2 openssl          # Source ≠ Package — важно для CPE/upstream
$ apt-cache show libssl3 | grep -E '^(Homepage|Architecture)'
Homepage: https://www.openssl.org/
Architecture: amd64
$ cat /usr/share/doc/libssl3/copyright | head -1   # лицензия пакета

Отсюда собирается PURL pkg:deb/debian/libssl3@3.0.11-1~deb12u2?arch=amd64, а из поля Source: openssl — upstream-имя для CPE и нормализации версии. Без dpkg -S тот же .so остался бы pkg:generic/... без матчинга.

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

Слепая зона — metadata описывает только то, что установлено как deb-пакет. Если библиотека собрана из исходников и положена руками в /usr/local/lib, dpkg -S ответит «no path found» — пакетного владельца нет, и обогащать нечего. Так же dpkg ничего не знает о статически вшитых библиотеках и о файлах из third_party/. Приём: трактовать «нет владельца пакета» как сигнал «это не системная зависимость» и переводить такой артефакт в worklist ручной разметки, а не считать его отсутствующим.

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

  1. Снять список .so через ldd/readelf -d и для каждого выполнить dpkg -S <путь> — получить пакет-владельца.
  2. Для каждого пакета взять версию и Source через dpkg-query -W -f='${Package} ${Version} ${Source}' — Source нужен для CPE и upstream-версии.
  3. Собрать PURL pkg:deb/<distro>/<pkg>@<version>?arch=<arch>, сохранив arch (различающий qualifier).
  4. Лицензию брать из /usr/share/doc/<pkg>/copyright, не угадывать по имени.
  5. Файлы, для которых dpkg -S не нашёл владельца (/usr/local/..., third_party/, статика), выносить в реестр unresolved.
  6. Фиксировать дистрибутив и его версию: одна и та же .so в разных deb-средах имеет разные версии пакета.

Связь