Biztonsági rés a kódban
Az operációs rendszer szoftver, az alkalmazásszoftver vagy a beágyazott rendszerben lévő firmware minden digitális infrastruktúra elemi összetevője. A digitalizálási projektek egyre növekvő gyorsulása és a határidőkre nehezedő nyomás azonban gyakran vezet a feltétlenül szükséges információbiztonsági szempontok elhanyagolásához. A szoftverekkel szemben támasztott fejlesztési követelmények általában funkcióközpontúak és a konstruktív szempontokat hangsúlyozzák, így a potenciális biztonsági sebezhetőségek destruktív szemlélete többnyire szöges ellentétben áll a tényleges fejlesztési célokkal: sok programozónak egyszerűen szintén hiányzik a kiberbiztonság strukturált és kiélezett szemlélete.
Ilyen körülmények között a fejlesztőcsapatok nehezen tudják folyamatosan felülvizsgálni és következetesen biztosítani szoftvereik kódolását, amit jól mutat az a sok sebezhetőség, amelyet a non-profit MITRE Corporation minden évben közzétesz a CVE (Common Vulnerabilities and Exposures) listáján. Még a jól ismert szoftvergyártók rendszeres biztonsági javításai is jelzik, hogy milyen sziszifuszi feladat a biztonság szempontjából fontos hibák bezárása, nem is beszélve azok azonosításáról, még mielőtt a szoftverek piacra kerülnének.
Nyílt forráskód - egy különleges eset
Saját fejlesztésű szoftverek kódolásakor a programozók szívesen nyúlnak nyílt forráskódú könyvtárakhoz és modulokhoz. A gyakorlati előnyök nyilvánvalóak: ha nem kell újra és újra feltalálni a kereket, akkor előnyös ez a technológiai lökés, a gyorsabb fejlesztés, az alacsonyabb fejlesztési költségek, a nyílt forráskód révén nagyobb átláthatóság, valamint a nyílt szabványok és interfészek révén nagyobb interoperabilitás.
Azt is gyakran mondják, hogy a nyílt forráskódú kód nagyfokú biztonságot nyújt, mivel a kódot sok felhasználó validálta, és a nyílt forráskódú közösség rajos intelligenciája gyors és hatékony hibajavítást tesz lehetővé.
A gyakorlatban ezt a bizalmat most differenciáltan és kritikusan kell értékelni. A legsúlyosabb példa erre a 2021 novemberében felfedezett nulla napos biztonsági rés, a Log4Shell a Java alkalmazásokhoz széles körben használt Log4J naplózási könyvtárban, amelyet 2021 novemberében fedeztek fel. Bizonyára hallott már a német Szövetségi Információbiztonsági Hivatal (BSI) által a Log4Shellre kiadott vörös riasztási fokozatról. A Log4J könyvtár, amelyet megbízhatóan működő kvázi-szabványként az Apache Alapítványon keresztül terjesztenek, 2013 óta számos rendszerben - köztük olyan jól ismert webes szolgáltatásokban, mint az Amazon AWS - meghonosodott.
Ezeknek a jól kidolgozott és egyben karbantartott könyvtáraknak a komplexitása implicit módon olyan erős funkcionalitásokat biztosít, amelyekről az importáló fejlesztő a saját kombinált új fejlesztésében gyakran nem is tud, de a támadók számára kihasználhatók.
A nyílt forráskódú komponensek másik bizonytalansági tényezője az úgynevezett ellátási lánc támadás, azaz a nyílt forráskódú közösség részének adják ki magukat és a kódfejlesztésben közreműködnek rosszindulatú szereplők által szándékosan beépített sebezhetőségek. Az ilyen sebezhetőség rendkívül hatékony módja annak, hogy a hackerek nagyszámú későbbi felhasználó szervezetet támadjanak meg. Nem csoda tehát, hogy ez a támadási vektor gyorsan növekszik: a Sonatype tanulmánya 650%-os növekedést diagnosztizált 2020 és 2021 összehasonlításakor.
