opentext Software Bill of Materials

Specifikace produktu

• Název produktu: Software Bill of Materials (SBOM)
• Popis: Seznam všech softwarových závislostí obsažených v softwarové aplikaci
• Funkčnost: Poskytuje pohled na vztahy dodavatelského řetězce při vývoji softwaru

Návod k použití produktu

Co je to Software Bill of Materials (SBOM)?
Software Bill of Materials (SBOM) je úplný seznam všech softwarových závislostí v aplikaci, včetně přímých a nepřímých závislostí.

Výhody SBOM
SBOM umožňuje uživatelům činit informovaná rozhodnutí o použití softwaru na základě přiložených balíčků a vybízí vývojáře, aby používali zabezpečené a aktualizované softwarové komponenty.

Metadata v SBOM
SBOM může obsahovat metadata, jako jsou podrobnosti o zranitelnosti, informace o licenci a vztahy mezi komponentami, aby poskytl graf dokončené závislosti.

Jak používat SBOM

1. Přístup k SBOM file pro softwarovou aplikaci, kterou používáte.
2. Review seznam závislostí pro pochopení zahrnutých komponent.
3. Zkontrolujte, zda metadata neobsahují zranitelnosti a licenční informace.
4. Pomocí těchto informací můžete činit informovaná rozhodnutí o používání softwaru.

Často kladené otázky (FAQ)

• Otázka: Proč je SBOM důležitý?
  Odpověď: SBOM poskytuje transparentnost softwarových komponent, pomáhá při přijímání informovaných rozhodnutí o používání softwaru a podporuje používání zabezpečeného softwaru.
• Otázka: Jaké informace obsahuje SBOM?
  Odpověď: SBOM obsahuje seznam všech závislostí, metadata o zranitelnostech, podrobnosti o licenci a vztahy mezi komponentami.

Potřeba softwarového kusovníku
Ať už vyrábíte, nakupujete nebo provozujete software, nahlédnutí do dodavatelského řetězce vám poskytne řadu výhod.

Softwarový kusovník

SBOM pomáhá organizaci poskytnout četné poznatky.
V tomto pozičním dokumentu probereme několik aspektů SBOM, včetně výhod a ovladačů pro přijetí, a ponoříme se trochu hlouběji do skutečných souborů a formátů SBOM. Začněme však definováním toho, co je SBOM.

Co je to softwarový kusovník?
Jednoduše řečeno, Software Bill of Materials (SBOM) je seznam všech softwarových závislostí, které jsou součástí softwarové aplikace. Zahrnuje nejen použité přímé závislosti, ale také závislosti používané těmito závislostmi, známé také jako nepřímé nebo tranzitivní závislosti. Jako takový popisuje vztahy dodavatelského řetězce používané při budování
software.

Seznam ingrediencí
Stejně jako potraviny v obchodě s potravinami mají na obalu napsaný seznam ingrediencí, můžeme si SBOM představit jako seznam ingrediencí pro softwarovou aplikaci. Pro alergiky lze seznam složek použít k ověření, že neobsahuje nic nežádoucího.
Lidé se často mohou chtít držet dál od neetického nebo nezdravého obsahu nebo věcí s příliš velkým množstvím nepřirozených chemikálií používaných pouze pro konzervaci, barvu nebo zisk. Seznam je povinný, protože chceme lidem umožnit, aby se informovaně rozhodovali o potravinách, které kupují.
Transparentnost také vyvíjí tlak na výrobce, aby nezahrnoval zbytečné špatné přísady, protože potravinu a výrobce lze nyní posuzovat podle přísad.
SBOM slouží k velmi podobnému účelu. Uvedením všech balíčků obsažených v softwarové aplikaci budou uživatelé moci činit informovaná rozhodnutí o tom, které aplikace použít na základě obsažených balíčků, a vývojáři budou motivováni k používání aktuálního, bezpečného a dobře udržovaného softwaru. .

Nejen ingredience
Často se používá analogie s přísadami. Ano, ukáže vám součásti, ze kterých se softwarový produkt skládá. Ale tím to nekončí. Při pohledu na nejběžnější dnes používané formáty SBOM je zde také podpora pro přidávání cenných metadat o komponentách.

• Jednoduše řečeno, Software Bill of Materials (SBOM) je seznam všech softwarových závislostí, které jsou součástí softwarové aplikace. Zahrnuje nejen použité přímé závislosti, ale také závislosti používané těmito závislostmi, známé také jako nepřímé nebo tranzitivní závislosti. Jako takový popisuje vztahy dodavatelského řetězce používané při vytváření softwaru.

Tato metadata mohou obsahovat podrobnosti o známých zranitelnostech komponenty. Mohou to být také podrobné licenční informace, tj. požadavky a omezení pro zahrnutí komponenty do jiného softwaru. Metadata mohou také zahrnovat, jak do sebe různé komponenty zapadají, tj. která komponenta závisí na ostatních komponentách.
Pokud jsou tyto vztahy úplné, SBOM může poskytnout úplný graf závislosti pro všechny součásti v softwaru.
I když je tedy analogie s ingrediencemi snadno pochopitelná, při plném využití možností SBOM v ní může být mnohem více.

Výhody a případy použití
SBOM lze použít k poskytnutí náhledu na váš software. Je neocenitelným nástrojem pro několik kritických obchodních operací souvisejících s vývojem softwaru, správou softwaru a spotřebou softwaru v celém hodnotovém řetězci.

Ne Stříbrná kulka
Než budeme diskutovat o výhodách, poznamenáváme, že SBOM ve skutečnosti sám o sobě žádné problémy nevyřeší. Aby bylo dosaženo pokroku, musí být doprovázeno organizačními procesytage údajů, které uchovává. S technickými nástroji a automatizacemi budete moci shromažďovat, prezentovat a přidávat obchodní hodnotu k datům v SBOM.
Díky tomu budou data použitelná a zlepší se zabezpečení softwaru a produktů. Umožní také organizacím, aby byly v souladu s licenčními i bezpečnostními požadavky. Za předpokladu, že jsou takové nástroje a procesy zavedeny, podívejme se na některé z výhod, které vám SBOM poskytne.

Zabezpečení
Hlavním předpokladem úspěchu je řízení rizik a snižování rizik, přičemž nejznámějším případem použití je zabezpečení. Je snadné argumentovat bezpečnostním případem. Všichni se chceme vyhnout nákladnému úniku dat. V roce 2022 se průměrné náklady na únik dat odhadovaly na 4.24 milionu USD. Zároveň jsou spolu s phishingem dva hlavní útoky, které dnes vidíme, pomocí známých zranitelností. Nyní k tomu přidejte, že počet objevených zranitelností neustále roste.
Se seznamem všech softwarových závislostí SBOM je možné a proveditelné posoudit, zda některá z těchto závislostí nemá známé bezpečnostní chyby. A pokud ano, víme, že je máme opravit. Bez SBOM, nebo alespoň bez podrobných přehledů o dodavatelském řetězci, které SBOM poskytuje, by nebylo možné skutečně zjistit, zda je software zranitelný nebo ne.
Jedná se o změnu hry pro ty, kteří si tento software kupují a používají. Pokud se objeví nová zranitelnost, mohou okamžitě posoudit, zda jsou odhaleni.

