A fejlesztés biztonságán az információbiztonsági szakma már régóta keresi a fogást. Sokáig ez nem volt több, mint a fejlesztés elején meghatározott biztonsági elvárások halmaza, lehetőleg jó általánosan, majd, jó esetben, a fejlesztés legvégén egy sérülékenységvizsgálat. A kettő között a fejlesztőre volt bízva, hogy eljusson a biztonságba. Így utólag, együttérző empátiával felvértezve, kijelenthetjük, hogy nem volt egy sikertörténet.
A 2010-es években azonban megjelent egy új gondolat: mi lenne, ha a biztonságos eredményterméket (szoftvert) folyamatában, a fejlesztői munkába beépülve próbálnánk meg garantálni? A gondolatot a biztonsági szakma kényszere szülte, mivel addigra a cégekben a fejlesztési ciklus olyannyira felgyorsult, hogy nehezen lehetett az elejét és a végét megtalálni, de közepe még mindig volt: amikor a fejlesztő fejleszt. Ebből lett a DevSecOps.
Az elképzelés szép és elegáns, de előbb-utóbb minden stratégia, presales-prezentáció, üzleti reggeli, lelkesítő gondolat munkává kell fajuljon. „Saját tapasztalatom alapján a DevSecOps, a biztonságos fejlesztés gondolatának átültetése a napi fejlesztői gyakorlatba pedig egyáltalán nem könnyű.”, mondta el Alföldi Judit, a Tigra Kft. információbiztonsági üzletágvezetője.
Ráadásul a DevSecOps-szemlélet gyakorlatba ültetéséhez az üzleti, vezetői oldal is csak egy bizonyos mértékig hajlandó a támogatást biztosítani, és az rendszerint kevesebb, mint amennyi a DevSecOps bevezetéséhez kell. Mindezek ellenére a kérdéssel foglalkozni kell, de egy reality check mindenképp indokolt! Célszerű az elvárásokat csak kicsit a lehetőségek fölé helyezni és fokozatosan haladni: egy sikertelen piruettnél jobban mutat egy stabil félfordulat. „Őszintén szembe kell nézni azzal, hogy hol tart a szervezet, igen, át kell világítani, és pár quick winnel kezdeni. Szerencsére elég jól dokumentált, hogy mások hol tartanak, hogy csinálják. Haladjunk járt úton!”, szögezte le Alföldi Judit.
| A biztonságközpontú szoftverfejlesztés problémái
– Széttartó fejlesztési technológiák és módszerek: a DevSecOps alkalmazása nagyfokú egységesítést és automatizmust feltételez, mivel a sok plusz feladat hatékonyan nem hajtható végre. – A fejlesztők túlterheltsége: akármennyire is szeretnénk, a DevSecOps igenis plusz munkát jelent. Ennek helyet kell találni, ami minél kevésbé hatékony a szervezet, annál nehezebb. – A dedikált figyelem és szakértelem hiánya: leegyszerűsítve a biztonságiak nem értenek a fejlesztéshez, a fejlesztők a biztonsághoz, de szót kell érteniük. Ki lép a másikhoz közelebb? Vagy mindkettő egyet-egyet és középen találkoznak? Ez a tudás nemcsak a szervezeteken belül, de a piacon is ritka kincs. |
Fontos, hogy a DevSecOps bevezetését ne egy technológiai megoldásokkal megtámogatott adminisztratív problémának tekintsük. Érdemes tapasztalatot, szervezeti elfogadást gyűjteni egy-egy kiválasztott kritikus projekten, csapaton keresztül, megtalálni a szervezeten belüli támogató személyeket, fel nem fedezett biztonsági bajnokokat.
Végül a legfontosabb: oktatás, képzés, párbeszéd. Ha a fejlesztő és a vezetőség is tudja, hogy mit miért kell csinálni, illetve milyen kockázatokkal jár az elhagyásuk, sokkal könnyebb a támogatást megszerezni. „A fejlesztőt nem kontrollálni kell, hanem támogatni, hisz erről is szól a DevSecOps. A tudás átadása a támogatás egy gyorsan megtérülő módja”, hangsúlyozta Alföldi Judit.
A siker nem lehetetlen, de munkás lesz. Az „o” betűk száma csak így csökkenthető a szükséges egyre!
