SBOM: ismerd, mi fut a szoftvereidben.
Az SBOM, vagyis a szoftver-összetevőlista megmutatja, milyen könyvtárakból, verziókból és licencekből áll egy alkalmazás. A Log4Shell óta ez a lista az ellátási lánc biztonságának alapja, a NIS2 és az EU Cyber Resilience Act pedig egyre többször számon is kéri. Megmutatjuk, mit tartalmaz, hogyan készül, és mit kérj a szállítódtól.
Mi az SBOM?
Az SBOM (angolul software bill of materials, magyarul szoftver-összetevőlista vagy szoftveranyagjegyzék) azt sorolja fel, miből áll egy szoftver. Olyan, mint az élelmiszer összetevőlistája: nem a receptet adja meg, hanem azt, mi van a dobozban.
Egy mai alkalmazás kódjának nagy részét nem a fejlesztőcsapat írta. Nyílt forráskódú könyvtárak és keretrendszerek adják, azok pedig újabb könyvtárakat hoznak magukkal. Ez a függőségi fa. Az SBOM ezt rögzíti egyetlen, géppel olvasható fájlban: komponens, verzió, licenc, eredet.
Mit tartalmaz minimálisan?
Az amerikai NTIA 2021-es minimumelemei hét adatmezőt neveznek meg:
- Szállító neve – ki készítette a komponenst.
- Komponens neve és verziója.
- Egyéb egyedi azonosítók – például CPE vagy Package URL, amellyel a sérülékenységi adatbázisokban megtalálható.
- Függőségi kapcsolat – melyik komponens melyiket használja.
- Az SBOM szerzője és időbélyege – ki és mikor készítette a listát.
2026 júliusában a CISA és több nemzeti hatóság, köztük a német BSI és a francia ANSSI, közösen frissítette ezeket. Új elem például a komponensek ellenőrzőösszege, a licenc, az SBOM keletkezési környezete és a digitális aláírás. Érdemes már most ezeket a frissebb elemeket kérni.
Miért kell SBOM?
A Log4Shell tanulsága.
2021 decemberében kiderült, hogy a Log4j naplózó könyvtárban kritikus sérülékenység van: ez a Log4Shell (CVE-2021-44228). A hiba távoli kódfuttatást tett lehetővé. A Log4j szinte mindenhol ott volt, de ritkán közvetlenül: sokszor egy másik könyvtár hozta magával.
Akinek volt összetevőlistája
Egy kereséssel kiderült, mely rendszerek érintettek. A javítás és a tesztelés gyakran órák alatt megvolt.
Akinek nem volt
Kézzel kellett átnézni a szervereket, a csomagokat és a beszállítók leveleit. A keresés gyakran hetekig tartott, közben a rendszer sebezhető maradt.
Az SBOM nem véd meg a sérülékenységtől. Azt adja meg, hogy a hír után az első kérdésre – érint ez minket? – percek alatt válaszolhass. Ez a sérülékenységkezelés alapja.
SBOM-formátumok
és eszközök.
| Formátum | Szabvány, gazda | Erőssége |
|---|---|---|
| SPDX | ISO/IEC 5962:2021, Linux Foundation | Licenc- és jogi megfelelés, nemzetközi szabvány. |
| CycloneDX | OWASP-projekt, ECMA-424 | Biztonsági fókusz, VEX-támogatás, könnyű build-integráció. |
| SWID | ISO/IEC 19770-2 | Telepített szoftver azonosító címkéje, leltározásra. |
Hogyan készül?
Az SBOM-ot a build-folyamatban generáld, ne utólag kézzel. Csak így felel meg a kiadott verziónak. A Syft és a Trivy a kész csomagot vagy konténerképet olvassa be. A CycloneDX-generátorok és a csomagkezelők beépülő moduljai (például Mavenhez, Gradle-hez, npm-hez vagy .NET-hez) a forrásból dolgoznak.
Tárold az SBOM-ot a kiadás mellett, verziózva. Így egy évvel később is megmondható, mi volt benne.
Mit kezdj az SBOM-mal?
Sérülékenység-egyeztetés
Az összetevőlistát összeveted a sérülékenységi adatbázisokkal, például az amerikai NIST adatbázisával, az NVD-vel. Az eszközök, például a Trivy vagy a Grype, ezt automatikusan elvégzik. Ha új CVE jelenik meg, nem kell újra felmérni a rendszert: elég a meglévő SBOM-ot újra lefuttatni.
VEX: melyik sérülékenység érint ténylegesen?
Egy könyvtár sérülékeny lehet, miközben a szoftvered a hibás részét sosem hívja meg. A VEX (Vulnerability Exploitability eXchange) ezt rögzíti: egy termékre és egy CVE-re megmondja, hogy érintett, nem érintett, javított, vagy még vizsgálják. Így nem kell száz téves riasztással foglalkoznod.
Licencmegfelelés és beszállítói kontroll
A licencadat megmutatja, ha egy szigorú (copyleft) licencű komponenst zárt termékbe építettek be. Beszállítónál az SBOM az első kérés: ebből látod, kire támaszkodik a szállítód.
Írd az ajánlatkérésbe és a szerződésbe, hogy az átvétel feltétele az SBOM. Utólag nehezebb elkérni, és egy régi rendszernél már senki sem tudja pontosan, mi van benne.
Jogszabályi és szabványi
háttér.
NIS2 és kiberbiztonsági törvény
A NIS2-irányelv (2022/2555) a kockázatkezelési intézkedések közé sorolja az ellátási lánc biztonságát. A magyar kiberbiztonsági törvény (2024. évi LXIX. tv.) is ezt várja el. Az NIS2 beszállítói lánc ellenőrzéséhez az SBOM kézzelfogható bizonyíték.
ISO 27001:2022
Az A.8.8 a műszaki sérülékenységek kezelését, az A.8.25–A.8.29 a biztonságos fejlesztést, az A.5.21 az informatikai ellátási lánc biztonságát írja elő. Mindháromnál bizonyíték lehet az SBOM.
Cyber Resilience Act
A (EU) 2024/2847 rendelet a digitális elemeket tartalmazó termékek gyártóira vonatkozik. Gyártóként SBOM-ot kell készítened a műszaki dokumentációhoz. Részletek alább.
Cyber Resilience Act (CRA) röviden
- 2024. december 10-én lépett hatályba.
- 2026. szeptember 11-től él a bejelentési kötelezettség: az aktívan kihasznált sérülékenységeket és a súlyos incidenseket jelenteni kell.
- 2027. december 11-től alkalmazandó a rendelet fő része, köztük az alapvető kiberbiztonsági követelmények és a CE-jelölés.
A gyártónak a sérülékenységkezelés részeként géppel olvasható, általánosan használt formátumú SBOM-ot kell készítenie, legalább a legfelső szintű függőségekre. Ez a műszaki dokumentáció része: nyilvánosan nem kell közzétenni, de a piacfelügyeleti hatóság kérésére át kell adni. Hogy a te szoftvered beletartozik-e a hatókörbe, esetenként érdemes megvizsgálni.
Az amerikai 14028. számú elnöki rendelet (2021) indította el az SBOM-elvárást az állami beszerzésben. Ezért amerikai partnernél is felmerülhet a kérés.
Így csináljuk
az ABSEC-nél.
A biztonságos szoftverfejlesztés részeként minden rendszerünkhöz SBOM készül a build során. Kiadás előtt a lista alapján sérülékenység-ellenőrzést futtatunk, és ha kritikus hibát találunk, a kiadás nem megy ki. Átadáskor az SBOM a dokumentáció része, így a NIS2- vagy ISO 27001-auditon bizonyítékként mutathatod be.
Ugyanezt megrendelőként te is bekérheted a beszállítóidtól.
Mit kérj a szoftverszállítódtól?
- SBOM minden kiadáshoz — verziónként új lista, nem egyszeri dokumentum, hogy mindig a futó szoftvert írja le.
- Géppel olvasható formátum — SPDX vagy CycloneDX, nem PDF és nem táblázat.
- Teljes függőségi fa — a közvetlen és a közvetett (tranzitív) függőségek is szerepeljenek.
- A minimumelemek — szállító, komponensnév, verzió, azonosító, függőségi kapcsolat, szerző, időbélyeg; lehetőleg ellenőrzőösszeggel és licenccel.
- Automatikus generálás — a build-folyamat része legyen, ne kézi munka.
- Átadás határideje — kiadáskor és új kritikus sérülékenységnél is: előre megállapodott, rövid határidővel.
- VEX-nyilatkozat — a nyilvános sérülékenységekről mondja meg, melyik érinti ténylegesen a terméket.
- Sérülékenység-bejelentési folyamat — kapcsolattartó, válaszidő és javítási határidők a szerződésben.
- Licencjegyzék — minden komponens licence, különösen a copyleft jellegűeké.
- Szerződéses feltétel — az SBOM hiánya hiányos átvételnek számít, a szállító pedig értesít, ha a komponensek változnak.
Ezt is érdemes elolvasnod.
Mi az SBOM magyarul?
Szoftver-összetevőlista vagy szoftveranyagjegyzék. Az SBOM géppel olvasható felsorolás arról, hogy egy szoftver milyen könyvtárakból és komponensekből áll, azok melyik verzióját és licencét használja, és hogyan függnek egymástól.
Kötelező az SBOM?
Az EU Cyber Resilience Act a digitális elemeket tartalmazó termékek gyártóitól várja el, a fő kötelezettségek 2027. december 11-től alkalmazandók. A NIS2 és a magyar kiberbiztonsági törvény az ellátási lánc biztonságát írja elő, amelynek az SBOM bevett eszköze. Hogy rád pontosan mi vonatkozik, a hatóság oldalán és a szerződéseidben érdemes ellenőrizni.
SPDX vagy CycloneDX a jobb?
Mindkettő elfogadott, és a legtöbb eszköz mindkettőt tudja exportálni. A CycloneDX biztonsági és sérülékenységkezelési célra gyakoribb, az SPDX licenc- és jogi megfelelésnél erős. Kérd azt, amelyet a saját eszközeid be tudnak olvasni.
Mi a különbség az SBOM és a VEX között?
Az SBOM azt mondja meg, mi van a szoftverben. A VEX azt, hogy egy adott sérülékenység ténylegesen érinti-e a terméket: érintett, nem érintett, javított vagy vizsgálat alatt van. A kettő együtt csökkenti a téves riasztások számát.
Hogyan készül az SBOM?
A build-folyamatban, automatikusan: olyan eszközök állítják elő, mint a Syft, a Trivy vagy a CycloneDX-generátorok. Minden kiadáshoz új SBOM készül, hogy a lista mindig a kiadott verziót írja le.
Tudod, mi fut
a szoftvereidben?
Átnézzük, hol tartasz az SBOM-mal, és megmondjuk, mit érdemes kérned a szállítóidtól. Az első beszélgetés után tudni fogod, mi a legkisebb lépés, ami már számít.