• Hlavním předpokladem úspěchu je řízení rizik a snižování rizik, přičemž nejznámějším případem použití je zabezpečení.
• Je snadné argumentovat bezpečnostním případem. Všichni se chceme vyhnout nákladnému úniku dat.

Soulad s licencí
Další výhodou je soulad s licencí. Pokaždé, když zahrneme kód napsaný někým jiným, např. Open-Source Software (OSS), používáme kód chráněný autorským právem. Bez licence nemůžeme tento kód použít. Licence nám řekne, co smíme s kódem dělat a za jakých okolností.
V některých případech jsou omezení a naše povinnosti poměrně těžké, pokud chceme zahrnout kód do distribuovaného softwaru. S SBOM získáváme přehled o závislostech třetích stran. Pak můžeme také vědět, jaké licence se vztahují na různé závislosti. Tyto licence lze také zapsat přímo do SBOM.

Závislost zdraví
Zabezpečení a soulad s licencí jsou dvě výhody, o kterých se v kontextu SBOM nejčastěji mluví. Zároveň vidíme, že používání OSS roste a dnešní codebase mají kolem 80–90 % OSS. Tato zvýšená závislost na OSS představuje nové výzvy, z nichž některé může SBOM pomoci splnit.
Jedna věc, se kterou se mnoho organizací potýká, je, jak vybrat nejlepší komponentu OSS pro konkrétní úkol. Existuje mnoho projektů OSS podporujících podobnou funkcionalitu, takže který z nich bychom si měli vybrat? Tato otázka je důležitější, než by se mohlo na první pohled zdát. Chcete projekt, který má trvalou podporu komunity, ne projekt, který byl nebo bude brzy opuštěn. Chcete také projekt, který opraví zranitelnosti, jinak neexistuje žádná bezpečná verze, na kterou by bylo možné upgradovat, a zdroj musíte opravit sami.
Můžete si také vybrat projekt, který zapojí zkušené vývojáře, projekt s přiměřenou dokumentací a možná projekt s aktivním základním týmem. Ačkoli neexistují žádné aktuální bezpečnostní chyby nebo rizika shody s licencí, všechny tyto vlastnosti budou přispívat k budoucímu riziku.
Mít inventář softwaru prostřednictvím SBOM pomůže při analýze softwarových závislostí pro taková budoucí rizika. Automatizovaný nástroj, jako je OpenText™ Debricked, automaticky naskenuje SBOM a nabídne vám řadu metrik, které vám pomohou porozumět stavu vašich softwarových závislostí.

Zvýšená transparentnost
Výhody zde nekončí. Použití dat k posouzení bezpečnosti, souladu s licencí a zdraví lze považovat za velmi přímé výhody. Musíme však také vzít v úvahu účinek nutnosti dodat SBOM, když je software distribuován nebo prodáván zákazníkům. S SBOM,
software již není černá skříňka. V tom, co dodáváte, je transparentnost.
Poskytovatel softwaru již nemůže skrývat špatné praktiky, pokud jde o záplatování a prověřování přiloženého softwaru, a dodržování licenčních podmínek musí být na prvním místě, abyste se vyhnuli právním problémům.

• Mít inventář softwaru prostřednictvím SBOM pomůže při analýze softwarových závislostí pro taková budoucí rizika.
• Automatizovaný nástroj, jako je Debricked, automaticky naskenuje SBOM a nabídne vám řadu metrik, které vám pomohou porozumět stavu vašich softwarových závislostí.

Když mají zákazníci přehled o komponentách aplikace, mohou také zkontrolovat zranitelnosti zabezpečení, shodu s licencí a prozkoumat software, zda neobsahuje zastaralé a nepodporované komponenty. A díky tomu mohou posuzovat své dodavatele podle jejich postupů při výběru a udržování závislostí.
To jasně podněcuje lepší postupy na straně dodavatele. Chyby zabezpečení ovlivní zákazníka, pokud budou zneužity, takže zákazník může vyvinout tlak na dodavatele, aby měl v aplikacích záplatovaný software. To povede k lepšímu, bezpečnějšímu a kompatibilnímu softwaru.

Silnější dodavatelsko-odběratelské vztahy
Dodavatel může SBOM také využít jako šanci získat silnější vztahy se svými zákazníky. Představte si organizaci, která si vybírá mezi dvěma dodavateli, z nichž jeden je schopen poskytnout podrobný a aktuální SBOM, zatímco druhý není ochoten nebo schopen tak učinit. Kterého byste si jako zákazník vybrali?
V jednom případě budete mít kontrolu nad prověřováním softwaru sami, pokud si to budete přát, a dodavatel je také motivován k tomu, aby měl správné softwarové postupy pro své součásti třetích stran.
V opačném případě kupujete černou skříňku bez možnosti kontroly komponent aplikace. A proč neposkytují SBOM? Je to proto, že prostě nemají nástroje nebo znalosti k jejich výrobě, nebo je to proto, že software má známé zranitelnosti? Nebo nevědí, zda existují zranitelnosti nebo ne? Používají spoustu zastaralého softwaru? Vědí vůbec, jestli ano? Žádný z důvodů není příliš lichotivý a jinak by dodavatel jistě šel po dodavateli, který poskytuje SBOM.
SBOM také usnadní průběžnou diskusi mezi dodavatelem a zákazníkem. Proč jste si vybrali tento software? Jsme zranitelní vůči tomuto novému CVE souvisejícímu s zahrnutou komponentou? Ano, bude pravděpodobně více otázek od zákazníků, některé dobré a některé méně relevantní, ale pro dodavatele je to příležitost ukázat osvědčené postupy během životního cyklu softwaru. To zvýší důvěru v dodavatele a zlepší vztah mezi zákazníkem a dodavatelem.

Snižte náklady na nápravu a dobu uvedení na trh
Oprava bezpečnostních problémů je tím nákladnější, čím později jsou hotové. Aktualizaci na zabezpečenou verzi závislosti lze snadno provést v době vývoje. Pokud to uděláte později, bude to složitější. Aktualizace softwaru, který je ve výrobě nebo který již byl distribuován, může být velmi nákladný.
Použití SBOM a doprovodného procesu pro sledování zranitelností, licencí a zdravotních informací umožní vývojářům rychle najít problémy. Tím se také sníží náklady na sanaci. Vlastně mít nástroj SCA pro sledování všech těchto věcí souvisejících se závislostmi se pravděpodobně rychle vyplatí, když jsou zranitelnosti, licence a stav nepřetržitě monitorovány.

• Oprava bezpečnostních problémů je tím nákladnější, čím později jsou hotové. Aktualizaci na zabezpečenou verzi závislosti lze snadno provést v době vývoje. Pokud to uděláte později, bude to složitější. Aktualizace softwaru, který je ve výrobě nebo který již byl distribuován, může být velmi nákladný.

