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

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

форки open source библиотек

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

Внутренний форк — это когда команда взяла open source библиотеку, наложила свои патчи (фикс под свою платформу, бэкпорт фичи, отключение «лишнего») и собирает её из своего репозитория. Для SCA форк ломает базовое допущение анализа уязвимостей: версия больше не определяет код. Сканер видит, скажем, openssl@1.1.1k, поднимает все CVE этой версии и применяет их — но форк мог уже бэкпортнуть фикс (тогда часть findings ложноположительные) либо, наоборот, отстать от upstream и не получить более поздних патчей (тогда есть реальные дыры, которых нет в «чистой» 1.1.1k). И то и другое искажает картину риска.

Лицензионная сторона не менее важна: патчи к copyleft-библиотеке (GPL/LGPL) порождают обязательства, а если форк выдаётся за upstream, эти обязательства теряются из виду. Форк должен честно описываться как «upstream-база + дельта», а не как официальный релиз.

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

Форк выглядит как библиотека с «правильной» версией, но его код не совпадает с официальным релизом. Разрыв виден при сверке с upstream:

# Версия, которую заявляет библиотека
grep -rhoE 'OPENSSL_VERSION_TEXT.*"[^"]+"' include/openssl/opensslv.h

# Но история репозитория показывает базу форка и наложенные коммиты
git log --oneline upstream/OpenSSL_1_1_1k..HEAD   # → список своих патчей поверх тега
git describe --tags                                # 1.1.1k-12-gA1B2C3 — 12 коммитов после тега

# Расхождение с эталоном: какие файлы изменены относительно upstream-релиза
git diff --stat OpenSSL_1_1_1k -- crypto/ ssl/

# В бинаре строка версии может остаться «чистой», хотя код пропатчен
strings libssl.so.1.1 | grep -i 'OpenSSL 1.1.1'

В SBOM такой компонент описывается как pkg:generic/openssl@1.1.1k с явной пометкой о модификации и, по возможности, со ссылкой на набор патчей в properties/pedigree (CycloneDX pedigree.patches).

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

Слепая зона — ложная применимость CVE по версии форка. Версия 1.1.1k для сканера значит один конкретный код, а у форка код другой. Без фиксации дельты вы либо тонете в ложных findings (фикс уже бэкпортнут), либо пропускаете реальные (форк отстал). Вторая слепая зона — обязательства по copyleft, возникшие из-за самих патчей.

«Версия та же, код другой» Никогда не выдавайте форк за upstream-релиз в SBOM. Запись openssl@1.1.1k без пометки о форке заставляет и сканер уязвимостей, и юридический workflow рассуждать о коде, которого в продукте нет. Применимость каждого CVE по форку проверяется триажем (VEX), а не доверием к номеру версии.

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

  1. Зафиксируйте базу форка: точный upstream-тег/коммит, от которого форк отведён (git merge-base, git describe).
  2. Сохраните дельту: git diff --stat <upstream-tag>..HEAD и список патчей; внесите их в pedigree.patches SBOM-записи.
  3. В SBOM пометьте компонент как модифицированный (а не чистый upstream); версию указывайте с суффиксом-дельтой, если форк ушёл от тега.
  4. Для каждого CVE базовой версии — отдельный триаж: бэкпортнут ли фикс в форке? Результат оформляйте как VEX (см. П35. VEX triage).
  5. Проверьте лицензионные обязательства от собственных патчей к copyleft-коду (см. М07. Лицензионная чистота).
  6. Заведите процесс синхронизации с upstream, чтобы форк не накапливал непропатченные CVE.

Связь