Вот уже более 20 лет проходит масштабная конференция разработчиков свободного и открытого ПО – FOSDEM. Для CodeScoring она примечательна тем, что с 2021 года на ней регулярно представлен тематический деврум "SBOMS and supply chains", посвященный составу программного обеспечения и цепочкам поставок.

Эта статья – адаптация доклада "LibreOffice and Collabora Online – how we managed to automate SBOM generation for a large legacy project", с которым Торстен Беренц выступил на конференции в 2026 году. Специально для вас мы перевели выступление и превратили его в статью, оригинал доклада на английском языке – по ссылке.

Вернемся же к Collabora и истории о том, как в компании обзавелись своим собственным опытом создания SBOM для достаточно сложного продукта — Collabora Online, онлайн-офисного пакета с открытым исходным кодом, построенного на ядре LibreOffice.

Заголовок доклада обещает полностью автоматизированную генерацию SBOM, но реальность, как всегда, внесла свои коррективы. Автор доклада и его коллеги достигли определенных успехов, но это история о начале большого пути, а не о финише.

Передаем слово Торстену!

Об авторе: Торстен — эксперт LibreOffice и Collabora, глубоко разбирающийся в отраслевых стандартах. За свои 25 лет в проекте он успел покопаться в самых разных уголках кода: от системы сборки и библиотек абстракции платформы до Impress и Writer.

По образованию Торстен — программист, по призванию — фанат свободного ПО. Начинал ещё в Sun Microsystems, работал над известной альтернативой Microsoft Office, OpenOffice.org, а затем стал одним из основателей The Document Foundation и проекта LibreOffice.

Сейчас в его повседневной работе много проектного менеджмента и общения с заказчиками, но это не мешает ему время от времени всё ещё возиться с кодом. Недавно он объединил свою компанию с Collabora, чтобы с новыми силами помогать заказчикам переходить на суверенное открытое ПО.

С чего мы начинали и с чем столкнулись

Наша цель — полная прозрачность и отслеживаемость всех артефактов продукта, чтобы соответствовать требованиям CRA. Для контейнерных образов мы уже многое умеем, но Collabora Online — это особый случай, так как под капотом у нас технологический микс:

• ядро: LibreOffice Core (колоссальный проект на C++);

• фронтенд: JavaScript и TypeScript со своей экосистемой;

• нативные зависимости: более 100 библиотек на C/C++;

• «пограничники»: шрифты, словари, для которых нет готовых автоматических решений.

Вдобавок ко всему стандарты CRA до сих пор формируются, так что процесс напоминает ремонт автомобиля на полном ходу.

Первые шаги: ручной труд и выбор инструмента

Аудит текущего состояния SBOM выявил печальную картину — не было ничего. Мы изучили вопрос, пообщались с экспертами и, чтобы сдвинуться с мертвой точки, выбрали формат SPDX (без особых причин, просто надо было с чего-то начинать).

Первая и самая очевидная задача — собрать информацию о лицензиях. Для Collabora Online мы решили сделать это вручную, так как количество прямых зависимостей было управляемым. Мы составили список JavaScript-зависимостей (к счастью, там не было типичного npm-ада с тысячами вложенных пакетов), затем добавили шрифты, которые неожиданно обнаружились в консоли администратора.

С зависимостями C++ на верхнем уровне все было не очень хорошо — несколько десятков библиотек и сам LibreOffice Core. Мы добавили их вручную, но для автоматизации версий подключили систему сборки, чтобы она могла хотя бы подтягивать автоматически номера версий.

Шрифты, словари и прочие «простые» вещи

Казалось бы, шрифт — это просто картинка. Но нет. У него есть лицензия, значит, он должен быть в SBOM. Более того, это бинарный артефакт. А если копнуть глубже — механизмы хинтинга в шрифтах содержат настоящий код, выполняющийся в виртуальной машине. Это уже потенциальная поверхность для атаки. И для полной безопасности нам нужно знать версию шрифта, его хэш и проверять наличие CVE.