S pečlivě zváženými volbami pro závislosti třetích stran doufejme, že v budoucnu bude s tímto softwarem méně problémů. To zahrnuje méně zranitelností, rychlejší procesy oprav, žádné problémy s licencí a lépe udržovaný software. Menší přidaná složitost umožní vývojářům zaměřit se více na výkon, stabilitu, uživatelskou zkušenost a přidané funkce. V konečném důsledku to zkrátí dobu uvedení na trh a umožní dodavateli být konkurenceschopnější.

Závěrem
SBOM představuje několik výhod pro všechny zainteresované strany. Ačkoli čisté výhody by měly stačit k okamžitému přijetí SBOM, často to nestačí k tomu, aby organizace překročily hranici. Přijetí někdy vyžaduje tlak ze strany vlád a úřadů. V další části budeme diskutovat o těchto hnacích silách, stejně jako o nově vznikajících hrozbách a výzvách, které se objevují, když čelíme přijetí SBOM.

Ovladače, motivátory a výzvy
SBOM nejsou nové, ale v poslední době se o ně zvýšil zájem. Pro mnoho organizací se změnilo z toho, co je hezké, na něco, co musíte mít. Tento posun je způsoben částečně novými požadavky na dodržování předpisů a částečně prostředím hrozeb kybernetické bezpečnosti.
Mnoho výhod, o kterých jsme hovořili dříve, jak pro dodavatele, tak pro zákazníky, významně přispělo k popularitě SBOM. Práce s SBOM však představuje řadu výzev, které je třeba si uvědomit a překonat. V této části se podrobněji podíváme na ovladače, motivátory a výzvy pro použití.

Shoda a regulační požadavky
Nové předpisy a požadavky se objevily od řady různých organizací, vlád a podobně. Tyto požadavky jsou reakcí na mnoho útoků na dodavatelský řetězec, kterých jsme byli svědky v posledních několika letech.

Výkonný příkaz pro kybernetickou bezpečnost
Snad nejvíce citovaný je Bidenův výkonný příkaz o kybernetické bezpečnosti z května 2021. Je třeba poznamenat, že soukromý sektor musí zintenzivnit hru, pokud má poskytovat systémy federální vládě USA. Pro zvýšení bezpečnosti softwarového dodavatelského řetězce je v objednávce uveden soubor požadavků, které musí být u těchto dodavatelů splněny.
Jedna část objednávky pojednává o SBOM a konkrétně vyžaduje, aby kupující obdržel SBOM spolu se zakoupeným softwarem. Národní správa telekomunikací a informací (NTIA) byla zároveň pověřena vytvořením seznamu minimálních požadovaných prvků takového SBOM.

Přijetí někdy vyžaduje tlak ze strany vlád a úřadů. V další části budeme diskutovat o těchto hnacích silách, stejně jako o nově vznikajících hrozbách a výzvách, které se objevují, když čelíme přijetí SBOM.

Navrhovaný zákon DHS
Souvisí to se zákonem HR4611—DHS Software Supply Chain Risk Management Act z roku 2021, což je navrhovaný zákon, který bude vyžadovat, aby dodavatelé Ministerstvu pro vnitřní bezpečnost (DHS) předložili SBOM spolu s certifikací, že v softwaru nejsou žádné bezpečnostní chyby. . Případně, pokud existují známé zranitelnosti, musí poskytnout jejich seznam.
Zákon EU o kybernetické odolnosti
V EU existuje návrh nařízení pro požadavky na kybernetickou bezpečnost, zákon Cyber ​​Resilience Act. Předpisy jsou povinné pro všechny členské státy. Zákon o kybernetické odolnosti mimo jiné ukládá výrobcům vypracovat SBOM. Na rozdíl od předpisů USA se toto nařízení EU bude vztahovat na všechny výrobce produktů s digitálními prvky, které se připojují k zařízení nebo síti. Na druhou stranu do SBOM je třeba zahrnout pouze závislosti nejvyšší úrovně.
Požadavek FDA
Pro konkrétní trhy v současnosti FDA prosazuje, aby SBOM byl povinným požadavkem pro zdravotnické produkty. Jde o reakci na zvýšený počet kybernetických bezpečnostních incidentů ve zdravotnictví, jak například uvádí Forbes. Data pacientů chráněná zdravotnickými produkty jsou navíc obvykle velmi citlivá a narušení služeb těmito produkty může ohrozit životy lidí.
Další pokyny
Kromě toho směrnice Národního úřadu pro bezpečnost silničního provozu zmiňují SBOM jako prostředek ke sledování zranitelnosti v procesu vývoje vozidla. Tyto pokyny jsou nezávazné a dobrovolné, ale zdůrazňují důležitost vnímanou v několika vertikálách.
Krajina hrozeb kybernetické bezpečnosti
Přijetí budou řídit požadavky a legislativa, ale tyto požadavky se objevují
od skutečné potřeby v průmyslu a společnosti. Prostředí kybernetických hrozeb je přítomno s předpisy nebo bez nich a mnoho podniků přijímá postupy SBOM bez ohledu na externí požadavky. Pojďme se krátce podívat na prostředí kybernetických hrozeb a na to, jak se vyvíjí.
Nové zranitelnosti
Za prvé, počet zranitelností registrovaných jako CVE v národní databázi zranitelností roste. V roce 2017 počet nových zranitelností vyskočil na více než 14,000 8,000 poté, co dříve nikdy nepřesáhl 2022 25,000 za rok. Od té doby se počet neustále zvyšuje a v roce XNUMX překonal XNUMX XNUMX.
Pokud zahrneme Advisory Database GitHub a ty, které jsou specifické pro daný jazyk, např. FriendsOfPHP a Python Packaging Advisory Database, existuje více zranitelností, ale existují významné překryvy.

• Požadavky a legislativa budou řídit přijetí, ale tyto požadavky vyplývají ze skutečné potřeby v průmyslu a společnosti. Prostředí kybernetických hrozeb je přítomno s předpisy nebo bez nich a mnoho podniků přijímá postupy SBOM bez ohledu na externí požadavky.

Zneužívání zranitelností je běžný vektor útoku
Známá chyba zabezpečení může být použita jako vektor útoku při porušení. S mnoha zranitelnostmi napříč řadou aplikací existuje více příležitostí k útokům. Když se podíváme na hlavní vektory útoků, jak je pozoruje IBM Security X-Force ve zprávě z roku 2022, 34 % bylo způsobeno zneužitím zranitelnosti, na druhém místě po phishingu. Organizace, které ve svém podnikání spoléhají na softwarové aplikace, tedy musí být na prvním místě oprava slabých míst zabezpečení.

Náklady na porušení
Je tedy zřejmé, že nedochází pouze k narušení způsobeným bezpečnostními chybami, ale jsou převládající. Přidejte k tomu; porušení je velmi nákladné. Globální průměrné náklady na únik dat způsobený zranitelností komponent třetích stran se odhadují na 4.55 milionu USD. Pokud zabezpečení aplikací neberete vážně, je jen otázkou času, kdy se tak stane.
Celkově vzato, prostředí kybernetických hrozeb vyžaduje investice do zabezpečení aplikací. Alternativa je prostě příliš nákladná. Vzhledem k tomu, že hodnocení a náprava bezpečnostních zranitelností je hlavním případem použití SBOM, je přirozené jej přijmout.

