Szoftverfüggőségek és az SBOM

Egy mai alkalmazás kódjának töredékét írja a fejlesztő csapat, a többi külső könyvtárakból jön. Ezek a könyvtárak további könyvtárakat hoznak magukkal, és néhány szint után senki nem tudja, mi fut valójában.

A probléma akkor válik láthatóvá, amikor egy széles körben használt komponensben súlyos sérülékenységet találnak, és a kérdés az, hogy érintett-e a rendszer.

Miért nehéz megválaszolni

Tranzitív függőségek. A közvetlenül behivatkozott tíz könyvtár mögött több száz további áll. A sérülékenység jellemzően a mélyebb rétegben van.

Verzió-eltérés. A fejlesztői gépen, a tesztkörnyezetben és az élesben nem feltétlenül ugyanaz a verzió fut.

Konténerek. Az alkalmazás mellett az alap image is tartalmaz csomagokat, saját sérülékenységekkel.

Régi rendszerek. Ami évek óta fut és senki nem nyúl hozzá, arról jellemzően nincs is nyilvántartás.

Mi az SBOM

A Software Bill of Materials a szoftver összetevőinek jegyzéke: mely komponens, milyen verzióban, milyen licenccel. Gépi olvasható formátumban (CycloneDX vagy SPDX), tehát automatikusan összevethető a sérülékenységi adatbázisokkal.

Az SBOM önmagában nem véd meg semmitől. Az értéke abban van, hogy egy új sérülékenység megjelenésekor percek alatt megválaszolható, érintett-e a rendszer, ahelyett hogy napokig keresgélnének.

Hogyan vezesse be

1. Generálás a build során. A legtöbb csomagkezelőhöz és build-eszközhöz van SBOM-generátor. A kulcs, hogy a build része legyen, ne külön futtatott feladat, mert különben elavul.

2. Tárolás verzióhoz kötve. Minden kiadott verzióhoz tartozzon egy SBOM. Ha három hónap múlva kérdés merül fel a februári verzióról, meg kell tudni nézni.

3. Automatizált illesztés. Az SBOM-ot rendszeresen össze kell vetni a sérülékenységi adatbázisokkal. Nem elég a build idején egyszer, mert az új sérülékenység később jelenik meg.

4. Beszállítói SBOM bekérése. Ha vásárolt szoftvert használ, kérje el az SBOM-ját. Ez egyre gyakoribb szerződéses elvárás.

Priorizálás

Egy közepes alkalmazás függőség-vizsgálata több száz találatot ad. Ugyanaz a logika érvényes, mint az általános sérülékenységkezelésnél:

• Elérhető-e a sérülékeny kód? Ha a könyvtár benne van, de az érintett funkciót az alkalmazás nem hívja, a kockázat lényegesen alacsonyabb. Egyes eszközök ezt is elemzik.
• Van-e aktív kihasználás? A CISA KEV-lista itt is a legjobb szűrő.
• Elérhető-e a komponens kívülről? Egy belső segédeszközben lévő hiba nem ugyanaz, mint a publikus API-ban.

Erről részletesen a sérülékenységkezelésről szóló cikkünkben írtunk.

Az ellátási lánc kockázata

A függőségek nem csak sérülékenységet hordoznak, hanem támadási felületet is:

Elgépelés-alapú csomagok. A támadó a népszerű csomag nevéhez hasonló nevű csomagot tesz közzé, abban a reményben, hogy valaki elgépeli.

Átvett csomagok. Egy elhagyott, de sokak által használt csomagot a támadó átvesz, és rosszindulatú kódot ad hozzá.

Build-lánc kompromittálódás. Nem a csomag, hanem a fordítási folyamat sérül.

Ezek ellen a csomagok verziójának rögzítése (lockfile), a belső csomagtükör és a build-környezet izolálása véd.

Mit mérjen

• Van-e SBOM minden éles rendszerhez
• Hány nyitott, KEV-listás komponens-sérülékenység van
• Átlagos idő a sérülékenység megjelenésétől a frissítésig
• Az éles image-ek hány százaléka vizsgált

Az IT biztonsági szolgáltatásaink között a fejlesztési folyamat biztonsági felülvizsgálata is szerepel.