Egy kiterjedt kutatás szerint a fejlesztőcsapatok 70 százaléka (!) mindig vagy legalábbis gyakran átugorja a biztonsági lépéseket a projekthatáridő kényszere miatt. Ez a magyarázata annak, hogy a szervezeteknél átlagosan a biztonsági problémák harmada (33 százalék) vezethető vissza a termékkódra.

A biztonsági és fejlesztői csapatok folyamatosan egy 22-es csapdája helyzetet kell megéljenek. Folyamatosan időnyomás alatt dolgoznak, hogy kielégítsék a szervezet egyre mohóbb digitális innovációs igényét, de ezzel egyre nagyobb lesz a vállalatok kiberbiztonságát veszélyeztető támadási felület. És bár vannak mindenféle módszerek az innováció és a biztonság összehangolására, a fejlesztők a rájuk nehezedő stressz miatt sokszor hoznak rossz döntéseket. A problémakört egy fiatal amerikai biztonsági startup, a 2018-ban alapított Invicti Security kutatta.

A cég idei AppSec Indicatora nem szűken ezt a helyzetet vizsgálta, hanem azt is, hogy milyen hatást gyakorol a biztonsági szakemberek, fejlesztők és vezetőik gondolkodására. Bár a minta az amerikai piacról állt össze (200 IT- és biztonsági vezetőt, kb. ugyanennyi fejlesztőt és DevOps mérnököt, valamint szintén 200 biztonsági szakembert kérdeztek meg), a szakma nemzetközisége miatt – egy fejlesztő például szinte a világ bármely szegletéből végezheti a munkáját – a megállapítások bárhol megállják a helyüket.

Látszik a kultúraváltás iránya

Jóllehet az első adat talán sokkoló, ugyanakkor az is látszik, hogy elindult ezen a téren a kultúraváltás. A szervezetek 86 százaléka az elmúlt egy évben már fokozottan figyelt a webalkalmazások biztonságára, amelyért a fejlesztő csapatot kiemelt felelősség terheli. A szervezetek 57 százalékában pedig bevezették azt, hogy a fejlesztő csapat biztonsági teljesítményét ugyanazokkal a KPI-kkel mérték, mint a biztonsági csapatét. Ez elsőre talán durvának hangzik, de ha jól belegondolunk, a megközelítés érthető: a biztonsági csapatnak azokat a rendszereket kell megvédeniük, melyeket a fejlesztők leszállítanak.

Nagyon érdekes ugyanakkor, hogy ez az újfajta megközelítés közel hozta egymáshoz a két területet. A biztonsági és fejlesztési szakemberek 41 százaléka familiárisnak ítélte a két terület viszonyát (az árnyaltabb adatokra kíváncsiaknak: a fejlesztők 55, míg a biztonsági szakemberek 37 százaléka választotta ezt az értékelést). Közös pontként a biztonság iránti elkötelezettséget és az egy csapatként végzett munkát jelölték meg. További 36 százalék szerint pedig az jellemzi legjobban az együttműködésüket, hogy ők a "legjobbak", akik gyakran együttműködnek a biztonsági kérdések megoldása érdekében.

Az már más kérdés, hogy bár a biztonsági szakemberek általában magasra értékelik a fejlesztők IT-biztonsági felkészültségét, a fejlesztők még felkészültebbnek tartják magukat. Arra a kérdésre, hogy mennyire hatékony a fejlesztői csapat a biztonsági problémák kezelésében, a biztonsági szakemberek fele mondta azt, hogy nagyon, 48 százalékuk pedig, hogy valamennyire felkészültek. Ezzel szemben a fejlesztők 66 százaléka értékelte saját csapatát nagyon, és csak 33 százalék valamennyire felkészültnek.

Mindezzel együtt az általános az, hogy az innováció prioritást élvez a biztonsággal szemben, és csupán a szervezetek 20 százaléka integrálta teljes mértékben a biztonságot a fejlesztésbe. Értelemszerűen itt kiemelt a vezetők szerepe. Ha maguk is felismerik például a webes alkalmazások biztonságának fontosságát, akkor engednek annak a lentről érkező kezdeményezésnek, hogy a biztonsági és a fejlesztési csapat mélyrehatóan szeretne együttműködni. Azt kell felismerniük, hogy ezáltal például jobban kalkulálhatóvá (és kivédhetőbbé) válnak a kockázatok.

A tanulmány innen (PDF) tölthető le.