Как убедиться, что код библиотеки не был изменен?

Любые Open Source проекты потенциально подвержены риску вредоносной модификации сторонними контрибьюторами и уязвимость может появиться на любом уровне распространения кода — от исходных текстов до двоичных артефактов, которые связываются с прикладными программами. Кроме того, нередко в библиотеках и подсистемах Linux обнаруживаются ошибки, которые могут привести к нарушению функционирования системы, аварийному завершению приложения или обходу механизмов безопасности и важно иметь возможность быстро обнаружить все затронутые этой ошибки компоненты и выполнить выпуск заплатки для 0-day уязвимости.

Для решения всех этих задач Linux Foundation в 2010 году предложил формат для описания юридических аспектов использования программного обеспечения (в частности, лицензии), происхождения артефакта (исходного кода или двоичного файла), способов контроля целостности объекта, а также зависимостей от других объектов. В 2021 году формат был принят как стандарт ISO/IEC 5962:2021 (спецификация SPVX V2.2.1) и является основой для определения SBOM (Software Bill of Materials), которые описывают зависимости компонентов, способы их верификации и описание цепочки поставок для валидации источника.

В статье мы обсудим общие принципы описания SPDX и инструменты (включая недавно открытый Microsoft SBOM Tool, ранее назывался Salus), для создания SPDX/SBOM (в том числе, для автоматической генерации на основании файлов спецификации зависимостей проекта).

Источник: Хабрахабр