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

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

Astra Debian RPM среды

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

Маппинг ELF → системный пакет — основной способ дать .so координаты (имя пакета, версия, дистрибутив). Но команда такого маппинга зависит от пакетного менеджера: в DEB-мире это dpkg -S, в RPM-мире — rpm -qf. В отечественных средах сосуществуют оба: Astra Linux и Debian-подобные дистрибутивы используют DEB, а ряд платформ — RPM. Анализ, заточенный под один менеджер, на другой среде просто молчит: dpkg -S на RPM-системе бесполезен, и .so остаётся unresolved не потому, что компонента нет, а потому что спросили не тем инструментом.

Вторая причина — версии в отечественных репозиториях не равны upstream. Дистрибутив перепаковывает библиотеку под себя: своя ревизия (1.1.1n-0+deb11u5+astra...), свои бэкпорты безопасности, иногда свой набор патчей. Поэтому версия пакета из репозитория Astra — это не то же самое, что одноимённый релиз upstream, и для CVE-мэтчинга это критично.

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

На DEB-среде (Astra/Debian) .so сопоставляют через dpkg/apt, на RPM-среде — через rpm:

# DEB-среда (Astra Linux, Debian): .so → пакет → версия
ldd ./app | awk '/=>/{print $3}'                 # пути реальных .so
dpkg -S /usr/lib/x86_64-linux-gnu/libssl.so.1.1  # → libssl1.1: ...
dpkg -query -W -f='${Package} ${Version}\n' libssl1.1
#   libssl1.1 1.1.1n-0+deb11u5+astra...   ← версия с маркерами репозитория, не upstream

# RPM-среда: тот же ELF, другой менеджер
rpm -qf /usr/lib64/libssl.so.1.1                 # → openssl-libs-1.1.1k-7.el...
rpm -q --qf '%{NAME} %{VERSION}-%{RELEASE}\n' openssl-libs

# Какой менеджер вообще на среде — определяет всю стратегию маппинга
command -v dpkg >/dev/null && echo DEB || (command -v rpm >/dev/null && echo RPM)

Имя пакета между мирами тоже расходится: то же содержимое — это libssl1.1 в DEB и openssl-libs в RPM. Это прямой повод для CPE/PURL-алиасинга.

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

Слепая зона двойная. Первая — не тот пакетный менеджер: пайплайн с зашитым dpkg -S на RPM-среде выдаёт сплошной unresolved, и это выглядит как «зависимостей не нашли», хотя их просто спросили не той командой. Вторая — версия репозитория ≠ upstream: маркеры +deb11uX, +astra, .elN несут бэкпорты безопасности, поэтому applicability CVE по «голой» upstream-версии даёт ложные срабатывания.

Сначала определи менеджер, потом маппь Перед маппингом ELF на пакет определите среду: DEB (Astra/Debian) или RPM. Команда маппинга, имя пакета и формат версии различаются. Версию берите как есть, со всеми суффиксами репозитория, — именно репозиторная ревизия определяет, какие бэкпорты безопасности уже наложены.

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

  1. Определите пакетный менеджер среды сборки/исполнения и выберите команду маппинга (dpkg -S/apt для DEB-сред Astra/Debian, rpm -qf для RPM).
  2. Для каждой .so из ldd/readelf -d получите пакет и его полную версию с суффиксами репозитория (см. dpkg/apt metadata).
  3. Не нормализуйте версию к upstream «на глаз»: репозиторная ревизия несёт бэкпорты; учитывайте их при триаже CVE (см. version normalization).
  4. Сведите различие имён между DEB и RPM (libssl1.1 ↔ openssl-libs) в alias-таблицу для CPE/PURL (см. CPE alias для libssl3).
  5. Фиксируйте дистрибутив и его версию как контекст SBOM — без него координаты пакета неоднозначны.
  6. То, что не маппится ни одним менеджером, уносите в unresolved libraries.

Связь