Az SBOM (Software Bill of Materials) lényegében egy szoftverleltár: megmutatja, hogy egy alkalmazás milyen komponensekből, könyvtárakból, csomagokból és függőségekből épül fel. Kisvállalatoknál ez elsőre túl „nagyvállalati” témának tűnhet, pedig nagyon is gyakorlati eszköz a kiberbiztonságban. Ha tudjuk, miből áll a saját webalkalmazásunk, webshopunk, belső ügyviteli rendszerünk vagy mobilappunk, sokkal gyorsabban kideríthető, érint-e minket egy frissen bejelentett sérülékenység.
Miért fontos az SBOM egy kisvállalatnak?
A modern szoftverek jelentős része nem nulláról íródik. Fejlesztők nyílt forráskódú komponenseket, keretrendszereket, JavaScript-csomagokat, konténer image-eket, API-kat és külső modulokat használnak. Ez teljesen normális, sőt hatékony megoldás. A probléma ott kezdődik, amikor senki nem tudja pontosan, melyik komponensből melyik verzió fut élesben.
Egy kisvállalatnál gyakori helyzet, hogy a weboldalt külsős fejlesztő készítette, a webshop motorját egy ügynökség karbantartja, a belső rendszerhez pedig évek óta nem nyúlt senki. Ha megjelenik egy súlyos sebezhetőség egy népszerű csomagban, az első kérdés ez: használjuk mi ezt valahol? SBOM nélkül a válasz sokszor csak kézi nyomozással, fejlesztői e-mailezéssel és találgatással derül ki.
Az SBOM célja nem az, hogy újabb adminisztrációs terhet rakjon a cégre, hanem hogy átláthatóbbá tegye a szoftverellátási láncot. Egy jól karbantartott szoftverleltár segít a kockázatok gyorsabb azonosításában, a hibajavítások priorizálásában és abban is, hogy egy ügyfél vagy partner biztonsági kérdéseire felkészülten lehessen válaszolni.
Mit tartalmazzon egy használható szoftverleltár?
Egy SBOM akkor hasznos, ha nem csak egy elavult Excel-fájl a megosztott meghajtón. Legalább azokat az információkat érdemes tartalmaznia, amelyek alapján egy sérülékenység érintettsége gyorsan ellenőrizhető.
- Komponens neve: például egy nyílt forráskódú könyvtár, npm-csomag, Python-modul vagy konténer image.
- Verziószám: ez kritikus, mert sok sebezhetőség csak bizonyos verziókat érint.
- Forrás vagy csomagkezelő: például npm, PyPI, Maven, NuGet, GitHub repository vagy konténer registry.
- Licencinformáció: nemcsak biztonsági, hanem megfelelőségi szempontból is hasznos lehet.
- Kapcsolódó alkalmazás vagy rendszer: fontos tudni, hogy az adott komponens hol fut.
- Felelős személy vagy beszállító: ki tud intézkedni, ha frissíteni kell?
Nem kell első lépésben tökéletes, minden részletre kiterjedő leltárt készíteni. Kisvállalatként sokkal jobb egy egyszerű, de rendszeresen frissített SBOM, mint egy túl bonyolult terv, amely soha nem készül el.
Hogyan kezdjen hozzá egy kisvállalat?
Az első lépés a legfontosabb üzleti rendszerek azonosítása. Nem érdemes rögtön minden régi eszközt és mellékprojektet feltérképezni. Kezdjük azokkal az alkalmazásokkal, amelyek ügyféladatot kezelnek, bevételt termelnek, publikus interneten elérhetők, vagy kritikus belső folyamatot támogatnak.
Ha van belső vagy külsős fejlesztő, kérjük el a használt technológiák és függőségek listáját. Sok esetben a csomagkezelők már eleve tartalmaznak ilyen információkat: például a package-lock.json, yarn.lock, requirements.txt, pom.xml vagy composer.lock fájlok jó kiindulópontot adhatnak. Konténeres környezetben a használt image-ek és azok alaprétegei is fontosak.
Érdemes bevezetni egy egyszerű szabályt: új fejlesztés vagy nagyobb frissítés csak akkor kerülhet éles környezetbe, ha a kapcsolódó szoftverleltár is frissül. Ez nem feltétlenül jelent bonyolult folyamatot. Sok fejlesztői pipeline-ba beépíthető automatikus SBOM-generálás, amely a build során elkészíti a komponenslistát.
SBOM és sebezhetőségkezelés: együtt működik igazán
Az SBOM önmagában még nem véd meg egy támadástól. Akkor válik értékessé, ha összekapcsoljuk a sebezhetőségkezeléssel. Amikor megjelenik egy ismert hiba valamelyik komponensben, a leltár alapján gyorsan ellenőrizhető, hogy érintett-e a cég valamelyik rendszere.
A gyakorlatban ez így nézhet ki: egy népszerű nyílt forráskódú komponensben sérülékenységet jelentenek be. A fejlesztő vagy az IT-felelős rákeres a komponens nevére és verziójára az SBOM-ban. Ha nincs találat, a kockázat valószínűleg nem érinti az adott rendszereket. Ha van találat, meg kell nézni, hogy az adott alkalmazás internet felől elérhető-e, kezel-e érzékeny adatot, illetve létezik-e javított verzió. Így a döntés nem pánik alapján, hanem konkrét információkra építve történik.
Fontos, hogy ne csak a közvetlenül telepített csomagokra figyeljünk. Sok kockázat tranzitív függőségekből jön: vagyis olyan komponensekből, amelyeket nem mi választottunk ki közvetlenül, hanem egy általunk használt könyvtár hozott magával. Egy jó SBOM ezeket is láthatóvá teszi.
Tipikus hibák, amelyeket érdemes elkerülni
Az egyik gyakori hiba, hogy az SBOM egyszer elkészül, majd elfelejtődik. A szoftverek folyamatosan változnak, ezért a leltárnak is követnie kell a frissítéseket. A másik probléma, amikor a dokumentum létezik, de senki nem tudja, hol van, ki felel érte, vagy hogyan kell használni incidenshelyzetben.
Szintén kockázatos kizárólag a beszállítóra hagyatkozni. Ha külsős fejlesztő vagy üzemeltető kezeli a rendszert, akkor is érdemes szerződéses vagy működési szinten rögzíteni, hogy kérhető legyen aktuális szoftverleltár, és sérülékenység esetén legyen kijelölt kapcsolattartó.
Az SBOM nem csodaszer, de kisvállalati környezetben is nagyon hasznos alap a kiberbiztonság megerősítéséhez. Segít átlátni a szoftverellátási láncot, csökkenti a bizonytalanságot, és gyorsabbá teszi a reagálást, amikor egy komponensről kiderül, hogy sebezhető. A legjobb kezdés nem a tökéletes rendszer, hanem egy átgondolt, karbantartható leltár a legfontosabb alkalmazásokról.
