Blog cikk szövege:
A szoftverellátási lánc biztonsága napjainkban már nem csak a nagyvállalatok fejfájása. Az elmúlt évek botrányai – a SolarWinds incidens vagy az XZ Utils backdoor – világosan megmutatták, hogy az ellenfél nem feltétlenül a végfelhasználót támadja meg közvetlenül, hanem az azt megelőző, sokszor rejtett láncolatot használja fel. Minden cég, amely szoftvert használ vagy fejleszt, érintett ebben a kérdésben.
Mi is történt valójában? A SolarWinds esete során egy széles körben használt monitorozási alkalmazás lett a járulékos támadás eszköze – világszerte tízezer szervezet került sérülékeny helyzetbe, anélkül hogy ezt közvetlenül tudták volna. Az XZ Utils backdoor pedig azt demonstrálta, hogy még a nyílt forráskódú szoftvereket sem mentesítik a fenyegetések, ha az őket fejlesztő közösség kellően fáradt vagy kiszolgáltatott.
Hogyan lehet tehát gyakorlatban védekezni? Az első lépés az adatok rendszerezése. A SBOM – vagyis a szoftver anyagjegyzék – egy olyan dokumentáció, amely pontosan felsorolja, hogy milyen komponensekből épül fel az alkalmazásunk. Ez nem luxus, hanem alapvető szükséglet. Szinte minden biztonsági szabályozás (beleértve az új amerikai és európai előírásokat) már megkövetelik ezt. Ha nem tudod, mik a függőségeid, akkor nem tudhatod, mik az ismeretlen veszélyek sem.
A nyílt forráskódú szoftverek auditálása ugyancsak kritikus. Sok fejlesztő automatikusan feltételezi, hogy a közösség által ellenőrzött kód biztonságosabb. Ez részben igaz, ám csak akkor, ha ténylegesen ellenőrzik azt. Egy széles körben használt függőség, amely egy-két fő karbantartásán múlik, már potenciálisan veszélyes pont. Érdemes olyan eszközöket használni, amelyek felmérik a függőségek állapotát és a közösség erősségét.
A kód-aláírás és az artifact provenance ellenőrzése is alapvetővé vált. Ez azt jelenti, hogy bizonyítható módon kell tudnunk, hogy egy adott verzió tényleg az eredeti fejlesztőktől származik-e, nem pedig valahonnan közbeékelt rosszindulatú módosítástól. A digitális láncok szigora garantálja a szállított szoftver integritását.
Praktikus szinten mit tehetünk? Készíts fel egy felelős személyt az SBOM kezelésére, legalább felméréseik szintjén. Egyeztess az alkalmazottakkal – ha nyílt forráskódot használ a cég, akkor egy transzparens listában kell, hogy szerepeljék az összes függőség. Értékelje meg a kritikus komponenseket, azokat az elemeket, amelyek nélkül a rendszer nem működne. Végül, de nem utolsósorban: egyeztess a szoftverszállítóiddal, hogy milyen biztonsági intézkedéseket vezettek be az ő végükön is.
A szoftverellátási lánc biztonsága nem egypontos megoldás, hanem a szervezet kulturális változása. A felelősség megosztott – mint a szoftvergyártóké, úgy a felhasználók körültekintésé is.