Spolehlivost na software
Software utváří naši společnost a každým dnem jsme stále více závislí na softwaru. V chytrém městě se snažíme optimalizovat pro udržitelnost a efektivitu prostřednictvím senzorů, aktuátorů, databází, komunikace a zpracování.
Údaje, které jsou shromažďovány, zpracovávány a ukládány, budou často citlivé, takže potřebujeme důvěrnost. Rovněž je zapotřebí ochrana integrity, aby se zajistilo, že data nebudou měněna během přenosu nebo v klidu. Všechny části a jejich funkčnost jsou řízeny softwarem.
Protože software ovlivňuje to, jak žijeme a pracujeme, potřeba mít lepší přehled o jeho vnitřním fungování se stává důležitější. K poskytnutí alespoň části tohoto náhledu lze použít SBOM.

Výzvy
Z předchozí diskuze by mělo být jasné, že SBOM tu zůstanou. Při generování a práci s SBOM je však třeba zvážit několik problémů. Nejde jen o to, vygenerovat SBOM a zavolat jej za den. Mít SBOM nemá velkou cenu, pokud jej nemůžete nebo nepoužíváte k zamýšleným účelům.

Úplnost
Úplnost odkazuje na SBOM včetně všech očekávaných dat. Při pohledu na různé formáty SBOM existuje podpora pro mnoho různých položek. Kompletní SBOM nemusí obsahovat všechna tato data. Místo toho musí pokrýt všechny softwarové komponenty, které se chystá zahrnout. Kromě toho, pokud existují informace o komponentě, u kterých lze očekávat, že budou zahrnuty, musí být zahrnuty.

• Při generování a práci s SBOM je třeba zvážit několik problémů. Nejde jen o to vygenerovat SBOM a zavolat jej za den. Mít SBOM nemá velkou cenu, pokud jej nemůžete nebo nepoužíváte k zamýšleným účelům.

Chybějící komponenty
Pokud informace chybí, např. existuje komponenta softwaru s otevřeným zdrojovým kódem, která je použita, ale není zahrnuta v SBOM, představuje to riziko pro přijímající organizaci. Mohlo by to znamenat kritické zranitelnosti, které nelze uvést a posoudit. Může to také znamenat, že aplikace používá komponentu s nepermisivní licencí způsobem, který porušuje licenci. Kromě rizik zabezpečení a souladu s licencí sníží neúplné SBOM důvěru v poskytovatele a mohou zpozdit dobu uvedení aplikace na trh.
Chybějící informace
Totéž platí pro součásti s otevřeným zdrojovým kódem, které jsou součástí, ale informace o
součástka je neúplná. V mnoha případech jsou informace o zranitelnosti zapsány přímo
v SBOM. Pak, pokud jsou informace o zranitelnosti převzaty pouze z NVD, budou pravděpodobně existovat zranitelnosti, které jsou přítomny, ale nejsou zahrnuty.
Známé neznámé
Lze namítnout, že neúplný SBOM může být horší než žádný SBOM. Pokud si myslíme, že SBOM je kompletní, budeme mít falešný pocit bezpečí, možná zklameme stráž a nejsme plně připraveni zvládnout zneužitou bezpečnostní zranitelnost. Se znalostí zranitelnosti, i když není opravena, lze přijmout další opatření, aby se zabránilo zneužití a porušení.
Pro pomoc se „známými neznámými“ mají běžné formáty SBOM podporu pro indikaci, zda je vztah závislosti (možná) neúplný nebo zda byly všechny vztahy započítány.
Aktuální
SBOM není jednorázová věc. Je to pohyblivý cíl, který je třeba udržovat v aktuálním stavu. Se zastaralým SBOM přichází stejná rizika jako s neúplným, chybnými údaji.
SBOM může být zastaralý z různých důvodů. Aplikace průběžně vyvíjená a aktualizovaná bude mít brzy zastaralý SBOM. Budou použity nové závislosti, některé budou aktualizovány na novější verze, zatímco jiné mohou být odstraněny.
Jakákoli hodnocení založená na zastaralých SBOM mohou obsahovat chyby. Chyby zabezpečení lze přehlédnout, zatímco některé již mohou být opraveny. Prvním je bezpečnostní problém a druhý představuje režii vývojářům a bezpečnostním analytikům, protože hodnocení bude mít falešně pozitivní výsledky.

Zastaralá externí data
SBOM může být také zastaralý, pokud jde o externí data, která může poskytnout. Bezpečnostní slabiny jsou neustále odhalovány. Pokud SBOM obsahuje seznam známých zranitelností, např. identifikátory CVE, bude takový seznam zastaralý, jakmile se objeví nová zranitelnost ovlivňující kteroukoli ze zahrnutých komponent.

• Jakákoli hodnocení založená na zastaralých SBOM mohou obsahovat chyby. Chyby zabezpečení lze přehlédnout, zatímco některé již mohou být opraveny. Prvním je bezpečnostní problém a druhý představuje režii vývojářům a bezpečnostním analytikům, protože hodnocení bude mít falešně pozitivní výsledky.

To by nemělo být žádným překvapením a při pohledu na pokyny, jak používat specifikaci SPDX, je dokonce výslovně uvedeno, že „spotřebitelé SPDX by měli vždy předpokládat, že zranitelnosti vyjmenované tvůrcem SPDX jsou zastaralé“. Kvůli potřebě mít aktuální SBOM je důležité zahrnout také časový údajamp.

Automatizace a SCA
Pro pomoc při vytváření SBOM je téměř vždy nutná automatizace. V dnešním softwaru je prostě příliš mnoho závislostí a je příliš mnoho informací, které je třeba shromažďovat a udržovat v aktuálním stavu, abyste to mohli dělat ručně. Automatizovaný nástroj je méně náchylný k chybám a dokáže vygenerovat úplný SBOM za zlomek času ve srovnání s manuálními procesy.
Namísto neustálé aktualizace SBOM kvůli externím změnám lze použít nástroj SCA ke sledování zranitelností, upozornění, když se objeví, a dokonce vám pomůže je opravit. To bude vždy poskytovat aktuální view rizik. Pro vývojáře, integrací úložišť kódu s nástrojem SCA, view se také aktualizuje, když jsou nové nebo aktualizované součásti.

Akční
SBOM je k ničemu, pokud informace v něm nejsou použity. Sama nic nezmůže, a proto je klíčové, aby byla akceschopná. To znamená, že obsah SBOM musí být ve formátu, který lze snadno konzumovat, a že jeho obsah lze použít pro případ použití, pro který je generován. Znamená to také, že musí být zavedeny organizační procesy pro použití SBOM, když je přijat.

