Вот уже более 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 году. Специально для вас мы перевели выступление и превратили его в статью, оригинал доклада на английском языке – по ссылке.
Закон о киберустойчивости (Cyber Resilience Act, CRA, новые европейские требования к созданию ПО) поэтапно вступает в силу, и многим из европейских компаний нужно срочно разбираться со списками компонентов ПО (ППК/SBOM).
В России тема SBOM также встроена в контекст безопасной разработки: ГОСТ Р 56939-2024 относит композиционный анализ к обязательным процессам контроля сторонних компонентов и известных уязвимостей. То есть SBOM становится не просто документом, а частью регулярной работы с составом ПО.
Для продуктов с повышенным уровнем доверия или сертификацией правила формальнее – в рамках требований ФСТЭК России необходимо предоставлять перечень заимствованных компонентов в установленном формате.
Вернемся же к 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, макросы и, возможно, шрифты) понимать его происхождение. А именно:
Имя компонента.
Контрольная сумма (для проверки целостности).
Идентификатор CPE (Common Platform Enumeration), чтобы привязать к нему CVE. Проблема в том, что для большинства старых C++ библиотек CPE просто не существует.*
Заявленная и фактическая лицензия (они могут отличаться).
Информация о системных библиотеках, с которыми слинкован бинарный файл (это ответственность дистрибутива, но мы должны это идентифицировать).
Это внушительный объем работы, который к тому же зависит от платформы: SBOM для Windows будет отличаться от SBOM для Linux.
*Прим.ред.: формально CPE-строку можно составить самостоятельно: это структурированный формат именования продуктов, а не идентификатор, который обязательно должен быть заранее зарегистрирован для каждой библиотеки. Однако для автоматического сопоставления с уязвимостями важна не только корректность строки, но и ее совпадение с тем, как компонент описан в публичных базах. Для старых C/C++ библиотек такой надежной привязки часто нет, поэтому самостоятельно составленный CPE может не помочь найти связанные CVE или, наоборот, привести к ложным совпадениям.
Что дальше?
Наш план — выжимать всю информацию из системы сборки. И если с прямыми зависимостями мы справились, то для получения полной картины (включая динамические связи и данные о сторонних библиотеках внутри Core) нам придется копаться в системах сборки. Это серьезная задача.
Самое печальное, что мы находимся на вершине стека. Мы не можем просто сказать «пусть авторы библиотек делают SBOM». Многие из этих библиотек поддерживаются одним человеком, и просить их еще и генерировать SPDX или CycloneDX — нереальная задача без дополнительного финансирования.
Заключение
Мы прошли путь от полного отсутствия SBOM до минимально рабочего процесса, который закрывает вопросы лицензионной чистоты. Главный вывод, который мы сделали – формировать SBOM необходимо на этапе сборки: во-первых, содержимое компонентов ПО напрямую зависит от текущих параметров конфигурации, а во-вторых, поддерживать список компонентов вручную после сборки слишком трудоемко.
Впереди — самый сложный этап: детализация гигантской кодовой базы LibreOffice Core для выполнения требований безопасности CRA».
Если вы решали или сейчас решаете похожие задачи – обязательно расскажите о своем опыте в комментариях под этой статьей!
Почему мы решили перевести этот текст? CodeScoring – это российское решение для безопасной работы с open source, проверки совместимости лицензий, поиска секретов и анализа качества разработки. Например, мы единственные в России умеем разбирать зависимости C/C++ через анализ сборки. Подробнее об этом можно почитать вот здесь.
Узнать больше о том, что мы делаем, вы можете на сайте CodeScoring.
А мы продолжим переводить для вас SBOM-доклады со свежего FOSDEM, и вы можете выбрать, какой доклад выйдет в блоге следующим, голосуйте в форме ниже!
