Европейската агенция за киберсигурност ENISA публикува технически насоки за внедряване на списъци на софтуерните компоненти (SBOM), които помагат на организациите да проследяват зависимостите, да откриват уязвими библиотеки и да управляват рисковете по веригата на доставки. Агенцията предупреждава, че неточните, остарели или компрометирани SBOM могат сами да се превърнат в източник на риск.

SBOM не е просто списък с компоненти

В техническия си документ ENISA Technical Advisory for Software Bill of Materials агенцията разглежда SBOM като структурирана, машинночетима информация за компонентите на даден софтуерен продукт, техните версии, произход, лицензи и зависимости. Тези данни могат да подпомогнат управлението на уязвимостите, инвентаризацията на софтуерните активи, лицензионното съответствие и оценката на доставчиците.

ENISA препоръчва използването на утвърдени формати като SPDX и CycloneDX. Генерираните списъци трябва да бъдат проверявани спрямо реалните софтуерни артефакти, а когато е приложимо, да се подписват цифрово и да се интегрират в процесите за разработка, изграждане и внедряване на софтуер.

Ключовият извод е, че самото създаване на SBOM не осигурява защита. Стойността му зависи от това дали информацията се поддържа актуална и се използва в реалните процеси за управление на уязвимости, реакция при инциденти и вземане на решения за коригиращи действия.

Автоматизацията напредва, но остават съществени пропуски

Данните от проучването ENISA SBOM Adoption State of Play 2026 показват разминаване между информацията, от която организациите се нуждаят, и тази, която действително получават.

• 36% от анкетираните организации се нуждаят от SBOM, включващ всички основни компоненти и преките зависимости, както и изрично посочени известни неизвестни. Такъв обхват получават едва 29%.
• 24% се нуждаят от SBOM с пълно задълбочено анализиране на зависимостите, но само 14% получават такава информация.
• 27% изискват задълбочен анализ с декларирани известни неизвестни, докато само 12% получават SBOM, отговарящ на това изискване.

Показателите разкриват проблем, който не може да бъде решен единствено с внедряване на инструмент за генериране. Организациите трябва да определят какво ниво на детайлност им е необходимо, как ще проверяват пълнотата на данните и как ще документират компонентите, за които информацията е непълна или липсва.

Автоматизацията също остава неравномерна. 41% от организациите планират напълно автоматизирано генериране на SBOM за всяка версия или компилация, но едва 26% очакват напълно автоматизирано актуализиране на списъците през целия период на поддръжка на продукта. Това е съществено ограничение, тъй като софтуерните зависимости се променят и след първоначалното издание.

Интеграция в процесите за разработка

ENISA препоръчва генерирането на SBOM да започне още на етапа на изграждане на софтуера. Така зависимостите могат да бъдат установени, докато контекстът на компилацията е наличен, без да се налагат значителни промени в съществуващата инфраструктура.

Процесът може да включва:

• автоматично откриване на компоненти и извличане на метаданни от хранилища с изходен код, файлове за управление на пакетите, артефакти от компилации, контейнерни образи и двоични файлове;
• генериране на SBOM в стандартизиран формат като SPDX или CycloneDX;
• проверка на структурата, задължителните метаданни и идентификаторите на компонентите;
• цифрово подписване и съхранение в хранилище, достъпно за инструментите за сигурност;
• автоматично актуализиране при промени в кода, зависимостите или нови софтуерни издания.

Насоките разглеждат два основни модела за интеграция. При първия SBOM се генерира след успешна компилация. При втория процесът се задейства от събития в хранилището, например нов комит, заявка за промяна или публикуване на версия.

Въвеждането на автоматизирани проверки позволява невалидните или несъответстващите на политиките SBOM да бъдат спрени преди публикуване или внедряване. За целта са необходими ясни правила за обработка на грешки, повторни опити, съхранение, срокове за запазване и проследимост на резултатите.

Самите SBOM също трябва да бъдат защитени

ENISA прилага рамката STRIDE на Microsoft, която обхваща шест категории заплахи: подправяне на самоличност, манипулиране на данни, отричане на действия, разкриване на информация, отказ на услуга и повишаване на привилегиите.

Рисковете не се ограничават до съдържанието на списъка. Те засягат инструментите за генериране, процесите за проверка и подписване, хранилищата и интеграционните канали.

Нападател може например да подмени SBOM, да промени версии, хешове или данни за произхода на компоненти, или да компрометира инфраструктурата за подписване. Подобна манипулация може да доведе до погрешна оценка на зависимостите и пропускане на уязвимости. Затова ENISA препоръчва проверка на цифровите подписи, надеждно управление на ключовете, удостоверяване на участниците и контрол на целостта.

Съществува и риск от прекомерно разкриване на информация. SBOM може да покаже използваните технологии, конкретни версии на библиотеки, доставчици и взаимовръзки между компонентите. В неправилни ръце тази информация може да улесни разузнаването преди атака и да ускори търсенето на известни уязвимости. Контролираното споделяне и управлението на достъпа са особено важни, когато списъците съдържат чувствителни данни за архитектурата на продукта.

