Сканирайте SBOM, но не приемайте празния резултат за чист код

За да проверите SBOM за известни уязвимости, използвайте osv-scanner scan source -L ./sbom.spdx.json за SPDX или osv-scanner scan source -L ./bom.cdx.json за CycloneDX. Документацията на OSV-Scanner посочва тези файлови имена, параметъра -L и поддръжката на SBOM записи с Package URL (purl).

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

Вземете SBOM от правилната сборка

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

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

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

Пуснете сканирането и запазете резултата

Изпълнете командата от директория, в която посоченият път е валиден. Разширението има значение за разпознаването на формата: примерните имена завършват на .spdx.json и .cdx.json. Ако инструментът не намери пакети, проверете пътя, името, валидността на документа и дали компонентите му имат използваеми идентификатори, преди да тълкувате изхода като успешна проверка.

За машинно четим отчет използвайте osv-scanner scan source -L ./bom.cdx.json --format=json > sbom-scan.json; при SPDX заменете входния път. Описанието на изхода на OSV-Scanner посочва, че JSON се записва на стандартния изход, а код 0 означава намерени пакети без известни находки, код 1 — находки, и код 128 — че не са намерени пакети.

Разгледайте източника, пакетите и уязвимостите в отчета, но използвайте самия SBOM за проверката на пълнотата. Наличието на JSON файл не доказва, че всички компоненти от сборката са били разпознати. Ако скенерът приключи с грешка, запазеният отчет също не бива да се представя като успешен резултат.

Сверете инвентара с доставените компоненти

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

• Проверете преките и транзитивните зависимости. Ако компонент присъства в заключения файл, но липсва в SBOM, поправете генерирането на инвентара.
• Потърсете готови библиотеки, копирани в хранилището файлове и пакети, добавени при сглобяване на архива. Генератор, който чете само един пакетен мениджър, може да пропусне тези части.
• При контейнер сравнете инвентара и с компонентите от базовия образ. SBOM само за зависимостите на приложението описва по-тесен обхват от целия доставен образ.
• Отделете записите без конкретна версия или с липсващ, невалиден или двусмислен purl. Поправете идентификацията и сканирайте отново, вместо да броите тези компоненти за проверени.

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

Разграничете липсата на CVE от безопасността на кода

„Няма намерена CVE“ не означава „компонентът е безопасен“. OSV-Scanner търси съвпадения с известни записи за извлечените пакети. Уязвимост може още да не е публикувана, а наличен запис може да използва друг идентификатор, например такъв за предупреждение в пакетна екосистема. Затова не свеждайте прегледа само до броя на CVE идентификаторите.

Дори когато скенерът е намерил пакети и е върнал код 0, проверката има конкретен обхват: известните находки за разпознатите зависимости към момента на изпълнение. Грешен purl, неточна версия или липсващ компонент стесняват този обхват. За собствената логика на приложението, настройките и начина, по който се използва дадена библиотека, са нужни други проверки.

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

Добавете проверката към CI за същия артефакт

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

1. Сглобете продукта, генерирайте неговия SBOM и запазете файла заедно с идентификатора на артефакта.
2. Пуснете примерната стъпка test -s ./bom.cdx.json && osv-scanner scan source -L ./bom.cdx.json --format=json > sbom-scan.json. За SPDX посочете съответния .spdx.json файл.
3. Запазвайте отчета и при неуспешна CI стъпка, за да можете да разгледате находките. Оставете кода за изход да сигнализира за находка или липса на намерени пакети; не преобразувайте автоматично тези случаи в успешна проверка.

Условието test -s установява само, че файлът съществува и не е празен. То не проверява дали съдържа всички зависимости. Преди публикуване съпоставете SBOM със заключените версии и съдържанието на доставяния артефакт; така успешното сканиране ще се отнася до правилния и достатъчно пълен инвентар.

Прочетете също:

• „Безопасен“ резултат не оправдава подозрителен линк — проверете без кликване
• Cursor или GitHub Copilot: цената не казва кой пише по-добър код
• AI умения в CV: един измерим резултат тежи повече от десет инструмента