Zacílení na případ použití
SBOM pouze s licenčními informacemi by mohl být dostačující, pokud se bere v úvahu pouze soulad s licencí, ale ne, pokud potřebujete potvrdit, že neexistují žádné chyby zabezpečení. Chcete-li použít SBOM k vytvoření zprávy o přiřazení pro vaše použití softwaru s otevřeným zdrojovým kódem, musí být zahrnut také text licence. S licenčním názvem nestačí.

Závěrem
Současné prostředí hrozeb s rostoucím počtem zranitelností a útoků by mělo být dostatečnými hnacími silami pro přijetí SBOM v širším měřítku. Pokud to nestačí, tlak regulací a úřadů jistě pomůže organizacím správným směrem.
Jak jsme však viděli, není to jen otočit vypínačem a nechat vše fungovat na dvě zatřesení jehněčím ocasem. Pro účelné nasazení je třeba zvážit některé výzvy.
Existuje několik dobře definovaných formátů pro kódování informací SBOM, které pomohou posouvat se vpřed, mají automatizaci a interoperabilitu mezi organizacemi.
Hlavní formáty, SPDX a CycloneDX, budou popsány v další části

• Současné prostředí hrozeb s rostoucím počtem zranitelností a útoků by mělo být dostatečnými hnacími silami pro přijetí SBOM v širším měřítku. Pokud to nestačí, tlak regulací a úřadů jistě pomůže organizacím správným směrem.

Softwarový kusovník: SBOM File

Existuje několik různých formátů pro ukládání a kódování informací SBOM. Nejznámějším zaměřením na transparentnost dodavatelského řetězce jsou formáty SPDX a CycloneDX.
V tomto příspěvku se hlouběji ponoříme do těchto formátů a poskytneme jejich srovnání. Krátce také diskutujeme o SWID tags, který lze také použít pro informace SBOM, ale má poněkud jiný cílový případ použití.

Minimální prvky NTIA
Výkonný příkaz pro kybernetickou bezpečnost nařídil (mimo jiné) Národní správě telekomunikací a informací (NTIA), aby zveřejnila sadu minimálních prvků pro SBOM. Tyto prvky jsou rozděleny do tří kategorií.

• Datová pole
• Podpora automatizace
• Praktiky a procesy

Pojďme si tyto kategorie probrat trochu podrobněji.

Datová pole
Datová pole definují, jaká data by měl SBOM obsahovat. Toto je minimální množství informací požadovaných pro každou komponentu, stejně jako metadata pro samotný soubor SBOM. Je definováno sedm datových polí. Jedná se o dodavatele komponenty, název komponenty, její verzi, další jedinečné identifikátory, vztah mezi závislostmi, tj. které komponenty jsou používány komponentou, autor SBOM a timestamp.
Další jedinečné identifikátory umožní mapování informací o komponentách na známá zranitelnost a licence. Taková mapování předpokládají, že komponenta není zaměňována s jinými komponentami podobného názvu. Hlavní jedinečné identifikátory jsou CPE, PURLa SWID.

Podpora automatizace
Obrovské množství komponent a jejich vztahů vyžaduje podporu nástrojů pro čtení i generování SBOM. Automatizace a podpora nástrojů také zajistí interoperabilitu mezi organizacemi. Vzhledem k tomu, že SBOM budou často poskytovány od dodavatele kupujícímu/spotřebiteli, je taková interoperabilita pro jeho použití klíčová.
Zatímco automatizace vyžaduje strojově čitelný formát, SBOM by měl být čitelný i pro člověka. Pomůže vám to s ručním odstraňováním problémů a rychlým opakovánímview určitých specifických údajů v SBOM. Pro podporu těchto požadavků vyžaduje NTIA použití jednoho z datových formátů SPDX, CycloneDX nebo SWID pro SBOM. Tento seznam může být v budoucnu rozšířen, ale proprietárním formátům je třeba se výslovně vyhnout.

• Obrovské množství komponent a jejich vztahů vyžaduje podporu nástrojů pro čtení i generování SBOM.

Praktiky a procesy
NTIA definuje několik minimálních požadavků na procesy kolem vytváření a správy SBOM. Pokud jde o frekvenci generování SBOM, musí být generován pokaždé, když je k dispozici nová verze softwaru.
Závislosti používané v softwaru lze vnímat jako stromovou hierarchii s přímými závislostmi nahoře a nadřazenými tranzitivními závislostmi níže. SBOM musí minimálně zahrnovat všechny přímé závislosti nejvyšší úrovně. Ty by měly být dostatečně podrobné, aby bylo možné najít tranzitivní závislosti. Kromě toho musí být jasné, zda neexistují žádné další tranzitivní závislosti nebo zda přítomnost takových závislostí není známa.
NTIA také zdůrazňuje, že je důležité začít s generováním a poskytováním SBOM co nejdříve. To zahrnuje souhlas s tím, že SBOM může mít některé počáteční chyby a opomenutí, ale namísto čekání na dokonalost by měly postupy SBOM začít dnes.

Dva hlavní formáty: SPDX a CycloneDX
Existují dva hlavní formáty SBOM, které jsou široce používány a přijímány. SPDX, který je udržován a podporován Linux Foundation, a CycloneDX, udržovaný a podporovaný OWASP.
Podívejme se krátce na soubory SPDX a CycloneDX, abychom získali představu o informacích, které mohou obsahovat. Oba formáty podporují mnohem více dat, než je zde uvedeno, a podrobnosti naleznete v příslušných specifikacích. Zde uvedené informace jsou založeny na SPDX v2.3 a CycloneDX v1.4.

Uvnitř SPDX SBOM File
SPDX SBOM se skládá ze sady sekcí. První část, která je povinná, jsou metainformace o souboru SPDX. Toto se nazývá Informace o vytvoření dokumentu. To zahrnuje např. to, kdy byl SBOM vytvořen, jaký nástroj byl použit k jeho vytvoření, na jaké verzi SPDX je založen a další dokumenty SPDX, na které se v tomto dokumentu odkazuje.

INFORMACE O BALENÍ
Pak jsou zde sekce pro každý z balíčků. Každý balíček obsahuje základní informace o jeho názvu, verzi a umístění stahování. Existuje také jedinečný identifikátor, který bude použit v dokumentu SPDX k odkazování na další informace.
Sekce balíčku také obsahuje licenční informace, a pokud různé soubory v balíčku mají různé licence, pak může být uveden úplný seznam všech nalezených licencí v balíčku. Sekce balíčků v SPDX má také podporu pro volné textové komentáře k licencím, text o autorských právech a další typy volných textových komentářů k balíčku obecně.

• Existují dva hlavní formáty SBOM, které jsou široce používány a přijímány. SPDX, který je udržován a podporován Linux Foundation, a CycloneDX, udržovaný a podporovaný OWASP.

BEZPEČNOSTNÍ INFORMACE V EXTERNÍCH REFERENCÍCH
Důležitým polem je pole pro externí reference. Toto pole lze použít k odkazování na externí zdroj pro další informace o balíčku.
Jednou z definovaných kategorií pro externí informace je zabezpečení, které lze použít k propojení s radami, opravami, popř URLs informacemi souvisejícími s bezpečností. Doporučení může obsahovat odkazy na CVE, dokument dodavatele o odhalení zranitelnosti nebo dokonce bezpečnostní informace zformátované v souboru CycloneDX SBOM.

