DevSecOps: sigurnost ugrađena u razvoj

DevSecOps je pristup koji ugrađuje sigurnost u svaki korak razvoja softvera, od dizajna do isporuke, umjesto da je tretira kao zasebnu provjeru pred lansiranje. Naziv spaja razvoj (development), sigurnost (security) i operacije (operations). Ideja se zove pomicanje ulijevo (shift-left): sigurnosne provjere pomiču se na početak razvojnog tijeka, prema programeru koji piše kod, a ne na sam kraj prema timu koji izdaje proizvod. Razlog je financijski i praktičan. Propust koji se nađe dok programer još radi na funkciji ispravi se u minutama. Isti propust koji prođe sve do produkcije zahtijeva istragu, hitnu zakrpu, novu isporuku i ponekad obavijest regulatoru.¹

Za reguliranu hrvatsku tvrtku, primjerice financijsku instituciju pod DORA-om ili obveznika prema Zakonu o kibernetičkoj sigurnosti kojim je u Hrvatskoj prenesena direktiva NIS2, ovo nije samo pitanje inženjerske higijene. Sigurnost softvera koji tvrtka razvija ili naručuje dio je upravljanja rizikom IKT sustava, a regulator očekuje da je taj proces dokumentiran i ponovljiv. DevSecOps daje upravo to: dokaziv proces u kojem se sigurnost provjerava sustavno, a ne ovisno o tome je li se netko sjetio pozvati pentestere prije roka. Ovaj tekst objašnjava što DevSecOps obuhvaća, koje alate i prakse koristi i kako ga uvesti bez usporavanja razvoja.

Ovo je dio našeg pregleda sigurnosti aplikacija. Pomažemo timovima ugraditi sigurnost u razvoj kroz sigurnost aplikacija i clouda.

Zašto sigurnost mora ući u razvoj, a ne na kraj

Tradicionalni model tretira sigurnost kao kontrolnu točku pred izlazak proizvoda. Razvojni tim mjesecima gradi aplikaciju, a tek na kraju ona ide na sigurnosnu provjeru. Problem je što su do tog trenutka propusti već ugrađeni u arhitekturu. Loš model ovlasti, pogrešno povjerenje prema vanjskom ulazu ili tajna zapisana u kodu nisu sitne pogreške koje se ispravljaju u jednoj liniji. One su odluke oko kojih je izgrađen ostatak sustava, pa njihov ispravak znači preraditi dijelove koji već rade.

Pomicanje ulijevo rješava to tako da sigurnost postane stalna, a ne jednokratna. Kad se prijetnje razmatraju u dizajnu, a automatske provjere pokreću pri svakoj promjeni koda, propusti se otkrivaju dok su mali i izolirani. Najjeftiniji trenutak za ispravak ranjivosti je onaj kad je programer još uvijek u kontekstu posla koji je upravo radio. Što kasnije propust izađe na vidjelo, to više ljudi i koraka uključuje njegov popravak.¹ To je suština ekonomske logike DevSecOpsa: ne radi se o više sigurnosti zbog sigurnosti, nego o jeftinijem i bržem razvoju sigurnog proizvoda.

Najjeftiniji trenutak za popravak ranjivosti je onaj dok je programer još u kodu koji ju je stvorio.

Što DevSecOps obuhvaća

DevSecOps nije jedan alat ni jedan proizvod. To je spoj praksi koje pokrivaju cijeli životni ciklus razvoja softvera. NIST taj ciklus opisuje kroz okvir za siguran razvoj softvera, SSDF, koji definira što organizacija treba raditi u svakoj fazi, od pripreme okruženja do zaštite isporučenog koda.¹ U praksi DevSecOps obuhvaća nekoliko glavnih skupina aktivnosti.

• Modeliranje prijetnji u fazi dizajna, prije nego se napiše prva linija koda, da se rizici uhvate na razini arhitekture.
• Automatske sigurnosne provjere ugrađene u cjevovod isporuke (CI/CD), koje se pokreću pri svakoj promjeni koda.
• Provjera vanjskih komponenti i knjižnica na poznate ranjivosti, jer većina modernog koda dolazi iz otvorenih izvora.
• Sigurna konfiguracija okruženja i infrastrukture, uključujući skeniranje infrastrukture opisane kodom (IaC).
• Upravljanje tajnama, dakle uklanjanje ključeva, lozinki i pristupnih žetona iz koda i njihovo čuvanje u zaštićenom trezoru.
• Kultura u kojoj su razvoj, sigurnost i operacije zajednički odgovorni za ishod, a ne tri tima koji jedan drugome predaju problem.

Alati i prakse u cjevovodu

Srce DevSecOpsa je niz automatskih provjera koje se pokreću u cjevovodu isporuke. Svaka pokriva drugačiju vrstu rizika i nijedna sama nije dovoljna. OWASP-ov vodič za DevSecOps opisuje kako ih posložiti tako da se nadopunjuju, a ne dupliciraju.² Sljedeća tablica daje pregled glavnih kategorija i onoga što hvataju.

Logičan redoslijed je da SAST i SCA rade rano, na razini koda i ovisnosti, jer su brzi i hvataju većinu poznatih problema jeftino. DAST dolazi kasnije, kad postoji pokrenuta verzija aplikacije u testnom okruženju. Skeniranje infrastrukture i provjera tajni pripadaju svakom prolazu cjevovoda, jer pogrešna konfiguracija ili procurjela tajna jednako su opasne bez obzira na fazu. Potpisivanje artefakata zatvara lanac: osigurava da je u produkciju otišlo upravo ono što je prošlo sve provjere, a ne podmetnuta verzija.

Sigurnost samog cjevovoda