Допълнителни рискове са прекъсването на достъпа до хранилищата, обработката на прекомерно големи или сложно вложени файлове и повишаването на привилегиите в процесите за изграждане и подписване. Като мерки за ограничаване на тези заплахи се посочват резервирана инфраструктура, защита от атаки за отказ на услуга, ограничения за размера и броя на файловете, укрепване на анализаторите и строги правила за достъп.

От откриване на уязвимости към управляем риск

SBOM трябва да се свързва с процес за приоритизиране и отстраняване на уязвимости. ENISA препоръчва решенията да се основават не само на тежестта на дадена уязвимост, но и на възможността за експлоатация, изложеността на системата, критичността на продукта, наличието на корекция и приложените компенсиращи мерки.

Организациите следва да определят срокове за отстраняване, прагове за сериозност и процедури за ескалация. Необходимо е също да съхраняват доказателства за одити и проверки за съответствие – журнали, резултати от валидация, цифрови подписи, времеви отметки и връзки към конкретни версии на софтуера.

Особено внимание трябва да се отделя на зависимостите, които не могат да бъдат напълно идентифицирани, на липсващите данни от доставчици и на компонентите, предоставени единствено като двоични файлове.

За организациите, включително малките и средните предприятия, насоките на ENISA предлагат практическа отправна точка: започване с автоматизирано генериране при компилация, последвано от проверка, защита, актуализиране и интеграция с управлението на уязвимостите. Зрелият процес за SBOM не приключва с инвентаризацията – той трябва да превръща данните за софтуерните зависимости в навременни и проследими решения за сигурност.

Практически план: седем стъпки за внедряване на SBOM

За да извлекат реална полза от SBOM, организациите трябва да изградят процес, който обхваща целия жизнен цикъл на софтуера – от компилацията до поддръжката и извеждането му от употреба. Практическото внедряване може да започне със следните действия:

1. Направете инвентаризация на софтуера и зависимостите. Определете кои приложения, услуги, контейнери и външни компоненти са критични за дейността. Установете кои от тях се разработват вътрешно, кои се доставят от трети страни и за кои вече има налични SBOM.

2. Изберете стандартизиран формат и инструмент за генериране. Използвайте утвърдени формати като SPDX или CycloneDX. Проверете дали избраният инструмент открива не само преките, но и транзитивните зависимости, и дали извлича достатъчно информация за версиите, произхода и идентификаторите на компонентите.

3. Автоматизирайте генерирането при всяка компилация или версия. Интегрирайте SBOM в съществуващия процес за непрекъсната интеграция и доставка (CI/CD). Настройте автоматично генериране при успешна компилация или при публикуване на нова версия, така че всяко софтуерно издание да има съответстващ списък на компонентите.

4. Проверявайте пълнотата и автентичността. Преди публикуване валидирайте структурата и задължителните метаданни, сравнявайте описаните компоненти с реалните артефакти и проверявайте цифровите подписи, когато се използват. Документирайте неизвестните зависимости и липсващите данни, вместо да приемате, че непълният SBOM представлява пълна инвентаризация.

5. Свържете SBOM с процеса за управление на уязвимостите. Използвайте списъците, за да установявате кои продукти и системи са засегнати при публикуване на нова информация за уязвимост. Приоритизирайте реакцията според възможността за експлоатация, изложеността на системата, критичността на актива, наличието на корекция и приложените компенсиращи мерки. Определете срокове за отстраняване и ясни правила за ескалация.

6. Защитете SBOM и ограничете достъпа до тях. Съхранявайте списъците в контролирани хранилища, прилагайте подходящи права за достъп и защитавайте ключовете за цифрово подписване. Проверявайте целостта при публикуване и получаване. Не разпространявайте публично подробни списъци с вътрешни зависимости, версии и технологична архитектура, ако това не е необходимо.

7. Поддържайте актуалност и събирайте доказателства. Генерирайте нов SBOM при промяна на компонентите и проверявайте дали информацията остава актуална през целия период на поддръжка. Запазвайте версиите, резултатите от проверките, подписите, времевите отметки и решенията за обработка на установените уязвимости. Тези записи подпомагат разследванията на инциденти, одитите и демонстрирането на съответствие.

Как да измервате напредъка

Организациите могат да въведат няколко вътрешни показателя: дела на софтуерните издания с валидиран SBOM, процента на идентифицираните зависимости, времето от публикуване на информация за уязвимост до установяване на засегнатите активи, времето за отстраняване и броя на списъците с липсващи или непроверени данни.

Тези показатели трябва да отразяват реалното качество и използване на информацията, а не просто броя на генерираните файлове. Практическата цел е всяка установена зависимост да може да бъде свързана със съответния продукт, оценен риск и документирано решение.

Редакционна бележка: Седемте стъпки са практически препоръки, изведени от техническите насоки на ENISA, а не дословно представен задължителен списък на агенцията. Показателите за измерване на напредъка са предложени за вътрешно управление.