FILES A ÚRYVKY
Po informacích o balíčku je také možné přidat informace o konkrétních souborech uvnitř balíčku. Tyto informace jsou uvedeny v samostatné části za příslušnou částí balení. Další podrobnosti mohou být uvedeny v další části odkazující na konkrétní úryvky uvnitř souboru. Na tyto úryvky lze odkazovat pomocí rozsahů bajtů nebo čísel řádků a mohou mít licence, které se liší od zbytku souboru nebo balíčku.

POPIS GRAFU ZÁVISLOSTI
V sekcích balíček, soubor a úryvek jsou data uvedená v každém prvku nezávislá na ostatních. Vztah mezi balíkem a jeho soubory je implicitní v tom, že sekce soubory následuje odpovídající sekci balíku. Ale také mohou existovat vztahy mezi soubory a, což je možná důležitější, vztahy mezi balíčky. Jeden balíček obvykle závisí na jiném balíčku a existují přechodné závislosti, takže jeden balíček bude záviset na balíčku, který zase závisí na třetím balíčku atd.
Tyto vztahy mezi komponentami jsou popsány v jejich vlastní části. Vztah může být jedním z mnoha, ale „závisí na“ a „závislost na“ jsou užitečné pro popis grafu závislosti pro software.
Vztah může být také označen, aby naznačil, že část grafu může být neúplná nebo že tvůrce ujišťuje, že je kompletní.

Uvnitř CycloneDX SBOM File
Podobně jako SPDX, CycloneDX začíná identifikačními informacemi a metadaty. To specifikuje, že se jedná o CycloneDX SBOM, které verzi specifikace odpovídá, a verzi SBOM pro tento konkrétní software. Pak je tu např. timestamp a identifikátor nástroje použitého ke generování SBOM (nebo autora, pokud byl vytvořen ručně).

KOMPONENTY
Po metadatech jsou popsány komponenty. Typ komponenty je definován jako např. soubor, kontejner, knihovna nebo aplikace. Některé důležité informace o komponentě zahrnují typ, název a verzi komponenty.

• Podobně jako SPDX, CycloneDX začíná identifikačními informacemi a metadaty. To specifikuje, že se jedná o CycloneDX SBOM, které verzi specifikace odpovídá, a verzi SBOM pro tento konkrétní software.

Aby byl jedinečně identifikovatelný, může také obsahovat jeden nebo několik CPE, PURL nebo identifikátory SWID. To umožní použití souboru SBOM k identifikaci a sledování nových zranitelností v softwaru. Informace o komponentě budou také obsahovat informace o licenci. Bude obsahovat licenční ID, ale může také obsahovat samotný text licence nebo a URL ukazující na licenční soubor. Každá součást může také obsahovat identifikátor bom-ref, který lze použít k odkazování na součást v jiných částech SBOM.

SLUŽBY
Odděleně od komponent je také možné uvést služby, např. mikroslužby. SBOM pak lze použít k definování, zda používání služby překračuje hranici důvěryhodnosti, pokud vyžaduje ověření a konkrétní koncové body API pro službu.

EXTERNÍ KOMPONENTY
CycloneDX má také podporu pro přidávání externích referencí. Ty mohou být buď deklarovány jako součást konkrétní komponenty, nebo mohou být definovány mimo komponentní část SBOM. Externí reference jsou přidány ve formě URLs k informacím.

POPIS GRAFU ZÁVISLOSTI
Vztah mezi závislostmi je dokumentován v samostatné části. Zde je možné odkazovat na komponent pomocí atributu bom-ref a deklarovat, na kterých dalších komponentách přímo závisí. Pokud to uděláte pro všechny komponenty, získáte graf závislostí softwaru, který představuje přímé i tranzitivní vztahy mezi závislostmi.

KOMPOZICE A SESTAVY
CycloneDX má také podporu pro popis kompozic, což je kolekce komponent, služeb a závislostních vztahů. Kompozice může popisovat sestavu, kterou lze považovat za dobře definovanou část softwaru nebo aplikace, která
zase může zahrnovat další části vnořeným způsobem. Složení lze také popsat pomocí závislostí, což jsou části softwaru, které vyžadují další nezávislé části.

ZRANITELNOST
Chyby zabezpečení jsou explicitně popsány v samostatné části CycloneDX SBOM.
Popis zranitelnosti odkazuje na bom-ref postižené komponenty a může obsahovat několik informací. To zahrnuje ID zranitelnosti, vydavatele, reference, identifikátor CWE, informace CVSS, popis zranitelnosti, poradenské informace, časamps atd.

Je také možné zahrnout podrobnosti analýzy zranitelnosti, např. popsat ji jako vyřešenou, zneužitelnou, v třídění nebo neovlivňující komponentu nebo službu, včetně odůvodnění tohoto hodnocení.

• Chyby zabezpečení jsou explicitně popsány v samostatné části CycloneDX SBOM. Popis zranitelnosti odkazuje na bom-ref postižené komponenty a může obsahovat několik informací.

PODPISOVÉ ÚDAJE
Nakonec lze kompletní SBOM podepsat také pomocí digitálního podpisu ve formátu JSON, včetně veřejného ověřovacího klíče a cesty k certifikátu. Kromě podpisu
SBOM, jednotlivé části, jako jsou komponenty, služby a kompozice, mohou být také jednotlivě podepsány.
POROVNÁNÍ SPDX A CYCLONEDX
SPDX a CycloneDX sdílejí podporu pro hlavní případy použití tím, že jsou podporovány jak informace o licencích, tak informace o zranitelnosti. Liší se však rozsahem podpory. Při pohledu na specifikace je jasné, že SPDX se více přiklání k případu použití licencí, zatímco CycloneDX má větší podporu pro informace o zranitelnosti.
PODPORA LICENČNÍCH INFORMACÍ
Jako exampsoubor pro informace o licenci, SPDX přidává specifické pole pro „uzavřenou licenci“, které lze použít, pokud nelze licenci určit nebo pokud nedošlo k žádnému pokusu
najít to. Má také pole pro shromažďování všech licencí v souborech balíčku a přidávání komentářů k licencím.
Část s informacemi o úryvku má také vlastní pole pro informace o licenci. Taková úroveň granularity, až po specifikaci úryvků souborů, není podporována specifikací CycloneDX. Součástí specifikace SPDX je také seznam licencí SPDX. Tento seznam poskytuje standardizovaný krátký identifikátor pro všechny běžně používané licence. Tento identifikátor se stává průmyslovým standardem pro identifikaci licencí a je také používán CycloneDX SBOM.
INFORMAČNÍ PODPORA ZABEZPEČENÍ A ZRANITELNOSTI
Podíváme-li se na zabezpečení, CycloneDX definuje velké množství polí souvisejících se zranitelnostmi, jejich metadaty, hodnocením a akcemi, které byly pro ně podniknuty. Tato data nejsou explicitně podporována SPDX, ačkoli je možné použít externí reference k zahrnutí některých bezpečnostních dat.
Dalším rozdílem souvisejícím s bezpečností je podpora digitálních podpisů v CycloneDX SBOM. Jak SBOM, tak i části dat v něm mohou být digitálně podepsány, aby byla zajištěna autentizace dat a jejich nepopiratelnost. Dokument SPDX je samozřejmě také možné digitálně podepsat. Přesto nemá podporu pro zabalené podpisy, jak je tomu v případě
pro CycloneDX, tj. podpis je součástí podepsaného dokumentu.
Kódování dat
SPDX i CycloneDX podporují data ve formátu JSON, zatímco SPDX navíc podporuje YAML, RDF, a tag: textový soubor hodnot a tabulky XLS. CycloneDX má podporu XML, zatímco SPDX se snaží tuto podporu přidat v příštím vydání.

