Google Cloud DORA: Zaščita dobavne verige se začne s kulturo

Podjetja, ki se osredotočajo na zaupanje svojim razvijalcem, gledajo dlje od krivde in si prizadevajo za tesno sodelovanje, običajno opazijo večje sprejemanje ukrepov, ki prispevajo k varnejšim dobavnim verigam programske opreme.

Glede na letno poročilo Accelerate State of DevOps za leto 2022, ki ga je 28. septembra objavila skupina za raziskave in ocenjevanje DevOps (DORA) v storitvi Google Cloud, je tudi ugotovila, da so imele ekipe DevOps, ki so se osredotočale na dobre varnostne prakse, nižjo stopnjo izgorelosti, pri čemer so imele ekipe z nizko stopnjo varnosti 1.4 večkrat večje možnosti za izražanje visoke stopnje stresa.

Čeprav je tehnična infrastruktura pomagala, raziskava kaže, da je začetek ali razvoj prave kulture izjemno pomemben.

Anketa DORA, ki je bila v središču poročila, je na primer merila spoštovanje skupin DevOps do 13 različnih vidikov, ki jih je meril varnostni okvir Supply-chain Levels for Software Artifacts (SLSA), ki zahteva gradnjo izdaj izdelkov z uporabo centralizirane stalne integracije/stalnega razvoja. (CI/CD), shranjevanje zgodovine sprememb za nedoločen čas, definiranje gradenj programske opreme prek skriptov in izolacija procesa gradnje. In čeprav je večina podjetij v celoti ali zmerno uvedla vseh 13 praks, so se tista, ki so imela bolj sodelovalno kulturo in manj na obtoževanje, odrezala bolje, je pokazala raziskava DORA.

»Bolj odprte, generativne kulture … imajo ponavadi pozitivne učinke na uspešnost organizacije in tudi na ljudi, ki tam delajo,« pravi Todd Kulesza, eden od avtorjev poročila in višji raziskovalec uporabniške izkušnje (UX) pri Google Cloud. . »Želimo videti – če obstaja varnostna težava – želimo, da se inženirji počutijo pooblaščene in varne, da opozorijo na to. Nočete, da vaši razvijalci stvari pometejo pod preprogo, zlasti v smislu varnosti.«

Raziskava je na žalost pokazala, da je na področju sodelovanja še veliko dela: številni razvijalci programske opreme menijo, da obstaja prepad med programerji in ekipami za varnost aplikacij.

»Pristopi k varnosti z velikim trenjem so lahko za razvijalce frustrirajoči in na splošno neučinkoviti, saj se ljudje poskušajo izogniti točkam trenja,« je navedeno v poročilu. "Razvijalci, s katerimi smo se pogovarjali, so želeli storiti pravo stvar in so pogosto razpravljali o frustraciji, da imajo funkcije pošiljanja ali popravki dosledno prednost pred morebitnimi varnostnimi težavami."

Varnost dobavne verige: kritični barometer za uspešnost DevOps

V svojem osmem letu je Letno poročilo ekipe DevOps Research and Assessment (DORA). si je prizadeval identificirati najboljše prakse med ekipami, ki uporabljajo pristop DevOps za razvoj programske opreme. Leta 2021 je skupina DORA ugotovila, da je varnost dobavne verige programske opreme postala kritična komponenta visoko zmogljivih organizacij DevOps, zato so se letos raziskovalci osredotočili na ugotavljanje, kaj je vodilo do uspešnih rezultatov na tem področju.

V raziskavi se je Google osredotočil na sprejemanje varnostnih praks, ki so del dobavnih verig.

Poleg spoštovanja skupin DevOps do ogrodja SLSA je anketa razvijalce vprašala, v kolikšni meri upoštevajo na desetine varnostnih praks, ki sestavljajo varno ogrodje za razvoj programske opreme (SSDF), ki ga je ustvaril ameriški nacionalni inštitut za standarde in tehnologijo (NIST). .

Organizacije, ki so imele zelo kooperativne ekipe, ki so si delile tveganja in odgovornosti ter dajale prednost učenju pred obtoževanjem — tako imenovane »generativne« kulture — so bolj verjetno sprejeli več kot dva ducata teh varnostnih praks, je pokazala raziskava izvajalcev DevOps.

»Veliko teh praks – ne bom rekel, da so 100-odstotno uveljavljene v vseh organizacijah – vendar veliko teh praks ima 50 % ali več strokovnjakov, ki poročajo, da so uveljavljene ali zelo dobro uveljavljene,« pravi John Speed Meyers, soavtor poročila in strokovnjak za varnostne podatke pri podjetju Chainguard za varnost dobavne verige programske opreme. "Obstaja veliko prostora za izboljšave, vendar te stvari niso tako težke, da tega nihče ne počne."

Raziskava je merila tudi izgorelost razvijalcev na podlagi tega, kako visoko so ocenili svoje strinjanje z izjavami, kot sta "moji občutki glede dela negativno vplivajo na moje življenje zunaj dela" in "Glede svojega dela sem brezbrižen ali ciničen." Ekipe, ki se niso osredotočale na varnost, so imele 40 % večjo verjetnost, da se bodo strinjale ali močno strinjale s temi izjavami.

Poleg tega so imele ekipe, ki so imele najslabše stopnje neuspešnih sprememb in so potrebovale najdlje časa za uvajanje – od enkrat na mesec do enkrat na šest mesecev – tudi visoko stopnjo izgorelosti.