Postoji rizik koji timovi često previde: sam cjevovod isporuke je meta. CI/CD sustav ima pristup izvornom kodu, tajnama, registrima artefakata i ovlasti za isporuku u produkciju. Napadač koji kompromitira cjevovod ne treba probiti aplikaciju, jer može podmetnuti zlonamjeran kod u proces izgradnje i taj kod će legitimno proći sve do korisnika. To je obrazac napada na opskrbni lanac softvera, a posljednjih godina je među najozbiljnijima.

Zaštita cjevovoda znači tretirati ga kao produkcijski sustav, ne kao pomoćni alat. Pristup se ograničava prema načelu najmanjih ovlasti, tajne se drže u trezoru i rotiraju, a ovisnosti o vanjskim radnjama i dodacima provjeravaju se prije korištenja. Potpisivanje artefakata i evidencija o tome što je ušlo u svaku izgradnju daju mogućnost da se nakon incidenta utvrdi gdje je lanac prekinut. Sigurnost cjevovoda usko je vezana uz sigurnost u oblaku, jer većina cjevovoda danas radi na cloud infrastrukturi.

Kako uvesti DevSecOps korak po korak

DevSecOps se uvodi postupno, bez zaustavljanja razvoja. Pokušaj da se sve uvede odjednom obično završi zatrpavanjem tima upozorenjima i odbacivanjem cijelog pristupa. Bolji put je krenuti od najvećih rizika i širiti se.

1. 01
   Krenite od dizajna

   Uvedite modeliranje prijetnji na početku svakog većeg posla, da se rizici uhvate prije nego postanu kod.
2. 02
   Uklonite tajne iz koda

   Maknite ključeve i lozinke iz repozitorija u trezor i uvedite automatsku provjeru koja sprječava nove.
3. 03
   Dodajte SCA i SAST

   Počnite s analizom ovisnosti i statičkom analizom koda, jer su brze i hvataju većinu poznatih problema.
4. 04
   Uvedite DAST i IaC skeniranje

   Dodajte dinamičko testiranje pokrenute aplikacije i skeniranje infrastrukture opisane kodom.
5. 05
   Zaštitite cjevovod

   Ograničite ovlasti CI/CD sustava, zaštitite tajne i uvedite potpisivanje artefakata.
6. 06
   Mjerite i učite

   Pratite koje se vrste propusta ponavljaju i uklonite njihov uzrok, ne samo pojedinačne nalaze.

Kultura i suradnja

Najteži dio DevSecOpsa nije tehnologija nego kultura. Tri tima, razvoj, sigurnost i operacije, povijesno imaju različite ciljeve. Razvoj želi brzo isporučiti, sigurnost želi spriječiti rizik, operacije žele stabilnost. U klasičnom modelu sigurnost je vrata koja usporavaju, pa je razvoj doživljava kao prepreku, a ne kao saveznika. DevSecOps mijenja taj odnos tako da sigurnost postaje zajednički cilj ugrađen u alate koje tim ionako koristi.

U praksi to znači da sigurnosni tim ne dolazi na kraju s popisom problema, nego daje programerima provjere koje se pokreću automatski i daju povratnu informaciju odmah, dok je programer još u kontekstu. Sigurnost postaje dio definicije gotovog posla, jednako kao testovi. Kad tim sam vidi i ispravlja propuste, vlasništvo nad sigurnošću prelazi na one koji pišu kod, a sigurnosni tim se bavi težim problemima i postavljanjem pravila. To je promjena u načinu rada, ne samo u alatima.

Gdje ručno testiranje i dalje treba

DevSecOps ne zamjenjuje penetracijsko testiranje. Automatske provjere u cjevovodu odlične su u hvatanju poznatih obrazaca: ranjivih ovisnosti, tipičnih grešaka u kodu, nesigurnih postavki. Ono što one ne vide su propusti u poslovnoj logici i kontroli pristupa, gdje svaki korak izgleda ispravno, ali njihova kombinacija dopušta zlouporabu. Korisnik koji izmjenom identifikatora dođe do tuđih podataka, ili tijek plaćanja koji se može preskočiti, za alat izgledaju kao normalan promet.

Zato se pristupi nadopunjuju. Automatika radi stalno, jeftino i hvata poznato. Periodični penetracijski test web aplikacije radi povremeno, skuplje, i hvata složeno. Po našem iskustvu, timovi s dobrim DevSecOpsom dobivaju veću vrijednost od pentesta, jer pentesteri ne troše vrijeme na trivijalne nalaze koje je automatika već uhvatila, nego se bave logikom. Stvarna procjena opsega ovisi o aplikaciji.

Veza s OWASP-om i sigurnim razvojem

DevSecOps se oslanja na poznate izvore sigurnih praksi. OWASP Top 10 popisuje najčešće kategorije ranjivosti web aplikacija i dobra je osnova za to što automatske provjere trebaju hvatati. Šire teme pokriva pregled sigurnosti web aplikacija, a posebnosti programskih sučelja sigurnost API-ja. OWASP-ov vodič za DevSecOps daje konkretne preporuke kako posložiti provjere u cjevovodu.²

Na regulatornoj strani, NIST-ov SSDF daje okvir koji se uklapa u zahtjeve upravljanja rizikom IKT sustava prema DORA-i i Zakonu o kibernetičkoj sigurnosti.¹ Ako tvrtka razvija ili naručuje softver, dokaziv proces sigurnog razvoja postaje dio očekivanja regulatora i dobavljača, ne samo interna dobra praksa.

Kako Raptoric pomaže

Pomažemo razvojnim timovima ugraditi sigurnost u proces, od dizajna i modeliranja prijetnji do provjera u cjevovodu i zaštite samog CI/CD sustava, te to povezati s ručnim testiranjem, kroz sigurnost aplikacija i clouda. Dogovorite uvodni razgovor.