• Podíváme-li se na zabezpečení, CycloneDX definuje velké množství polí souvisejících se zranitelnostmi, jejich metadaty, hodnocením a akcemi, které byly pro ně podniknuty. Tato data nejsou explicitně podporována SPDX, ačkoli je možné použít externí reference k zahrnutí některých bezpečnostních dat.

Softwarová identifikace (SWID) Tags
Jak je uvedeno výše, NTIA také zahrnuje možnost použití identifikace softwaru (SWID) Tags jako formát SBOM. SWID tag může zahrnovat informace potřebné pro transparentnost v dodavatelském řetězci softwaru s otevřeným zdrojovým kódem, ale jeho hlavní případ použití je poněkud odlišný. SWID tag je navržen pro sledování nainstalovaného softwaru v průběhu celého životního cyklu. Zde je v průběhu životního cyklu podporováno definováním různých typů tags pro předinstalovaný a nainstalovaný software a také opravy tags, k definování záplat pro software a doplňkové tags pro další informace.
SWID ve formátu XML tag bude obsahovat informace o softwaru, jeho licenci a souborech potřebných k instalaci softwaru. Může také obsahovat informace o tom, jaké další balíčky jsou potřeba jako předpoklad pro instalaci. To umožní automatizovanou instalaci softwaru a sledování, jaký software je v systému nainstalován, jakou verzi má a které záplaty byly nainstalovány.

Čtyři varianty SWID Tags
Korpus tag používá se před instalací a používá jej instalační program softwaru. Mohou ověřit vydavatele a použít k ověření integrity softwaru. Licenční informace lze použít k zajištění toho, že před instalací softwaru nebude porušena žádná licence.
Primární tag se používá k popisu softwaru, který byl nainstalován. Má celosvětový unikát tag ID, aby bylo možné tuto konkrétní instalaci sledovat. Může se také propojit s jiným SWID tags. Takový odkaz může být definován jako komponenta, pokud je součástí softwaru jiný software. Může být také definován s požadovaným atributem, pokud závisí na jiné softwarové komponentě. Prostý example je produktivní sada, která má jako komponenty textový a tabulkový procesor. Oba budou mít podle potřeby některé společné knihovny a funkce.
Náplast tag popisuje opravu spíše než samotný softwarový produkt. Obsahuje informace o tom, pro který produkt je náplast určena, zda je třeba před touto náplastí použít jiné náplasti nebo zda nahrazuje jinou náplast.
Doplňkové tag mohou být použity místním systémem k poskytování dalších informací. Může to být například čas instalace.

Závěrem
Pro jeho přijetí je životně důležité mít dobře definované formáty pro ukládání, komunikaci a kódování informací SBOM. Jak CycloneDX, tak SPDX byly široce přijaty a zdá se, že současný trend je takový, že CycloneDX získává největší pozornost. To lze přičíst skutečnosti, že nedávné ovladače, např. Bidenův exekutivní příkaz a zákon EU o kybernetické odolnosti, se silně zaměřují na bezpečnostní přínosy SBOM.
V závěrečné části ukážeme, jak Debricked podporuje export i import SBOM, aby vám pomohl zůstat na vrcholu bezpečnosti a souladu s licencí.

Software Bill of Materials: SBOM with Debricked
S Debricked je snadné generovat i analyzovat SBOM a existuje několik způsobů, jak obojí provést. V tomto příspěvku se podíváme na některé možnosti vytváření a skenování souborů SBOM pomocí Debricked.
Ve společnosti Debricked upřednostňujeme a aktuálně podporujeme formát CycloneDX pro SBOM. To neznamená, že neexistují případy použití, které by se lépe hodily pro formát SPDX. Přesto se domníváme, že licenční podpora v CycloneDX je dostatečná a další pole zranitelnosti, která poskytuje, jsou velmi užitečná.
Generování SBOM
Generování nebo export SBOM je k dispozici pro naše zákazníky na podnikové úrovni. Pokud jste svá úložiště integrovali s Debricked, lze SBOM vygenerovat jako zprávu. Můžete si vybrat, zda chcete vygenerovat SBOM pro jedno úložiště nebo vybranou sadu úložišť, nebo můžete vygenerovat globální zprávu pro všechna vaše integrovaná úložiště.

Ve společnosti Debricked upřednostňujeme a aktuálně podporujeme formát CycloneDX pro SBOM. To neznamená, že neexistují případy použití, které by se lépe hodily pro formát SPDX. Přesto se domníváme, že licenční podpora v CycloneDX je dostatečná a další pole zranitelnosti, která poskytuje, jsou velmi užitečná.

SBOM bude vygenerován jako soubor JSON a zaslán e-mailem na e-mailovou adresu spojenou s vaším účtem.
Některé z věcí, které budou nalezeny v SBOM generovaném Debricked, jsou:

• Všechny závislosti, včetně tranzitivních závislostí, spolu s jejich CPE a/nebo PURL identifikátor.
• Identifikovaná licence pro závislosti. Je uveden jak krátký název licence SPDX, tak text skutečné licence. Jako externí reference také poukazujeme na URLs aktuálních licenčních informací.
• Tento odkaz se označuje jako „Proof of License“ a umožňuje komukoli snadno najít licenční soubor.
• Data o zranitelnosti pro každou závislost. Tato data zahrnují identifikátor zranitelnosti (CVE, GHSA atd.), zdroj, CWE, popis zranitelnosti, odkazy na další informace, skóre CVSSv2 a CVSSv3 a data, kdy byla publikována a naposledy aktualizována.
• Vztahy mezi závislostmi. Všechny závislosti jsou uvedeny pro každou knihovnu a poskytují úplný graf závislostí pro všechny komponenty s otevřeným zdrojovým kódem. Pokud knihovna nemá žádné závislosti, je to označeno prázdným seznamem.

Pokud dáváte přednost použití našeho API, lze SBOM vygenerovat pomocí odpovídajícího koncového bodu. Existuje několik koncových bodů API, ze kterých si můžete vybrat, a my odkazujeme na dokumentaci k rozhraní API, kde najdete úplný přehledview.

