Secure Scrum: válasz az agilis módszertanok biztonsági hátulütőire?
Egy új szoftverfejlesztési módszertan van kialakulóban, mely megoldást nyújthat olyan biztonsági problémákra, amik jellemzően az agilis módszertanok "melléktermékei". Két német kutató vizsgálta meg, hogy az agilis munkaszervezés az egyértelmű előnyei mellett milyen biztonsági kockázatokat rejthet, és kutatásuk eredményeként a Scrum egy új változatát is kidolgozták, mely gyógyírt jelenthet a problémákra.
Miért a Secure Scrum?
Hans-Joachim Hof, a müncheni egyetem professzora, és PhD hallgatója, Christoph Pohl azt kutatták, hogy napjaink webalkalmazásai miért sebezhetőbbek az átlagnál, mikor meglepő módon arra jutottak, hogy ennek egyik oka az alkalmazott agilis módszertanok folyamataiban rejlik. Ezt követően kezdtek el kifejezetten erre a témára fókuszálni, és arra jutottak, hogy ezeknek a módszertanoknak bizony szükségük lenne egy biztonsági "keretrendszerre".
Az eredmény egy, a Secure Scrum: Development of Secure Software with Scrum névre hallgató tanulmány lett, melyet az augusztus végi SECURWARE konferencián mutatnak majd be.
A konklúzió az lett egyébként, hogy míg az agilis projekteknél a korai tervezési fázist próbálják minimális hosszúságúra redukálni, hogy minél előbb egy működő alkalmazást tudjanak produkálni, addig ezzel pont az a tervezési és elemzési szakasz marad ki a folyamatból, ahol a főbb biztonsági kérdések is felmerülhetnének. Így az ilyen jellegű problémák hamar "mozgó célponttá" válnak a fejlesztés során, rendkívül megnehezítve a kiküszöbölésüket.
Hogyan működik a Secure Scrum?
A Secure Scrumban a legfontosabb, hogy a biztonsági kockázatok kerüljenek rögzítésre a backlog létrehozásakor épp úgy, mint később a sprintek tervezésekor. A user story-k kidolgozásakor minden egyes sztorihoz fel kell tüntetni, hogy milyen biztonsági kockázat tartozik hozzá, és aztán a sprintek összeállításakor az egyes sztorikat a kapcsolódó kockázat nagysága alapján kell rangsorolnunk.
Hof és Pohl azt állítják, hogy más hasonló kezdeményezésekkel (pl. az S-Scrum is ilyen) szemben a Secure Scrum sokkal kevésbé észrevehető módon avatkozik bele a hagyományos Scrum folyamatokba, hiszen a fő cél csupán az, hogy a kockázati tényezők mindig legyenek szem előtt a fejlesztés során, ehhez pedig nincs szükség például külön security backlogra.
Működik-e a gyakorlatban?
A kutatók a feltételezéseik bizonyítására 16 harmadéves informatikus hallgatót osztottak 3 csoportba. A csoportoknak 6 darab funkcionális követelmény alapján kellett egy közösségi hálózat prototípusát elkészíteniük egy hét alatt úgy, hogy egyikük a Scrumon kívül bármilyen módszertant alkalmazhatott, egy másik csoport kizárólag a Scrumot, a harmadik pedig a Secure Scrumot.
Az eredmény ugyan a biztonsággal kapcsolatos feltevéseket igazolta, hiszen lényegesen kevésbé volt sebezhető a Secure Scrumos csapat "végterméke", ám az erre fordított idő meglátszódott annak készültségi állapotán: a másik két csapat tovább jutott, de sebezhetőbb volt az alkalmazásuk.
Ez most akkor a legújabb spanyolviasz, vagy csak új nevet adtak a "gondos tervezésnek"?
Jó kérdés, de az biztos, hogy élesben még nem bizonyított a Secure Scrum. Személy szerint pedig jogos kritikának érzem, hogy nem minden esetben volna indokolt az agilis módszertanok nyakába varrni azt, ha egy csapat hanyagul tervez a fejlesztés bármely szakaszában.
Szerintetek?