SBOM: Odhaľte tajný recept na bezpečný softvér!

Čo Vás napadne ako prvé pri tejto zvláštnej skratke? Ak sa nepohybujete v úzkom kruhu IT security, môže vám to pripomenúť Byte-Order-Mark, ktorý určoval kódovanie znakov v textových súboroch. Nie. BOM znamená Bill of Materials, teda zoznam komponentov a S určuje o aký materiál sa jedná.

Každý produkt sa z niečoho skladá. Program, webová stránka aj mikroservisa majú svoje komponenty, ktoré sme poskladali a nasadili do výslednej podoby. Keďže sme produkt vytvorili sami, pravdepodobne vieme, že sme tam použili .NET, C++, Javu, alebo sme to celé urobili v Pythone. Vieme však urobiť úplný zoznam všetkých assemblies, komponentov, ktoré sme potrebovali referencovať, aby to všetko fungovalo? Vedeli by sme automaticky určiť, aké licenčné podmienky má daný komponent?

Už teraz asi tušíte, že sa to dá. Kým si však povieme ako, zostáva ešte zopár nezodpovedaných otázok. Prečo by som to mal robiť? Načo vytvárať zoznam všetkých Python balíčkov použitých v mojom programe?

Nuž, pokiaľ nie ste chorobný spisovač to-do listov a zoznamov, tak jediným dôvodom je (tušíte správne) bezpečnosť. Takýto zoznam si dokonca začínajú vyžadovať samotní zákazníci, ba dokonca vlády.

Spomeňme Zákon o kybernetickej bezpečnosti Cyber Resilience Act CRA, pod hlavičkou EU, alebo príkaz na zlepšenie kybernetickej bezpečnosti (Executive Order on Improving the Nation’s Cybersecurity), ktorý podpísal prezident Joe Biden v máji 2021.

Bežní zákazníci, ktorí by mali vyžadovať zoznam softvérových komponentov sú vládne agentúry alebo organizácie.

Prečo od nás zákazník takýto zoznam vyžaduje? Pravdepodobne má vo svojom tíme silnú skupinu kybernetických špecialistov, ktorí si chcú overiť, či naše produkty spĺňajú ich bezpečnostné štandardy. Sú naše nuget balíčky, na ktoré odkazujeme aktuálne? Neobsahujú nejakú bezpečnostnú zraniteľnosť? Náš zoznam teda musí obsahovať nielen zoznam balíkov, ale aj ich príslušné verzie. Preto vznikli štandardné formáty, ktoré riešia to, čo spomínaný SBOM zoznam musí obsahovať.

Najrozšírenejšie sú 2 štandardné formáty. Prvý prichádza z dielne LINUX a ten druhý od OWASP u. Prvým je Software Package Data Exchange SPDX, druhý má názov CycloneDX. Meno CycloneDX má symbolický význam, kde Cyclone evokuje predstavu niečoho dynamického a rýchlo sa pohybujúceho. DX: Skratka pre Dependency-Track, čo je jeden z pôvodných nástrojov, ktoré tento štandard podporujú.

Prehľad jednotlivých formátov pre SBOM

Existujú aj ďalšie vylepšenia, ako napríklad VEX formát, ktorý je navyše obohatený aj o možnosť pridať poznámky a stav, čo zákazníkom umožní sledovať čo a kedy plánujeme opraviť (napr. odstrániť zastaralú verziu komponentu).

Určite sa Vám v hlave vynárajú ďalšie a ďalšie otázky. Prečo by som mal zákazníkovi priznať, že používam starú verziu niektorých balíkov alebo nebodaj, že používam JAR-ko, ktoré má známe bezpečnostné riziko? Aj keď je technicky možné upraviť SBOM tak, aby obsahoval iba informácie, ktoré chcete zdieľať, takéto konanie zníži vašu transparentnosť, môže negatívne ovplyvniť dôveru zákazníka vo Vás a potenciálne vytvoriť právne problémy. Zákazník si totiž dokáže veľa vecí overiť aj iným spôsobom.

Čo ak zákazník zverejní zoznam komponentov a útočníci ho využijú, aby sa dostali do môjho systému, keďže presne vedia, aké technológie a verzie používam? V prvom rade ide o komunikáciu a určite pomôže NDA (dohoda o mlčanlivosti). Je to právny dokument stanovujúci podmienky dôvernosti informácií. Argument, že by sa zoznam mohol dostať do nesprávnych rúk, nie je úplne správny. Zoznam komponentov síce môže byť pre hackerov užitočný, ale v skutočnosti ho ani nepotrebujú.

Hoci existujú legitímne obavy z potenciálneho zneužitia SBOM hackermi, celkové výhody implementácie SBOM vo vývoji softvéru zvyčajne prevažujú nad rizikami.

Tým, že máme prehľad o tom, aké komponenty používame, môžeme automaticky identifikovať potenciálne problémy a zaviesť procesy na ich riešenie. Keď už teda máme SBOM, napríklad vo formáte CycloneDX, môžeme ho „prevetrať“ cez nástroj Dependency-Track, ktorý nám prehľadne zobrazí komponenty a ich zraniteľnosti, a prípadne aj licenčné podmienky. Tento prehľad nám umožňuje lepšie spravovať bezpečnosť a súlad s licenčnými požiadavkami, čím zvyšujeme spoľahlivosť našich produktov.

Možno si hovoríte, že toto nikdy nebudete musieť robiť. My v DESCARTES však berieme bezpečnosť softvéru veľmi vážne. Je lepšie byť pripravený vopred, pretože všetko spolu súvisí.

Je v našom záujme nastaviť procesy tak, aby sme postupne riešili technologický dlh, odstránili nevyužívané DLL knižnice z našich repozitárov a vždy používali package manažérov. Zároveň by sme mali nastaviť automatický systém, napríklad Dependabot, ktorý nás upozorní na zastarané komponenty. Ak si tieto kroky dobre nastavíme, nemusíme sa obávať vytvoriť SBOM a poskytnúť hozákazníkovi. Možno práve on bude klásť správne otázky, čo nám pomôže spraviť náš produkt odolnejším voči útokom a tým aj konkurencieschopnejším.

Organizácie môžu prijať opatrenia na minimalizáciu expozície a ochranu citlivých informácií, pričom zároveň zvyšujú svoju bezpečnostnú úroveň prostredníctvom väčšej transparentnosti a lepšieho riadenia zraniteľností. Na záver by sme mali vnímať SBOM ako nástroj na zlepšenie bezpečnosti, nie ako zodpovednosť.

zdroje:
HTTPS://CYCLONEDX.ORG
HTTPS://GITHUB.COM/CYCLONEDX/CYCLONEDX-CLI
HTTPS://GITHUB.COM/DEPENDENCYTRACK/DEPENDENCY-TRACK
HTTPS://WWW.WHITEHOUSE.GOV/BRIEFING-ROOM/PRESIDENTIAL-ACTIONS/2021/05/12/EXECUTIVE-ORDER-ON-IMPROVING-THE-NATIONS-CYBERSECURITY/
HTTPS://WWW.CISA.GOV/SITES/DEFAULT/FILES/2023-09/EU%20COMMISSION%20SBOM%20WORK_508C.PDF