Mind több vállalat szembesül ugyanakkor azzal, hogy a szoftverbiztonság hagyományos megközelítését milyen nehéz lenne ráhúzni erre az új modellre, ezért a biztonságban sokan a DevOps akadályát látják. Az alábbiakban a probléma két vonatkozását fogom közelebbről is bemutatni, amelyek rávilágítanak, a biztonság hogyan ágyazható be a DevOps-kezdeményezésekbe a létező legjobb módon. A megközelítés további aspektusairól többet is megtudhat, ha letölti a Checkmarx biztonság és a DevOps kapcsolatát taglaló e-könyvét, de foglaljuk össze röviden, mi is a lényeg!
Hogy a DevOps összefüggésében vizsgálhassuk, tisztázzuk először a biztonság fogalmát! A szoftver világában ugyanis a fejlesztés, a tesztelés, az üzemeltetés és a biztonság sok különböző dolgot jelenthet. A biztonsági szabályok meghatározásától, a biztonsági tesztek automatizálásától és a sérülékenységek azonosításától kezdve az eredmények összevetésén és a sérülékenységek javításán át a biztonsági programok és fejlesztői KPI-k menedzseléséig és monitorozásáig a biztonság kezelésének számos szakasza létezik a szervezeteknél. Amikor a biztonság DevOpsba ágyazásáról beszélünk, akkor ezen belül több tevékenység közvetlenül az alkalmazásbiztonságot tesztelő (AST-) megoldásokhoz kapcsolódik, amelyeket a szervezetek a szoftverfejlesztés teljes életciklusán át használnak.
A DevOps két kulcsfontosságú vonatkozása például a teszteredmények összevetése (korrelációja) és a feltárt sérülékenységek javítása, a mentesítés. Ha mindkettőt a lehető legteljesebb mértékben automatizálják és integrálják, a vállalatok nagyobb értéket nyerhetnek AST-megoldásaikból. Vizsgáljuk meg ezt a két területet kicsit közelebbről!
Korreláció: teszteredmények összevetése
A korreláció célja, hogy az AST-szkennelések során feltárt biztonsági sérülékenységek kockázati fokozat szerinti rangsorolását segítse és megerősítse - különösen akkor, ha a vállalat több szkennelő megoldással végzett teszt eredményeit is összevetheti. Ha a statikus tesztelés során a SAST-megoldás például SQL injektálási sérülékenységet azonosított a kódban, és azt az IAST-megoldással végzet interaktív tesztelés is megerősíti - és ezt a két eredményt a vállalat egyetlen szoftverbiztonsági platformon összevetheti -, akkor nagy bizonyossággal kijelenthető, hogy a teszt eredménye valóban pozitív.
Ebben az esetben szinte teljesen biztos, hogy a teszteredmény megismételhető lesz. Ha ez bebizonyosodik, akkor a sérülékenységet inkább előbb szükséges javítani, mint később. Minthogy a szervezetek alkalmazások százait készíthetik és használhatják, AST-megoldásaik ezerszám találnak potenciális sérülékenységeket, ezért a méretezés képessége itt kezdődik - a tesztelésekből származó hatalmas adatmennyiség értelmezésével. Manapság éppen emiatt elvétve fordul elő, hogy egy vállalat kézi úton veti össze a teszteredményeket. A szervezetek vagy megfelelő eszközöket használnak erre, vagy egyszerűen nem végeznek korrelációt.
Kockázatmentesítés: a feltárt sérülékenységek javítása
A kockázatmentesítés két fő vonatkozása, hogy mit és hogyan kell javítani. Ha méreteiben szemléljük a problémát, akkor könnyen beláthatjuk, hogy nincs az a fejlesztő, aki sérülékenységek ezreivel megbirkózna. Létfontosságú ezért, hogy a vállalat rangsorolja, priorizálja a feltárt, potenciális sérülékenységeket, mert a fejlesztők így tudják érdemben áttekintetni azokat. Márpedig a fejlesztőknek a lényegre, azon sérülékenységekre kell összpontosítaniuk, amelyek javításával exponenciálisan csökkenthetik a biztonsági kockázat szintjét.
Fontosabb nem is lehetne ezért, hogy a vállalat megfelelő mechanizmussal automatizálja a sok ezer teszteredmény rangsorolását, feltételrendszerek felállításával meghatározza, hogy mi a fontosabb, és mi bír kisebb jelentőséggel. Egy nyílt forráskódú szoftver frissen felfedezett sérülékenysége például fontosabb lehet, mint az egyedi, zárt kódé, és egy 60 napja ismert sérülékenység javítása is fontosabb lehet, mint egy újonnan felfedezetté. Nagyon sok feltétel szerint meghatározható, hogy a teszteredmények rangsorolása milyen szempontok szerint történjen. Miután a vállalat automatizálta ezt a folyamatot, méretezni is tudja, és minden fejlesztőhöz fontossági sorrendben eljuttathatja a kódrészleteket, amelyeket javítani kell.
Ha a vállalat AST-megoldásának része az automatikus priorizálás mechanizmusa, akkor annak tartalmaznia kell a gépi tanulás algoritmusait is, amelyek a fejlesztők és az alkalmazásbiztonsági csapatok figyelmét a ténylegesen pozitív teszteredményekre irányítják - napjainkban már a találatok százalékos súlyozásán keresztül. Az algoritmusok például megtaníthatók rá, hogy megértsék, a sérülékenységek mely típusai bizonyulnak leggyakrabban ténylegesen pozitív találatnak, illetve milyen típusú sérülékenységekről derül ki utóbb a legtöbbször, hogy elenyésző kockázatot hordoznak vagy veszélytelenek, álpozitívak. A gépi tanulásnak ez a képessége rendkívüli mértékben növeli a rangsorolás megbízhatóságát és az automatizálás hasznosságát.
Miután a biztonsági csapat - gyakran előre meghatározott szoftverbiztonsági szabályzat alapján - egyetértésre jutott abban, hogy mely sérülékenységeket szükséges javítani, a következő döntés az, hogy miként történjen ez a mentesítés. A biztonságos kódolás olyan segédletei (Secure Coding Education, SCE), mint a Checkmarx Codebashing ebben sokat segítenek. A Codebashing a sérülékenységek különböző típusaira szabott feladatokon keresztül tanítja meg a fejlesztőket a javításra, méghozzá közvetlenül az általuk használt fejlesztőkörnyezetbe (IDE-be) integrálható módon.
Ha a szervezetek a lehető legáramvonalasabb folyamatban vetik össze a bevezetett AST-megoldásaikból származó találatokat, juttatják el az eredményeket a fejlesztőknek és az alkalmazásbiztonsági csapatoknak a feltárt sérülékenységek javításához, akkor nagy méretekben is csökkenteni tudják a biztonsági kockázatot. Olyan platformot érdemes választaniuk ehhez, amellyel összegyűjthetők a különböző AST-megoldásokkal végzett tesztek eredményei, és azok rangsorolása is automatizálható a gépi tanulás algoritmusaival, a korreláció, a szabályok finomhangolása és az egyedi súlyozás által.