Pomocí API
Pokud dáváte přednost použití našeho API, lze SBOM vygenerovat pomocí odpovídajícího koncového bodu. Existuje několik koncových bodů API, ze kterých si můžete vybrat, a my odkazujeme na dokumentaci k rozhraní API, kde najdete úplný přehledview. Jedním z nich je jednoduše vygenerovat SBOM na základě vybrané sady úložišť, jak je uvedeno níže.

Nahrání a analýza SBOM
SWID tags jsou navrženy tak, aby byly odstraněny, jakmile je nainstalovaný software odinstalován a odstraněn ze systému. To ukazuje úzký vztah mezi SWID tags mít s nainstalovaným softwarem. Ve srovnání s SPDX a CycloneDX tyto dva formáty SBOM více popisují software a jeho složení a nejsou vázány na konkrétní instalaci softwaru.
Pro více podrobností poskytuje NIST vynikající vodítko pro SWID tags.

• SWID tags jsou navrženy tak, aby byly odstraněny, jakmile je nainstalovaný software odinstalován a odstraněn ze systému. To ukazuje úzký vztah mezi SWID tags mít s nainstalovaným softwarem.

Zde si můžete vybrat, zda chcete zahrnout také zranitelnost a/nebo licenční data. Použití rozhraní API bude vyžadovat přístupový token. Ve vašem účtu Debricked lze vygenerovat obnovovací token, který lze použít k vygenerování tokenu JWT. Nebo můžete jednoduše použít své přihlašovací ID a heslo k okamžitému vygenerování tokenu JWT.

Nahrání a analýza SBOM
Pokud máte SBOM a chcete jej analyzovat, Debricked to může udělat za vás. Dokonce sledujeme závislosti na nových zranitelnostech a můžeme vás upozornit, pokud nějaké najdeme.

• Pokud máte SBOM a chcete jej analyzovat, Debricked to může udělat za vás. Dokonce sledujeme závislosti na nových zranitelnostech a můžeme vás upozornit, pokud nějaké najdeme.

Ruční nahrání
Nejjednodušší způsob, jak analyzovat existující CycloneDX SBOM, je nahrát jej do Debricked GUI. Stačí přejít do nastavení úložiště a kliknout na tlačítko Manual scan.

Zde můžete vybrat soubor SBOM nebo jej jednoduše přetáhnout. SBOM se zobrazí jako nové úložiště se seznamem všech zranitelností, licencí a závislostí. Pokud existuje nová chyba zabezpečení, zobrazí se také v uživatelském rozhraní.

Přidání SBOM do úložiště
Možnost ručního skenování zobrazí nové chyby zabezpečení v uživatelském rozhraní. Pokud chcete být upozorněni, např. e-mailem, pokaždé, když se objeví nová zranitelnost, můžete jednoduše přidat SBOM ke skenování jako součást CI/CD. Při skenování úložiště Debricked najde soubor SBOM a prohledá jej, zda neobsahuje nové zranitelnosti.
Po skenování můžete nastavit pravidlo automatizace, které spustí existující nebo nové chyby zabezpečení. Pravidlo automatizace můžete přizpůsobit tak, aby např. spustilo výstrahu, pokud je zranitelnost vysoká
nebo kritická závažnost. Níže uvádíme exampsoubor, který po skenování odešle e-mail všem administrátorům účtu Debricked, pokud existuje nová zranitelnost nebo zranitelnost s alespoň vysokou závažností.

• Po skenování můžete nastavit pravidlo automatizace, které spustí existující nebo nové chyby zabezpečení. Pravidlo automatizace můžete přizpůsobit tak, aby například spouštělo výstrahu, pokud je zranitelnost velmi závažná nebo kritická.

To umožní správcům připomenout vysoce závažná zranitelnost při každém skenování, ale pouze jednou být upozorněni na méně závažná zranitelnost. Také zranitelnosti, které byly vyhodnoceny tak, aby neovlivnily organizaci nebo software, nezpůsobí žádná upozornění. To je zajištěno zaškrtnutím políčka „Ignorovat neovlivněné zranitelnosti“.

Podívejme se na exampInformace o tom, jak můžete GitHub používat ke sledování a upozorňování na identifikaci nových zranitelností. Ke spuštění kontroly použijte naplánovaný pracovní postup akcí GitHubu. Pracovní postupy jsou přidány do podsložky .github/workflows. Pro Debricked může pracovní postup vypadat takto.
název: Debricked scan
na:
naplánovat:

• cron: "0 9 * * *"
• zaměstnání:
• skenování zranitelností:
• run-on: ubuntu-latest
• kroky:
  • používá: actions/checkout@v2
  • použití: debricked/actions/scan@v1
• env:
• DEBRICKED_TOKEN: ${{ secrets.DEBRICKED_TOKEN }}

Zaregistrujte se zdarma do Debricked a převezměte plnou kontrolu nad zabezpečením, dodržováním předpisů a zdravím pomocí sady nástrojů, která změní způsob, jakým používáte open source.

To spustí nové skenování SBOM každý den v 9:XNUMX a spustí výstrahy podle výše uvedeného pravidla automatizace.
Pokud používáte jiné nástroje CI/CD, je samozřejmě možné provádět podobné naplánované kontroly.

Závěr
Protože Debricked podporuje skenování a monitorování SBOM, není nástroj SCA určen pouze pro výrobce softwaru a vývojáře. Je to také mocný nástroj pro kupující a spotřebitele. Debricked se postará o části automatizace a interoperability, bude sledovat nové zranitelnosti a změny licencí a upozorní vás na jakékoli významné změny.
Jakmile budou splněny požadavky na dodávku SBOM spolu se softwarovými produkty, budou všechny zúčastněné strany v rámci hodnotového řetězce schopny lépe porozumět bezpečnosti produktů. To povede k bezpečnějším produktům, lepším reakcím na nová zranitelná místa a transparentnosti v dodavatelském řetězci softwaru.
Zaregistrujte se zdarma do Debricked a převezměte plnou kontrolu nad zabezpečením, dodržováním předpisů a zdravím pomocí sady nástrojů, která změní způsob, jakým používáte open source.

Spojte se s námi www.opentext.com

OpenText Cybersecurity poskytuje komplexní bezpečnostní řešení pro společnosti a partnery všech velikostí. Od prevence, detekce a reakce až po obnovu, vyšetřování a dodržování předpisů, naše jednotná end-to-end platforma pomáhá zákazníkům budovat kybernetickou odolnost prostřednictvím holistického portfolia zabezpečení. Zákazníci OpenText Cybersecurity, využívající praktické poznatky z našeho zpravodajství o hrozbách v reálném čase a kontextuálních informací, těží z vysoce účinných produktů, vyhovujícího prostředí a zjednodušeného zabezpečení, které jim pomáhá řídit obchodní rizika.
762-000084-004 | O | 01/24 | © 2024 Open Text

Dokumenty / zdroje

opentext Software Bill of Materials [pdfUživatelská příručka Software kusovník, materiály

Reference

• Uživatelská příručka