Со словарями ситуация немного проще (в основном лицензия), но и они должны быть в списке. В итоге, помимо кода, нам нужно учитывать еще 50 словарей и сотни шрифтов. Мы надеялись, что кто-то уже автоматизировал учет шрифтов в SBOM, но, к сожалению, на практике эта проблема не решена и соответствующие баг-репорты до сих пор открыты. Чуда не произошло.

LibreOffice Core

Итак, что у нас есть по состоянию на январь 2025 года? Для Collabora Online есть система, которая генерирует список лицензий для прямых зависимостей. Мы можем видеть 26 взаимосвязей и версии, полученные из системы сборки.

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

В поисках автоматизации для C/C++

Проблема в том, что для C и C++ нет единого стандарта сборки и менеджера пакетов, как, например, в Go, Java или Python*. Каждая библиотека может использовать свою легаси-систему. Но есть и хорошая новость: система сборки самого LibreOffice (довольно специфичная и основанная на OpenOffice, релиз которой состоялся в 2002 году) знает всё, что она собирает. Она динамическая, позволяет включать и отключать функции, и именно она в итоге упаковывает все в форматы DEB, RPM или MSI.

Мы решили пойти этим путем и написали патч, который вытаскивает из системы сборки линейный список всех зависимостей, которые реально попадают в продукт. Это позволило нам сгенерировать минимальный SBOM, включающий все сторонние компоненты и их лицензии.

*Прим. ред. Конечно, для C/C++ существуют менеджеры зависимостей, например, Conan и vcpkg. Но далеко не все проекты готовы переходить на них из-за исторически сложившихся систем сборки, требований к совместимости и устоявшихся процессов разработки. Поэтому в таких проектах часто приходится работать с тем, что уже знает их собственная сборочная система.

От лицензий к безопасности: требования BSI

CRA требует не просто наличие списка лицензий, а возможности оценивать уязвимости. Немецкое ведомство по безопасности BSI выпустило подробные рекомендации, которые, хоть и не являются обязательным, задают высокую планку.

Если следовать ему, то нам нужно для каждого файла на диске (включая скрипты Python, макросы и, возможно, шрифты) понимать его происхождение. А именно:

1. Имя компонента.

2. Контрольная сумма (для проверки целостности).

3. Идентификатор CPE (Common Platform Enumeration), чтобы привязать к нему CVE. Проблема в том, что для большинства старых C++ библиотек CPE просто не существует.*

4. Заявленная и фактическая лицензия (они могут отличаться).

5. Информация о системных библиотеках, с которыми слинкован бинарный файл (это ответственность дистрибутива, но мы должны это идентифицировать).

Это внушительный объем работы, который к тому же зависит от платформы: SBOM для Windows будет отличаться от SBOM для Linux.

*Прим.ред.: формально CPE-строку можно составить самостоятельно: это структурированный формат именования продуктов, а не идентификатор, который обязательно должен быть заранее зарегистрирован для каждой библиотеки. Однако для автоматического сопоставления с уязвимостями важна не только корректность строки, но и ее совпадение с тем, как компонент описан в публичных базах. Для старых C/C++ библиотек такой надежной привязки часто нет, поэтому самостоятельно составленный CPE может не помочь найти связанные CVE или, наоборот, привести к ложным совпадениям.

Что дальше?

Наш план — выжимать всю информацию из системы сборки. И если с прямыми зависимостями мы справились, то для получения полной картины (включая динамические связи и данные о сторонних библиотеках внутри Core) нам придется копаться в системах сборки. Это серьезная задача.

Самое печальное, что мы находимся на вершине стека. Мы не можем просто сказать «пусть авторы библиотек делают SBOM». Многие из этих библиотек поддерживаются одним человеком, и просить их еще и генерировать SPDX или CycloneDX — нереальная задача без дополнительного финансирования.

Заключение

Узнать больше о том, что мы делаем, вы можете на сайте CodeScoring.

А мы продолжим переводить для вас SBOM-доклады со свежего FOSDEM, и вы можете выбрать, какой доклад выйдет в блоге следующим, голосуйте в форме ниже!

Проголосовали 4 пользователя. Воздержавшихся нет.