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

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

hash-based identification

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

Когда у C/C++ артефакта нет ни манифеста, ни читаемой строки версии, остаётся последняя зацепка — криптографический хеш файла. Если хеш .a/.so/бинаря совпадает с хешем известного артефакта из базы (дистрибутивный пакет, релиз upstream, ранее размеченная сборка), компонент идентифицируется однозначно: совпадение хеша не зависит от имени, пути и наличия debug-символов. Это особенно ценно для stripped-бинарей и статически слинкованных библиотек, где другие методы дают только догадку.

Обратная сторона — хрупкость. Хеш привязан не к «версии OpenSSL 3.0.11», а к конкретному байтовому артефакту. Любая пересборка с другим компилятором, флагами или цепочкой инструментов даёт другой бинарь и другой хеш при той же версии исходников. Поэтому хеш — сильное доказательство присутствия конкретного файла и слабое — версии, если артефакт собран не из эталонного дистрибутива.

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

SBOM хранит хеши в поле hashes; их сверяют с базой известных артефактов:

$ sha256sum /usr/lib/x86_64-linux-gnu/libssl.so.3
9f2c...e41a  libssl.so.3
# сверка с хешем файла из дистрибутивного пакета:
$ apt-get download libssl3 && dpkg-deb -x libssl3_*.deb /tmp/p
$ sha256sum /tmp/p/usr/lib/x86_64-linux-gnu/libssl.so.3
9f2c...e41a   # совпало → это именно дистрибутивная libssl3, не пересобранная

В CycloneDX тот же факт фиксируется при компоненте:

{
  "hashes": [
    { "alg": "SHA-256", "content": "9f2c...e41a" },
    { "alg": "SHA-512", "content": "be7d...0c19" }
  ]
}

Если же бинарь собран локально, его хеш не совпадёт ни с одним эталоном из дистрибутива при той же версии OpenSSL — идентификация по хешу не сработает, и придётся опираться на символы/строки версий.

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

Слепая зона — ждать совпадения хеша для самосборных артефактов. Своя сборка зависимости даёт уникальный хеш, которого нет ни в одной публичной базе, поэтому отсутствие совпадения не значит «компонент неизвестен» — значит «он не из эталонного дистрибутива». Приём: использовать хеш как подтверждение там, где есть эталон (системные пакеты, official-релизы), и как стабильный ключ дедупликации/целостности там, где эталона нет — фиксировать хеш в SBOM, чтобы при будущей пересборке заметить изменение артефакта.

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

  1. Для значимых бинарных артефактов считать и хранить хеш (sha256sum, b2sum); записывать его в hashes SBOM как evidence.
  2. Где есть эталон (дистрибутивный пакет, релиз upstream) — сверять хеш и помечать совпавшие записи высоким confidence.
  3. Для самосборных артефактов фиксировать хеш как baseline целостности, не ожидая публичного совпадения.
  4. Не выводить версию только из хеша при отсутствии эталона: хеш доказывает файл, а не версию исходников.
  5. Указывать алгоритм (предпочтительно SHA-256/SHA-512); не полагаться на устаревшие MD5/SHA-1 как на единственное доказательство.
  6. Использовать хеши для дедупликации одинаковых .so/.a, встречающихся в нескольких местах поставки (одна occurrences-группа).

Связь