Код, пот и слезы: композиционный анализ проектов на С/С++

24.09.2026 17:07:42 | Хабр

Хабы: Блог компании CodeScoring, Open source, C, C++, Информационная безопасность

В экосистемах со сложившейся моделью пакетных индексов вроде Python, Java или JavaScript состав проекта обычно начинают анализировать с манифеста, где разработчик перечисляет прямые зависимости проекта и их допустимые версии. Менеджер пакетов читает эти требования, выбирает совместимые версии и подтягивает зависимости, которые нужны самим пакетам. Конкретный результат выбора сохраняется в lock-файле, где фиксируется уже не диапазон, а точные версии прямых и транзитивных зависимостей. В результате получается список всех пакетов, необходимых для работы с проектом.

В проектах на C и C++ такой общей записи, как правило, нет. Одну библиотеку могут устанавливать через менеджер системных пакетов, другую собирать из исходников в отдельном пайплайне, третью копировать прямо в каталог с исходным кодом проекта. Все они могут оказаться в рабочем приложении, хотя ни один источник не обязан перечислять их все в одном месте.

На крупной кодовой базе это быстро становится проблемой. Например, в нашем разборе автоматизации SBOM для LibreOffice в проекте была сотня с лишним C/C++ библиотек, собственная сборочная система и ресурсы вроде шрифтов и словарей, которые тоже попадают в поставку. За каждым компонентом такого SBOM стоит отдельное расследование от файла и команды сборки к имени проекта, версии и источнику. На каждом переходе теряется своя часть данных.

В CodeScoring мы анализируем состав программных продуктов и на практике часто сталкиваемся с ограничениями разных экосистем. Разбор проектов на C/C++ требует особого внимания. В этой статье мы разобрали особенности этой экосистемы, которые осложняют построение SBOM, и постарались рассказать, что позволяют выяснить разные методы анализа.

Подробнее

Читайте также