Статическая линковка и форки

О чём

Предмет проверки — пробелы идентификации внутри сборки, которую мы контролируем. Даже когда build scan отработал и сборочный контекст есть, два класса кода плохо сопоставляются с известным пакетом+версией: статически слинкованный сторонний код и внутренние форки библиотек (vendored-копии, патченные ветки). Открытый вопрос — что система ловит автоматически, а что требует ручной разметки. Это отличается от случая «подали готовый бинарник без сборки» — там нет контекста вовсе (см. Ограничения готовых бинарников); здесь контекст есть, но компонент всё равно не распознан.

Граница с соседней темой «Готовые бинарники» = нам передали артефакт, сборки нет. «Статическая линковка и форки» = сборка наша и наблюдается, но vendored/forked/статический код не маппится на запись в базе компонентов. Разные причины одной проблемы — отсутствие чистого соответствия «файл → пакет → версия».

Что подтверждено

• C/C++ build scan через агент захватывает фактическую сборку (GCC/Clang, CMake/Make) и восстанавливает состав на этапе компиляции/линковки.
• Для пакетных экосистем разделение прямых/транзитивных зависимостей и граф поддержаны; механизм идентификации Open Source-включений по базе метаданных производителя в продукте есть.

Что не подтверждено или ограничено

• Статически слинкованный сторонний код в C/C++ без пакетного менеджера — зона риска: что именно build scan распознаёт в статике, на реальных сборках Организации не проверялось.
• Внутренние форки (vendored-копии, патченные библиотеки, отколовшиеся ветки) могут не сопоставляться с upstream-компонентом и его версией.
• Объём ручной разметки неопознанных компонентов не определён: сколько ручной работы потребуется и в каком интерфейсе она ведётся — неизвестно.
• Полноценная идентификация native .a/.so/исполняемых файлов без сборочного контекста ограничена (поставщик обозначил это как нерешённое) — пересекается с разрывом № 4.

Риск для достоверности SBOM Если статика и форки уходят в «неопознанное», SBOM по C/C++ legacy будет неполным, а значит часть уязвимостей и лицензионных обязательств останется невидимой. Для контура Организации, где Conan внедрён не везде и есть внутренние библиотеки, это ключевой риск достоверности — проверяется только на реальном проекте с форкнутой библиотекой.

Что проверить на пилоте

Вопросы и приёмочные проверки - Собрать тестовый C/C++ проект со статически слинкованной сторонней библиотекой и зафиксировать: распознан ли компонент и версия. - Включить в проект внутренний форк известной OSS-библиотеки (патченную копию) и проверить, маппится ли он на upstream. - Что система делает с неопознанным компонентом: помечает, требует ручной разметки, игнорирует молча? Где и как ведётся ручная разметка? - Насколько трудозатратна ручная разметка на типовом legacy-проекте Организации? - Как форк/статика отражаются в графе зависимостей и попадают ли в финальный SBOM.

Связь

• Матрица соответствия требованиям OSA SCA — разрыв № 4 (статическая линковка) и приёмочный сценарий с .a/.so, stripped binary и форкнутой библиотекой.
• Ограничения готовых бинарников — иной случай: артефакт без сборочного контекста.
• C C++ build scan make cmake qmake — механизм сборочного захвата, на котором держится идентификация.
• Приемочные сценарии пилота · Критерии Go No-Go после пилота
• Документация: https://docs.codescoring.ru/en/user-guide/agent/scan-build