DevOps Security
--Dkisic2 17:34, 25. siječnja 2016. (CET)
Sadržaj |
Uvod
Što je to DevOps? DevOps je termin nastao spajanjem riječi development i operations, a on označava praksu koja stavlja naglasak na suradnju i komunikaciju softver developera i drugih IT stručnjaka automatizirajući na taj način proces razvoja softvera te infrastrukturnih promjena. Glavni cilj je postizanje radne okoline u kojoj će razvoj, testiranje i isporuka softvera biti brže, ali i pouzdanije. Popularnost je svakim danom sve veća, a o tome dovoljno govori podatak da ga koriste najveće kompanije poput Facebooka, Amazona, Netflixa, Twittera i Linekdina.
DevOps je čvrsto povezan s agilnim pristupom razvoja softvera. Stoga ga je najlakše opisati, proširujući definiciju agilnog pristupa. Ta definicija se sastoji od četiri ključna svojstva, a DevOps će biti opisan na način da se doda i peto svojstvo. Ovo su glavna svojstva agilnog pristupa:
AGILNE VRIJEDNOSTI – ovo su ključne (core) vrijednosti koje agilni pristup koristi
AGILNI PRINCIPI – sastavni dio strategijskih pristupa koji podržavaju vrijednosti
AGILNE METODE – implementacija principa, XP, Scrum itd.
AGILNI ALATI – tehničke implementacije metoda koje timovi koriste kako organizirali svoj rad , JIRA, planningpoker.com itd.
Kao što je rečeno prije, DevOps pristup će biti opisan dodavanjem i petog svojstva:
DEVOPS VRIJEDNOSTI – glavne vrijednosti opisane su Manifestu agilnog pristupa
DEVOPS PRINCIPI – proširivanje agilnih principa na način da se uključe sistemi i operacije, a ne da se prestanu razmatrati već nakon provjere koda
DEVOPS METODE – slično kao agilni pristup, koriste se Scrum , Kanban itd.
DEVOPS PRAKSE – specifični načini na koje se implementiraju gornji procesi i koncepti, npr. kontinuirana integracija, cloud computing itd.
DEVOPS ALATI – skup alata koji se koriste, a dobro se uklapaju u DevOps praksu, npr. Jenkins, travis, noah, AWS, OpenStack itd.
Nešto stariji pogled na DevOps praksu razdvajao je ovo Dev stranu kao "stvaratelje", a Ops stranu kao "ljude koji, nakon što je nešto stvoreno, brinu o tome". [1]
TRADICIONALNE METODE KONTROLIRANJA SIGURNOSTI WEB APLIKACIJA
TEST PENETRACIJE – softverski napad koji traži slabosti u sustavu sigurnosti, pokušava doći u posjed podataka koji se nalaze na računalu
VATROZID WEB APLIKACIJE – skup pravila koji se odnosi na HTTP izmjene, obično pokriva najčešće tipove napada poput XSS-a i SQL injectona.
ANALIZA KODA – traženje potencijalnih prijetnji unutar izvornog koda
Te metode same ne mogu odgovoriti na izazove koje donosi moderni pristup razvoj kao što je DevOps. Test penetracije primjerice zahtijeva bar 2 tjedna da bi se mogao donijeti sud o sigurnosti, a usto dolazi i još par stotina stranica dokumentacije. Analiza koda dijeli se na tri dijela : setup, running i analysis. To također zahtijeva puno vremena. Zbog toga se javlja potreba za novim, sigurnim pristupom razvoja softvera. Taj pristup dolazi kroz pet koraka:
Planiranje sigurnosti – identificirati nesigurne API-je i frameworke, mapirati sigurnosno osjetljive dijelove koda (mehanizam promjene lozinke, autentikacija korisnika), planirati i pripremiti se za regulatorne probleme
Povezati developere – koristiti platforme za online suradnju (Jive, Confluence), imati otvoren pristup
"Naoružati developera" – koristiti sigurne frameworke (Spring Security, JAAS, Symfony2), koristiti alate koji mogu dati informaciju o sigurnosti u pre-commit fazi
Automatizirati proces – integracija unutar razvoja (Jenkins, Bamboo), prekinuti razvoj ako sigurnost nije na zadovoljavajućoj razini
Koristiti "stare" metode – periodični testovi penetracije, vatrozid, analiza koda za sigurnosno osjetljive dijelove koda [2]
DevOps i sigurnost - DA
Svakim danom sve više kompanija koristi DevOps kako bi razvojni proces, koji se sastoji od više različitih koraka, spojili u jedinstveni, automatizirani proces. IT stručnjaci iz svih područja rade zajedno ispočetka kako bi drastično skratili vrijeme potrebno za razvoj softvera. Tako se u tim pokušava i uklopiti i sigurnosne stručnjake kako bi oni radili na projektu kao dio cjeline od samog starta, a ne zasebno kao što je to često bio slučaj. Ideja da u DevOps-u nema mjesta za sigurnost je mit. DevOps integrira mnogo funkcionalnih cjelina, uključujući i sigurnost u konačni proizvod. Najveća razlika u odnosu na stare pristupe je u tome da se svačiji doprinos procjenjuje ranije i zatim pokušava automatizirati kako bi se osigurala kvaliteta, ali još važnije i raniji i predvidljiviji rokovi isporuke proizvoda. Ovo su neke od najčešćih zablude koje se tiču sigurnosti:
Sigurnost je teško uklopiva u DevOps – DevOps je zapravo blagodat za sigurnosne stručnjake, uz prave alate i dobar postupak automatizacije, sigurnosni propusti mogu se ukloniti već u startu razvoja
Alati za upravljanje konfiguracijom su dobri za sigurnost – alati poput Puppeta i Chefa odlični su za razvoj aplikacije, ali jednostavno nisu dovoljno napredni da analiziraju i ocijene sigurnost poput sigurnosnog stručnjaka te također nisu dizajnirani kako bi upravljali sistemom na način koji je potreban kako bi se osigurala sigurnost tokom vremena
DevOps eliminira potrebu za sigurnosnim stručnjakom – većina developera ima tek osnovno znanje o sigurnosti te je zbog toga svakom projektu potreban stručnjak koji će u suradnji s drugim kolegama procijeniti rizike, poduzeti adekvatne mjere te spriječiti opasnosti na vrijeme
Kompanije i DevOps su kao ulje i voda – oni možda ne nude najprirodniju suradnju, ali većinu zahtjeva koje biznis postavi DevOps može ispuniti, problem se može javiti jedino oko sigurnosti, čiju važnost kompanije često ne prepoznaju [3]
U budućnosti će naglasak i dalje biti stavljen na automatizaciji. Sigurnosni stručnjaci već su prigrlili taj trend te se radi na mnogim novinama koji će revolucionalizirati način na koji se aplikacije razvijaju. Primjerice, biti će moguće umetnuti alate za analizu koda u proces razvoja i primorati da se problemi riješe prije isporuke proizvoda. Ili pokrenuti automatizirane napade na kodu, te ukoliko su uspješni, spriječiti isporuku nedovršenog proizvoda. Ovo su samo neki od primjera, a kada se oni ujedine, činit će skup najboljih praksi dizajniranih kako bi pomogli kompanijama da umetnu sigurnosne provjere u samu jezgru DevOps razvojnih procesa. Takvo što je godinama bilo san sigurnosnih stručnjaka koji bi svoj posao, kao u vodopadnom modelu, odradili tek na kraju procesa. Umetanje sigurnosnih provjera u razvojni proces donijet će mnoge boljitke. Što prije prijetnja bude otkrivena, prije će se ona i riješiti, a to donosi bolji te otporniji proizvod. Danas više nema smisla riskirati sa sigurnošću. Propusti u sigurnosti idnose preko 100 milijardi dolara godišnje samo u SAD-u. Ključ za integraciju sigurnosti u DevOps je dodavanje procjene prijetnje, modeliranja rizika i penetracijskih testiranja što je ranije moguće. [4]
DevOps i sigurnost - NE
Spojiti DevOps i sigurnost u praksi nije baš najlakše. Problem leži prije svega u biznisu koji ne uspijeva prepoznati važnost sigurnosti. Bolje rečeno, biznis investira u ono što biznis razumije, a to su načela poput "isporuči moj softver brže", "zaradi više novca" itd. DevOps to može ispuniti, ali se u toj žurbi često zapostavi sigurnost. Zbog toga bi bilo poželjno da svakim tim koji radi na ozbiljnijem problemu ima sigurnosnog stručnjaka.
Nedavna anketa također je pokazala poraznu statistiku, gotovo pola ispitanika priznalo je da isporučuju aplikacija znajući za njihove ranjivosti gotovo 80 posto vremena. U savršenom svijetu, aplikacije bi bile kodirane sigurno, prolazile bi sva skeniranja za ranjivosti i penetracijske testove i nikad se ne bi susrele sa zero-day napadima. Nažalost, neranjivi kod ne postoji. Još jedna anketa koja je ispitala oko 200 softver developera pokazala je kako preko 70 posto njih zbog pritiska za objavom ažuriranja svjesno zanemaruje sigurnosne nedostatke. [5]
Kako uklopiti sigurnost u DevOps
DevOps kao što mu govori i ime, je spajajanje developmenta i operacija u jednu cjelinu. Ovo je dosta bitno za sigurnost. Većina timova proteklih desetljeća oslanjala se na koncept zvan "nightly builds" gdje bi se sav kod koji je napravljen prethodnog dana kompilirao preko noći, a onda bi se ujutro pregledavale eventualne greške. To je samo jedan od koraka koji vodi do automatizacije procesa koji podržavaju razvoj softvera. Put do DevOpsa obično dolazi u dvije faze: prva je kontinuirana integracija, koja se bavi buildanjem i testiranjem koda, a drugi je kontinurana implementacija, koja skuplja cijeli aplikacijski stog u izvršnu okolinu.
Kontinuirana integracija
Suština kontinuirane integracije su svakodnevne provjere koda od strane developera. Kod većina timova, to predstavlja više ažuriranja dijeljenog izvornog koda i obično jedan build dnevno. Glavna ideja su manje i jednostavnije promjene jer to je način na koji je lakše proinaći grešku u kodu. To su zapravo agilni koncepti, ali implementirani u procesima koji pokreću kod, a ne u procesima koji kontroliraju rad ljudi na projektu. Kontinuirana integracija kod DevOpsa znači da kod nije samo buildan i integriran, već je automatski otpremljen na testiranje. Također, promjene u kodu neće biti primijenjene samo na grani, već će biti stavljene u glavni dio koda te će se na taj način smanjiti kompleksnost. Konceptualno, ovo zvuči veoma jednostavno, ali u stvarnosti to zahtijeva puno pomoćne infrastrukture. Build proces javlja se odmah nakon što je kod mijenjan te se nakon toga šalje na testiranje.
Kontinuirana implementacija
Veoma je slična integraciji, samo što je fokusirana na isporuku softvera krajnjim korisnicima, a ne na build. Također uključuje slične procese poput pakiranja, testirana i praćenja, ali s nekim dodatnim modifikacijama. Na sljedećoj slici prikazani su i tok koda, od početka pa sve do isporuke te alati koji daju podršku automatizaciji.
Nakon uspješnog kompletiranja kontinuirane integracije, rezultatit dolaze do procesa vezanih uz kontinuiranu implementaciju. Ona zatim poduzima jedan veliki korak prema automatizaciji te pristupa svakom problemu koji koči implementaciju, posebno se to odnosi na promjene koje su sklone greškama. Isto radi i s razlikama u revizijama pomoćnih biblioteka korištenih od strane dev i op timova. Vjerojatno najvažniji je korištenje koda i infrastrukture tako da je moguće kontrolirati implementaciju te se vratiti na ranije stanje u slučaju grešaka. [6]
Integracija sigurnosti iz SDLC perspektive
Secure Development Lifecycle (SDLC) ili životni ciklus sigurnog razvoja softvera opisuje različite funkcije unutar razvoja softvera. Često ljudi miješaju SDLC s vodopadnim modelom, što čini diskusiju o spajanju SDLC s DevOpsom jako zamršenom. Ali postoje dobri razlozi za to. Arhitektura, dizajn, razvoj, testiranje, isporuka su faze SDLC-a koje se dobro uklapaju u uloge razvojne organizacije. [7]
Definiraj
Operacijski standardi: Tipično u ranoj fazi razvoja sotvera, fokus je stavljen na veliku sliku aplikacijske arhitekture i kako će veliki funkcionalni dijelovi zajedno raditi. S DevOpsom, također se definiraju operativni standardi za okolinu. Isto kao što se to ostvaruje s kodom, tako se i s operativnim standardima svaki dan ostvaruje mali, iterativni napredak. To uključuje ažuriranja infrastrukture, ali i definiranje smjera u kojem će ići aplikacijska sigurnost, kako će popravci biti uključeni, upravljanje konfiguracijom, testiranje itd. Ti će standardi biti sakupljeni u priče koje će biti poslane Ops timu tijekom faze razvoja Sigurnosne potrebe: Koji će sigurnosni testovi biti provedeni i kojim će alatima to biti obavljeno. Kao minimun, potrebno je definirati sigurnosne potrebe za sav novi kod te odrediti tim koji će to testirati prije certificiranja. To znači battery ili unit testove za specifične prijetnje koje su time dodijelenje – primjerice Owasp Top Ten. Ili pak izabrati neki komercijalni alat. Na tržištu postoji mnoštvo takvih alata ali nemaju svi API-je ili mogućnosti da budu potpuno integrirani u DevOps. Slično, mnogi testovi ne izvršavaju se jednako brzo kao i razvojni ciklus tako da odluka nije nimalo lagana.
Metrika i nadziranje: Ako sa svakom distribucijom dolaze male, iterativne promjene, što treba popravljati? Što radi dobro i kako to dokazati? Metrika je ključna za odgovor na ova pitanja. Potrebno je razmisliti koji će podaci biti prikupljani i kako će oni biti uključeni u kontinuiranu integraciju i implementaciju da bi se izmjerile performanse. [8]
Dizajn
Sigurni dizajn / arhitektura: DevOps pruža načine za značajan napredak u dizajnu sigurne arhitekture. Pošto je cilj automatizirati popravke i konfiguracije za implementaciju, moguće je u potpunosti onesposobiti adminisitrativne konekcije do produkcijskih servera. Greške se popravljaju u buildu i automaticijskim skriptama, a ne ručno. Također je moguće u potpunosti onemogućiti mrežne portove i pristupne točke koje se koriste u administrativne svrhe. DevOps donosi veliki napredak osnovnoj sigurnosti sistema, ali je potrebno specifično dizajnirati način implementacije kako bi se utjecalo na prednosi koje kontinuirana integracija pruža.
Osigurati implementacijsku okolinu: S većom kontrolom nad proizvodnom oklinom, razvojni i testni serveri postaju atraktivnija meta. Oni obično imaju malo ili ništa sigurnosti. Ali javlja se veća potreba za sigurnijim upravljenjem nad izvornim kodom te build serverima. Mora se osigurati stroža kontrola nad pristupom prema ovim sistemima. I zbog manjka ljudskog kontrole nad skriptama koje se kontinuirano izvršavaju u pozadini, potrebno je zadužiti nekoga da to počne pratiti kako bi greške i nepravilno korištenje bilo detektirano i ispravljeno. Model rizika: Modeliranje rizika još uvijek je jedno od najproduktivnijih područja u sigurnosti softvera. DevOps to ne mijenja, već omogućuje da sigurnosni stručnjaci ukažu članovima Dev tima na potencijalne prijetnje te im pomognu u planiraju jediničnih testova za takve tipove prijetnji. [9]
Razvoj
Infrastruktura i automatizacija prva: Kod DevOpsa, i posebno sigurnosti, integriranje alata te sastavljanje testova radi se prije nego što se počne razvijati sljedeći set svojstava. Tako planiranje dolazi u prvi plan. Dev timovi planiraju testove i alate koji su im potrebni prije nego što krenu na samo kod. Loša vijest je da se troškovi javljaju unaprijed, a dobra je da sada svaki build ima utjecaja na korištene alate i infrastrukturu.
Sigurnosni zadaci: Umjesto da se piše ogromni specifikacijski dokumenti za kvalitetu i sigurnost koda (kao što se to radilo u vodopadnom modelu), ovdje se politika dokumentira u funkcionalnim skriptama i programima. Jedinični testovi nisu tu samo kako bi definirali, već i proveli sigurnosne zahtjeve.
Sigurnost u Scrumu: Kao što je napomenuto ranije, DevOps je procesno neutralan. Moguće je koristiti spiralne, agilne i druge pristupe razvoju softvera. Ali ipak, korištenje agilnih Scrumova ili Kanbana je najprimjerenije DevOpsu. Fokus je stavljen na manje, lakše objašnjive zadatke. Za sigurnosne zadatke, oni nisu ništa manje bitni nego bilo kakvi drugi strukturalni napredak. Preoporučljivo je trenirati barem jednu osobu u timu osnovama sigurnosti, po mogućnosti onu koja za to pokazuje najviše interesa. Na taj način moguće je raspodijeliti sigurnosne zadatke osobama koje imaju adekvatno znanje, ali i želju suočiti se s takvom vrstom problema. [10]
Test
Borba s greškama: U mnogim situacijama, DevOps izvrće dugo korištene principe naglavačke. Izdržljivost je predstavljala iskorišteno vrijeme, a danas predstavlja brzinu zamjene. Detaljne specifikacije su korištene kako bi se koordinirali Dev timovi, a sada su to samo bilješke. Osiguranje kvalitete bilo je fokusirano na to da kod ispuni funkcionalne zahtjeve, a sada pokušava slomiti aplikaciju prije nego što to uradi netko drugi. Cilj nije samo ugraditi sigurnosne testove u automtizirane procese, već podići ljestvicu za ono što je prihvatljivo objaviti. Aplikacija se namjerno udara na sve moguće načine, funkcionalnim, stres i sigurnosnim testovima prije nego što dođe u ruke sigurnosnih stručnjaka. Ako je moguće naći način da se slomi aplikacija, postoji vjerojatnost da to napravi i napadač, stoga je potrebno učiniti sve kako bi se to otkrilo te eventualni propust na vrijeme otklonio.
Ubrzati sigurnosna testiranja: Problem sa svim agilnim pristupima je što napraviti s testovima koji traju duže od razvojnog ciklusa. Testiranje kritičnih dijelova koda obično traje duže nego prosječni sprint. DevOps nije nimalo drugačiji u tom pogledu. Kako bi se taj problem riješio, DevOps timovi provode sigurnosna testiranja paralelno. Validacija protiv poznatih kritičnih pitanja napisana je kao više jediničnih testova, a greške se odmah prosljeđuju Dev timu. Skeneri koda također se pokreću paralelno. Rezultate toga također dobiva Dev tim te često imaju puno problema jer izvor dosta teško odrediv. [11]
Implementacija
Manualna vs automatska implementacija: Lagano je gurnuti novi kod u produkciju. Zabraniti taj kod ili vratiti se na prijašnje stanje je kompleksno. Većina timova još nije u fazi prihvaćanja potpunog automatiziranja implementacije. Dosta njih isporučuje kod tek svakih par tjedana. Svakim danom javlja se sve više koji podržavaju potpuno automatizirani način. Ovdje ipak nema pravog odgovora, no u svakom slučaju, automatizacija odrađuje veliki dio posla te oslobađa ostale od testiranja i praćenja.
Vraćanje na prethodne verzije: Još uvijek se koristi metoda dvostruke provjere, timovi još uvijek rade i "dimne" testove, ali su postupno automatizirali te postupke te stekli veću kontrolu nad vraćanjem prethodnih verzija. Tipično, koriste se tri metode. Prva je nazvana Plavo-zelena implementacija. Jednostavno, novi i stari kod se pokrenu istovremeno, svaki na svom setu servera. Ako se nađu greške na novom, slijedi povratak na stari kod. Sljedeća nosi zanimljiv naziv "Canary testing". Određeni broj individualnih sesija usmjerava se prema novom kodu, prvo testiraju zaposlenici, a zatim i pravi klijenit. Ukoliko "canary" umre, tj. jave se greške, novi kod se povlači sve do trena kad se i zadnja greška ne otkloni. I zadnja, označavanje svojstava gdje se novi elementi koda budu aktivirani ili deaktivirani preko konfiguracijskih datoteka. U slučaju da bude pronađena greška, svojstvo može biti deaktivirano, a kod zamijenjen kada bude popravljen. Stupanj automatizacije i ljudskog utjecaja varira, no opet, ovo je dosta automatiziranije nego ostale metode.
Testiranje sigurnosti proizvoda: Ovdje mogu biti iskorištene gore spomenute metode. Relativno je lako postići da "canary" bude neka vrsta dinamičnog skenera koda, tester penetracije ili neki drugi. Kada se to objedini s testnim računima korištenim za invazivno testiranje sigurnosti, rizik od korupcije podataka je smanjen, a opet je omogućeno da sigurnosni testovi budu izvedeni u produkcijskoj okolini. [12]
Primjer iz prakse
Netflix je multinacionalni pružatelj medija na zahtjev koji koristi DevOps praksu. Oni imaju preko 62 milijuna korisnika (vjerojatno i više), a njihovi developeri gotovo tisuću puta na dan commitaju promjene. Stoga tom načinu razvoja najbolje odgovara DevOps. Ipak, prethodno spomenute brojke predstavljaju velik izazov kada je sigurnost u pitanju. Ali uz pomoć automatizacije i nekih drugih pristupa oni uspijevaju iskontrolirati potencijalne sigurnosne prijetnje, a istovoremeno također zadržati i veliku brzinu usluge. Od 2011. Netlix je razvio niz sigurnosnih alata poput Security Monkeya. Scumblra i Fully Integrated Defense Operationa (FIDO) koji automatiziraju sve od pronalaženja kompromitiranih pretplatnika pa do odgovarajućih akcija prilikom sigurnosnih incidenata.
Security Monkey je softver otvorenog koda koji interno prati sigurnost konfiguracija. Kako Netlix upravlja svojom infrastrukturom u okviru Amazon Web Servisa, alat kontinuirano motri sigurnosne postavke AWS-a. Također sadrži listu pravila koje omogućuju Netflixu da zna kada se nešto promijeni i kada netko treba to provjeriti. Primjerice, moguća je situacija u kojo developer napravi firewall pravilo koje omogućuje pristup sa sumnjive IP adrese ili pak napravi grešku u kontroli pristupa za spremišni resurs koji bi i nerigistriranome korisniku pružao uslugu. Tri su sastavna dijela Security Monkeya: Watcher, Notifier i Auditor. Watcher prati dani AWS račun i tehnologiju kojom se rade promjene u konfiguraciji. Druga komponenta, Notifier, daje do znanja timovima kada se nešto promijeni. Auditor pak procjenjuje razinu riziku povezanog s određenom konfiguracijom izvršavajući set poslovnih pravila kontra svake konfiguracije. [13]
Drugi automatizirani alat, Scumblr, može pretraživati stranice poput Pastebina za korisničkim imenima i lozinkama koje su možebitno procurile ili pretraživati kompromitirane Netflix račune koje kriminalci pokušavaju prodati na eBayu. Ukoliko se takav račun nađe, odmah se javlja korisniku koji zatim vraća kontrolu nad svojim računom. Scumblr radi s alatom zvanim Sketchy koji prikuplja snimke zaslona i testira sadržaj s potencijalno malicioniznih stranica. Na taj način on omogućuje timu da prikupi podatke, a da istovremeno izoliraju svoja računala od opasnosti koju posjet takvim stranicama donosi.
Netflix je također počeo automatizirati prijavu incidenata pomoću sistema zvanog Fully Integrated Defense Operation (FIDO). FIDO automatski analizira i sortira sigurnosne događaje ovisno o težini. U nekim slučajevima, može automatski izolirati probleme poput onemogućavanja zaposlenikovog računa koji je bio kompromitiran malicioznim softverom. Kada FIDO primi sigurnosno upozorenje od firewalla ili sistema za detekciju upada on pokušava sakupiti čim više informacija o tome što se događa. Provjerit će interne sisteme da vidi ukoliko netko cilja administratora ili pak PCI zonu – najsigurniji dio mreže gdje se obavljaju financijske transakcije. Također provjerava i prirodu napada te utvrđuje je li uzbuna lažna ili pak je u pitanju neka opasnija prijetnja. Ovisno o prikupljenim informacijama, on poduzima određene mjere, poput onesposobljavanja zaposlenikova računa ili pak slanja e-maila odgovarajućoj osobi koja će se dalje baviti problemom. Automatizacija je vrlo važna kako bi se označile potencijalne sigurnosne prijetnje koje bi developeri previditi. Kako bi još poboljšali sigurnost Netflix radi i križaljku među timovima te tako svaki tim provjerava posao kojeg je napravio onaj drugi. Tako su i sigurnosni te DevOps tim dosta povezani te prate tuđi rad s ciljem otklanjanja propusta, kako sigurnosnih tako i drugih, a s ciljem razvitka boljeg proizvoda. [14]
Još jedna kompanija, Walmart, slijedi sličan pristup. Oni su stvorili program nazvan "security mavens" kako bi podignuli svijest o sigurnosti unutar razvojnih timova. Kompanija je privukla radnike na ova mjesta nudeći im subvencije za polaganje tečaja sigurnosti. Sada preko 10 posto IT dijela kompanije čine "security maveni". To se pokazalo veoma isplativim te je tako proteklih godina zabilježen pad od 92 što se tiče sigurnosnih propusta. Sigurnost je područje gdje se donose mnoge kritične odluke, a uvjeti se mijenjaju veoma brzo te je radi toga potrebno donositi trenutne odluke, a tome automazicija donošenje odluka svakako pridonosi.
Zaključak
Iako je u počecima postojala određena doza skepse prema sigurnosti unutar DevOpsa, to se u zadnjih godinu dana mijenja. Nekoliko najvećih kompanija koristi DevOps prakse, a to su kompanije kojima je sigurnost na prvom mjestu. Već je to dovoljan pokazatelj kako je moguće implementirati sigurnost. Problem koji se najčešće javlja su kompanije koje u žurbi za bogaćenjem, zaboravljaju važnost sigurnosti. Danas na Webu postoji bezbroj prijetnji i ako nije sve napravljeno kako treba postoji velika vjerojatnost da će se ta prijetnja i realizirati. Tada se spoznaje prava vrijednost dobrog sigurnosnog posla jer šteta se često broji i u milijunima. DevOps suradnja godinama je bila nezamisliva, ali i to je napokon ostvareno i označava veliki napredak u IT zajednici. Kako se taj napredak nebi ugrozio potrebno je svakom timu pridodati i sigurnosnog stručnjaka jer iako vjerojatno u timu postoje ljudi koji se razumiju u sigurnost, to u današnje vrijeme ipak nije dovoljna garancija sigurnosti.
Literatura
1. Bravo H., DevOps and Security: It’s Happening. Right Now., dostupno na https://www.owasp.org/images/c/cd/Bravo.pptx
2. Arychuk S., SecDevOps: Injecting Security Into DevOps Processes, dostupno na https://blog.newrelic.com/2015/08/27/secdevops-rugged-devops/
3. Tabac Y., How Netflix Manages Security in the Age of DevOps, dostupno na https://dzone.com/articles/how-netflix-manages-security-in-the-age-of-devops
4. Brown J. D., Mythbusting: DevOps and Security, dostupno na http://www.wired.com/insights/2013/10/mythbusting-devops-and-security/
5. Bellanger J., Why DevOps Fails At Application Security, dostupno na http://www.darkreading.com/risk/why-devops-fails-at-application-security/a/d-id/1322625
6. Lane A, Building Security Into DevOps: Security Integration Points, dostupno na https://securosis.com/blog/building-security-into-devops-security-integration-points
