Upravljanje sigurnošću CI/CD cjevovoda za revizije u 2026.

Ponedjeljak je, 08:17, a CISO rastuće fintech tvrtke prima poruku kakve se svaki sigurnosni rukovoditelj pribojava:

„Produkcijska izrada izgleda čisto, ali sažetak artefakta ne odgovara commitu izvornog koda.”

U roku od nekoliko minuta razvojni tim potvrđuje da je izdanje prošlo jedinične testove, da postoji zapis implementacije i da usluga dostupna klijentima radi stabilno. No cjevovod pokazuje drukčiju priču. Samostalno ugošćeni CI runner ponovno je korišten na više projekata. Privremena vjerodajnica za oblak ostala je aktivna dulje nego što je planirano. Registar artefakata prikazuje potpisanu sliku kontejnera, ali ključ za potpisivanje bio je dostupan s istog runnera koji je izvršavao nepouzdane skripte izrade.

Voditelj izdanja može dokazati da je nešto implementirano. Ono što organizacija ne može dokazati, barem ne dovoljno brzo, jest što je izrađeno, tko je to odobrio, je li okruženje izrade bilo čisto i bi li dokazi izdržali reviziju ili istragu incidenta.

To više nije samo DevOps problem.

U 2026. upravljanje sigurnošću CI/CD cjevovoda nalazi se na sjecištu sigurnosti opskrbnog lanca softvera, operativne otpornosti, odgovornosti za privatnost, sigurnosti proizvoda i nadzora kibernetičkog rizika na razini odbora. NIS2 zahtijeva da upravljačka tijela odobravaju i nadziru mjere upravljanja kibernetičkim rizicima. DORA zahtijeva da financijski subjekti upravljaju IKT rizicima, incidentima, testiranjem i ovisnostima o trećim stranama. GDPR zahtijeva da voditelji obrade i izvršitelji obrade dokažu odgovarajuću sigurnost i odgovornost za osobne podatke. Cyber Resilience Act povećava tržišna očekivanja za sigurne proizvode s digitalnim elementima, sigurna ažuriranja i postupanje s ranjivostima. ISO/IEC 27001:2022 zahtijeva ISMS koji obradu rizika pretvara u kontrolirane operacije potkrijepljene dokazima.

Cjevovod je postao revizijski trag povjerenja u moderni softver.

Novo pitanje usklađenosti: možete li dokazati što je stiglo u produkciju?

Godinama su se DevSecOps programi usredotočivali na dodavanje skenera u cjevovode. Statička analiza, provjere ovisnosti, skeniranje tajnih vrijednosti, skeniranje kontejnera i provjera infrastrukture kao koda postali su uobičajeni. Te su kontrole i dalje važne, ali ne odgovaraju na upravljačko pitanje koje revizori, regulatori, klijenti i odbori sada postavljaju:

Može li organizacija dokazati da je svaka produkcijska implementacija proizašla iz odobrenog izvornog koda, da je izrađena u kontroliranom okruženju, da je proizvela provjerljiv artefakt, prošla obvezne sigurnosne kontrolne točke, koristila odobrene vjerodajnice, slijedila postupak upravljanja promjenama i generirala dokaze koji se mogu očuvati?

Napadači znaju da su sustavi izrade, paketne ovisnosti, tokeni razvojnih inženjera, CI runneri, automatizacija izdanja, registri artefakata i uloge za implementaciju u oblaku ciljevi visoke vrijednosti. Kompromitirani cjevovod može zaobići tradicionalne obrane jer koristi pouzdanu automatizaciju za unos zlonamjernog koda u pouzdana okruženja.

Zreo model upravljanja sigurnošću CI/CD cjevovoda zato treba šest stupova dokaza.

Tu se Clarysecov pristup razlikuje od usklađenosti po kontrolnoj listi. CI/CD platformu tretiramo kao upravljani poslovni proces, a ne samo kao tehnički alat. Taj proces mora biti obuhvaćen opsegom ISMS-a, procijenjen s aspekta rizika, kontroliran, nadziran, revidiran i poboljšavan.

Uključite CI/CD u ISO/IEC 27001:2022 ISMS

ISO/IEC 27001:2022 počinje kontekstom, zainteresiranim stranama i opsegom. Točke 4.1 do 4.4 zahtijevaju da organizacije razumiju interna i vanjska pitanja, utvrde zahtjeve zainteresiranih strana, identificiraju pravne, regulatorne i ugovorne zahtjeve te definiraju opseg ISMS-a uzimajući u obzir ovisnosti o drugim organizacijama.

Za pružatelja SaaS usluga, fintech, pružatelja upravljanih usluga, dobavljača softvera ili poslovanje izvorno građeno za oblak, CI/CD je gotovo uvijek unutar tog opsega jer izravno utječe na pružanje usluge, podatke klijenata, produkcijsku infrastrukturu i ugovorne obveze.

Točke 5.1 do 5.3 čine vodstvo odgovornim za ISMS. To je važno jer moderna automatizacija izdanja povezuje razvoj, sigurnost, operacije u oblaku, nabavu, usklađenost i upravljanje proizvodom. Ako nijedan izvršni rukovoditelj nije vlasnik apetita za rizik automatizacije produkcijske implementacije, organizacija obično završava s fragmentiranim alatima i nedosljednim dokazima.

Točke 6.1.1 do 6.1.3 pružaju temelj planiranja. Organizacija mora procijeniti rizike za povjerljivost, cjelovitost i dostupnost, identificirati vlasnike rizika, usporediti rizike s kriterijima, odabrati obrade, usporediti odabrane kontrole s Prilogom A, izraditi Izjavu o primjenjivosti te pribaviti odobrenje za plan obrade rizika i preostali rizik.

Procjena rizika CI/CD-a ne smije samo navesti „rizik opskrbnog lanca softvera”. Mora imenovati realistične scenarije:

• Zlonamjerna skripta izrade iznosi ključeve za potpisivanje iz dijeljenog runnera.
• Razvojni inženjer zaobilazi zaštitu grane i implementira nepregledani kod.
• Kompromitirana radnja treće strane mijenja artefakt tijekom izrade.
• Vjerodajnica pripremnog okruženja omogućuje pristup produkcijskom okruženju.
• Implementacija se provodi bez povezanog zahtjeva za promjenu.
• Zapisi cjevovoda potrebni za rekonstrukciju incidenta prepisuju se nakon sedam dana.
• Incident trovanja ovisnosti dopire do predprodukcije ili produkcije.

Točka 8.1 zatim zahtijeva planirano i kontrolirano izvođenje ISMS procesa, dokumentirane dokaze, kontrolu planiranih promjena, pregled nenamjernih promjena te kontrolu procesa, proizvoda ili usluga koje pružaju vanjske strane, a relevantni su za ISMS. Ako cjevovod mijenja produkciju, mora proizvesti dokaze kontroliranog izvođenja.

Clarysecov model kontrola za sigurnu isporuku softvera

Clarysec povezuje politike, kontrole i revizijske dokaze. Zenith Blueprint: Revizorov plan u 30 koraka Zenith Blueprint smješta sigurni DevOps i siguran razvoj u fazu upravljanja rizicima, korak 14. Navodi da organizacije trebaju osigurati CI/CD alate, osigurati da samo ovlašteno osoblje može pokretati implementacije, koristiti MFA za pristup cjevovodu, štititi cjelovitost artefakata izrade te zapisivati i nadzirati CI/CD radnje.

„Kontrole DevOps cjevovoda: CI/CD alati moraju biti osigurani – samo ovlašteno osoblje smije pokretati implementacije; koristite MFA za pristup cjevovodu; zaštitite cjelovitost artefakata izrade. Zapisujte i nadzirite CI/CD radnje.”

Te smjernice postaju provedive kada se prevedu u odredbe politika i zahtjeve za dokazima.

P24 Politika sigurnog razvoja Politika sigurnog razvoja navodi:

„Artefakti izrade moraju biti potpisani i sljedivi do commitova izvornog koda.”

To je jedna od najsnažnijih kontrola u programu upravljanja CI/CD-om. Razvojnom timu jasno nalaže da produkcijski artefakt mora imati provjerljivo podrijetlo u sustavu za upravljanje izvornim kodom. Revizorima također govori što testirati: odabrati produkcijsko izdanje, pregledati potpis artefakta, provjeriti referencu na commit, pregledati odobrenje pull requesta i potvrditi zapis izrade cjevovoda.

Ista politika navodi:

„Sve razvojne aktivnosti moraju se pratiti kroz odobrene sustave za upravljanje verzijama uz obvezne kontrole pristupa, revizijske tragove i zaštite grana.”

Time se upravljanje pomiče uzvodno. Ako repozitoriji izvornog koda nisu zaštićeni, sljedivost izrade je slaba. Ako se zaštite grana mogu zaobići, cjevovod može vjerno izraditi neodobreni kod. Ako su revizijski tragovi onemogućeni, rekonstrukcija incidenta ovisi o pamćenju i snimkama zaslona umjesto o dokazima.

Za manje organizacije, Politika sigurnog razvoja za SME Politika sigurnog razvoja za SME uključuje pragmatičan minimalni zahtjev:

„Praćenje verzije koda, datuma implementacije i odobravatelja”

Ta jednostavna evidencija implementacije snažan je početak. Mnogim SME organizacijama prvog dana nije potrebno složeno upravljanje izdanjima, ali moraju znati koja je verzija puštena u rad, kada i tko ju je odobrio.

SME politika također navodi:

„Pristup produkcijskim alatima ili sustavima za implementaciju mora biti kontroliran, zapisan u dnevnik i periodično pregledan od strane direktora ili pružatelja IT usluga.”

To je upravljački korak koji mnogi manji timovi propuštaju. CI/CD platforma s produkcijskim vjerodajnicama za oblak predstavlja put pristupa produkcijskom okruženju s povišenim ovlastima.

Tri područja kontrola ISO/IEC 27002:2022 iza sigurnog CI/CD-a

Zenith Controls: Vodič za međusobno usklađivanje Zenith Controls Clarysecov je kompas za mapiranje službenih standarda i okvira u praktične odnose kontrola. Za upravljanje sigurnošću CI/CD cjevovoda ključna su tri područja kontrola ISO/IEC 27002:2022.

Zenith Controls opisuje 5.21 kao preventivnu kontrolu koja podupire povjerljivost, cjelovitost i dostupnost, pri čemu je sigurnost odnosa s dobavljačima ključna operativna sposobnost. To odgovara CI/CD-u jer moderni cjevovodi ovise o vanjskim uslugama: platformama za upravljanje izvornim kodom, ugošćenim runnerima, registrima kontejnera, repozitorijima paketa otvorenog koda, GitHub Actions radnjama trećih strana, alatima za skeniranje, API-jima za implementaciju u oblaku i vanjskim razvojnim inženjerima.

U mapiranju 5.21, Zenith Controls povezuje sigurnost IKT opskrbnog lanca s 5.19 Informacijska sigurnost u odnosima s dobavljačima, 5.20 Uređivanje informacijske sigurnosti u ugovorima s dobavljačima, 8.27 Načela sigurne arhitekture sustava i inženjeringa, 8.28 Sigurno kodiranje, 8.29 Sigurnosno testiranje u razvoju i prihvatu, 5.15 Kontrola pristupa, 5.28 Prikupljanje dokaza, 8.25 Sigurni životni ciklus razvoja softvera i 8.30 Vanjski ugovoreni razvoj.

Za 8.25, Zenith Controls identificira sigurni životni ciklus razvoja softvera kao preventivnu kontrolu koja štiti povjerljivost, cjelovitost i dostupnost. Povezuje sigurnosne zahtjeve, arhitekturu, kodiranje, testiranje, vanjski ugovoreni razvoj i 8.31 Razdvajanje razvojnih, testnih i produkcijskih okruženja.

Za 8.32, Zenith Controls postavlja upravljanje promjenama kao most između razvoja i operacija. Povezuje ga s 8.9 Upravljanje konfiguracijom, 8.8 Upravljanje tehničkim ranjivostima, sigurnim SDLC-om i odgovorom na incidente. Zbog toga automatizacija implementacije ne može biti izvan upravljanja promjenama. Ona je mehanizam kojim nastaju produkcijske promjene.

Sljedivost izrade: priča izdanja koju revizori mogu pratiti

Sljedivost izrade sposobnost je da se dokazima odgovori odakle je softverski artefakt došao i kako je proizveden. Snažan zapis o sljedivosti opisuje priču izdanja:

1. Koji su repozitorij izvornog koda i commit korišteni.
2. Koja je grana ili oznaka pokrenula izradu.
3. Koji su pull request, pregledavatelj i odobrenje povezani.
4. Koja se definicija cjevovoda izvršila.
5. Koji je runner izvršio posao.
6. Koje su ovisnosti i osnovne slike korištene.
7. Koji su testovi i sigurnosne kontrolne točke izvršeni.
8. Koji je artefakt proizveden.
9. Koji je potpis ili sažetak generiran.
10. Koja je implementacija upotrijebila artefakt.

P05 Politika upravljanja promjenama Politika upravljanja promjenama pruža upravljačku poveznicu. Navodi:

„Promjene provedene alatima i dalje moraju biti u skladu s ovom politikom i biti sljedive do odgovarajućeg ID-a zahtjeva za promjenu.”

Time se adresira čest argument da automatizirane implementacije ne trebaju prijave promjena. Automatizacija ne uklanja upravljanje promjenama. Ona mijenja način na koji se dokazi generiraju.

Ista politika navodi:

„Svi zahtjevi za promjene, pregledi, odobrenja i pripadajući dokazi moraju se evidentirati u centraliziranom sustavu za upravljanje promjenama.”

U praksi sustav za upravljanje promjenama treba biti indeks, a ne odlagalište. Prijava treba upućivati na repozitorij izvornog koda, pokretanje izrade, potpis artefakta, zapis implementacije i plan povrata. Detaljni dokazi mogu ostati u inženjerskim alatima ako su definirani zadržavanje, kontrola pristupa i mogućnost izvoza.

Očvršćivanje runnera: zanemarena produkcijska kontrola

CI/CD runneri često se tretiraju kao potrošna infrastruktura, ali oni su izvršna okruženja visokog rizika. Runner može pristupati izvornom kodu, tajnim vrijednostima, predmemorijama izrade, repozitorijima paketa, ključevima za potpisivanje, registrima artefakata i ulogama za implementaciju u oblaku. Ako je trajan, dijeljen, prekomjerno ovlašten ili slabo nadziran, postaje povlaštena točka lateralnog kretanja.

Sigurno upravljačko stajalište jednostavno je: runneri koji izrađuju ili implementiraju produkcijski kod moraju biti očvrsnuti kao produkcijska infrastruktura.

Politika testnih podataka i testnih okruženja Politika testnih podataka i testnih okruženja navodi:

„Integracija s CI/CD cjevovodima mora provoditi razdvajanje okruženja i autentifikacijskih vjerodajnica.”

Runner koji može implementirati u pripremno i produkcijsko okruženje istim modelom vjerodajnica narušava načelo razdvajanja okruženja, čak i ako je infrastruktura logički odvojena. Clarysec u pravilu preporučuje zasebne identitete za implementaciju po okruženju, zasebne kontrolne točke odobrenja za produkciju i izričite kontrole koje sprječavaju poslove nižih okruženja da pristupe produkcijskim tajnim vrijednostima.

Zenith Blueprint, faza Kontrole u praksi, korak 21, to dodatno naglašava kroz razdvajanje razvojnih, testnih i produkcijskih okruženja:

„Ako se koristi CI/CD, potvrdite da je promocija implementacije između okruženja kontrolirana i da zahtijeva pregled ili odobrenje. Dokumentirajte to u svojem Postupku upravljanja okruženjima i priložite snimke zaslona ili izvoze iz konzole kao potporu.”

Za stvarnu reviziju to znači da revizor ne bi smio vidjeti samo dijagram. Trebao bi vidjeti izvoze iz konzole koji prikazuju vjerodajnice specifične za okruženje, zaštićena implementacijska okruženja, kontrolne točke odobrenja i zapise koji dokazuju da je promocija bila kontrolirana.

Dokazi o implementaciji: artefakt usklađenosti koji je svima pred očima

Najzreliji DevSecOps timovi ne tretiraju prikupljanje dokaza kao tromjesečnu utrku. Oni projektiraju cjevovode tako da automatski generiraju dokaze.

Politika zapisivanja događaja i praćenja za SME Politika zapisivanja događaja i praćenja za SME identificira relevantne događaje dnevnika kao:

„Sistemski zapisi dnevnika: promjene konfiguracije, administrativne radnje, instalacije softvera, aktivnosti zakrpavanja”

CI/CD sustavi proizvode sve četiri kategorije. Promjene konfiguracije cjevovoda utječu na način izrade softvera. Administrativne radnje mijenjaju tko može odobravati ili implementirati. Instalacije softvera događaju se u slikama izrade i ciljevima implementacije. Aktivnosti zakrpavanja mogu teći kroz automatizirane procese izdanja. Ti se događaji moraju zapisivati, zadržavati i pregledavati prema riziku.

Za spremnost na istragu, P31S Politika prikupljanja dokaza i forenzike za SME Politika prikupljanja dokaza i forenzike za SME navodi:

„Snimke zaslona, izvezeni zapisi dnevnika i sažeci datoteka moraju se pohraniti zajedno s datotekom lanca čuvanja dokaza.”

To je osobito važno nakon sumnje na kompromitaciju cjevovoda. Same snimke zaslona slab su dokaz. Zapisi dnevnika bez sažetaka mogu biti osporeni. Datoteka lanca čuvanja dokaza bez referenci na izvor nije potpuna.

Dokazni zapis produkcijske implementacije trebao bi uključivati sljedeće.

Ovaj paket pretvara CI/CD iz niza tehničkih koraka u priču o upravljanju, kontroli i dubinskoj analizi dobavljača.

Mapiranje upravljanja CI/CD-om na NIS2, DORA, GDPR i CRA

NIS2 se primjenjuje na mnoge ključne i važne subjekte, uključujući digitalnu infrastrukturu, upravljanje IKT uslugama i organizacije digitalnih pružatelja kada su ispunjeni kriteriji. Article 20 osobito je relevantan jer uspostavlja dužnosti kibernetičke sigurnosti na razini uprave. Upravljačka tijela moraju odobriti mjere upravljanja kibernetičkim rizicima, nadzirati provedbu i proći obuku.

Article 21 pruža polaznu osnovu upravljanja rizicima. Zahtijeva odgovarajuće i razmjerne tehničke, operativne i organizacijske mjere koje obuhvaćaju analizu rizika, politike, postupanje s incidentima, neprekidnost poslovanja, sigurnost opskrbnog lanca, sigurnu nabavu, razvoj i održavanje, postupanje s ranjivostima, procjenu učinkovitosti, kibernetičku higijenu, kriptografiju, sigurnost ljudskih resursa, kontrolu pristupa, upravljanje imovinom i MFA gdje je primjenjivo.

Article 23 dodaje fazno prijavljivanje značajnih incidenata, uključujući rano upozorenje u roku od 24 sata od saznanja, obavijest o incidentu u roku od 72 sata i završno izvješće najkasnije mjesec dana nakon obavijesti o incidentu. Ako bi kompromitacija CI/CD-a mogla uzrokovati ozbiljan operativni poremećaj, financijski gubitak ili materijalnu štetu drugima, proces klasifikacije incidenta mora biti spreman prije incidenta.

Za financijske subjekte DORA se primjenjuje od 17. siječnja 2025. i obuhvaća upravljanje IKT rizicima, prijavljivanje incidenata, testiranje otpornosti, razmjenu informacija, upravljanje IKT rizicima trećih strana i ugovorne zahtjeve. Article 5 zahtijeva interni okvir upravljanja i kontrola za IKT rizik, uz odgovornost upravljačkog tijela. Article 6 zahtijeva dokumentirani okvir upravljanja IKT rizicima integriran u cjelokupno upravljanje rizicima.

Articles 8 to 14 izravno se mapiraju na upravljanje CI/CD cjevovodima. Financijski subjekti moraju identificirati i klasificirati poslovne funkcije podržane IKT-om, imovinu, ovisnosti, prijetnje i ranjivosti. Moraju štititi IKT sustave putem politika, kontrola pristupa, snažne autentifikacije, zaštite kriptografskih ključeva, kontroliranog upravljanja IKT promjenama, zakrpavanja i segmentacije. Moraju otkrivati anomalije, odgovarati, oporavljati se i učiti iz incidenata.

Articles 28 to 30 jednako su važni jer CI/CD platforme, pružatelji upravljanja izvornim kodom, registri artefakata, sustavi izrade u oblaku i vanjski razvojni inženjeri mogu biti IKT ovisnosti trećih strana. DORA očekuje dubinsku analizu dobavljača, ugovorne zaštitne mjere, procjenu rizika koncentracije, prava na reviziju i inspekciju, okidače za raskid, izlazne strategije i odredbe o razini usluge.

GDPR dodaje perspektivu odgovornosti. Article 5 zahtijeva da se osobni podaci obrađuju zakonito, pošteno, transparentno, u određene svrhe, minimizirano, točno, zadržavaju samo koliko je potrebno i štite od neovlaštene ili nezakonite obrade te slučajnog gubitka, uništenja ili oštećenja. Article 5(2) zahtijeva od voditelja obrade da dokaže usklađenost.

CI/CD cjevovodi važni su za GDPR jer razvojni inženjeri mogu koristiti produkcijske podatke u testnim okruženjima, zapisi cjevovoda mogu izložiti osobne podatke ili tokene, izdanja mogu promijeniti logiku obrade, a kompromitirani artefakti mogu uzrokovati povrede osobnih podataka. Kada softverske promjene utječu na kontrole privatnosti, zapis promjene treba zabilježiti utjecaj na privatnost. Kada incident u cjevovodu uzrokuje neovlašten pristup osobnim podacima, procjena povrede mora biti povezana s postupanjem s incidentom.

Očekivanja CRA dodaju sigurnost proizvoda i dokaze sigurnog ažuriranja. Za proizvođače i pružatelje softvera koji na tržište EU stavljaju proizvode s digitalnim elementima klijenti sve više očekuju sigurnosne datoteke proizvoda, dokaze o postupanju s ranjivostima, kontrole sigurnog ažuriranja i cjelovitost izdanja. Upravljanje CI/CD-om pruža velik dio tih dokaza kroz sljedivost izvornog koda, potpisane artefakte, rezultate skeniranja ranjivosti, napomene o izdanju, sigurnosne ispravke i zapise distribucije ažuriranja.

NIST CSF 2.0 i COBIT 2019: revizijska perspektiva izvan ISO-a

NIST CSF 2.0 pruža integracijski sloj za upravljanje kibernetičkom sigurnošću. Njegova jezgra, organizacijski profili i razine pomažu organizacijama razumjeti trenutačni i ciljani sigurnosni profil, prioritizirati aktivnosti usklađene s pravnim i regulatornim zahtjevima te komunicirati kibernetički rizik.

Za CI/CD, Clarysec često izrađuje profil cjevovoda za isporuku softvera. Trenutačni profil opisuje kako danas funkcioniraju upravljanje izvornim kodom, runneri, potpisivanje artefakata i odobrenja implementacije. Ciljani profil definira potrebno stanje za regulirane operacije. Plan uklanjanja praznina postaje plan implementacije.

Funkcija NIST GOVERN osobito je relevantna. GV.OC-03 zahtijeva da se pravni, regulatorni i ugovorni zahtjevi kibernetičke sigurnosti razumiju i upravljaju. GV.RM obuhvaća apetit za rizik i standardiziranu prioritizaciju rizika. GV.RR dodjeljuje odgovornost vodstva, uloge i resurse. GV.PO zahtijeva uspostavu, provedbu, pregled i ažuriranje politika kibernetičkog rizika. GV.OV obuhvaća nadzor i vrednovanje učinkovitosti.

Revizor koji se oslanja na COBIT 2019 ili ISACA pristup često će manje gledati kriptografske detalje potpisivanja artefakata, a više dizajn upravljanja. Pitat će je li vlasništvo definirano, je li omogućavanje promjena kontrolirano, upravlja li se rizicima usluga trećih strana, proizvodi li nadzor osiguranje, jesu li iznimke odobrene i prima li uprava smisleno izvješćivanje.

Česti nalazi revizije CI/CD-a i metrike za odbor

Većina nalaza revizije CI/CD-a predvidljiva je. Prvi je nepovezanost dokaza. Tim ima Git zapise, zapise cjevovoda i zapise implementacije, ali nijedan jedinstveni zapis promjene ih ne povezuje. Drugi je prekomjerno ovlaštena automatizacija, pri čemu jedan posao može čitati produkcijske tajne vrijednosti, slati artefakte, odobravati implementacije i mijenjati definicije cjevovoda. Treći su trajni dijeljeni runneri, koji stvaraju rizik kontaminacije između projekata i otežavaju forenzičko određivanje opsega nakon kompromitacije.

Drugi česti nedostaci uključuju nepotpisane ili prepisane artefakte, neformalne iznimke od skeniranja, nedovoljnu vidljivost dobavljača i curenje privatnih podataka u zapisima dnevnika. Dobar cjevovod dopušta iznimke, ali zahtijeva odobrenje, istek, vlasništvo nad rizikom i pregled.

Sigurnosni rukovoditelji trebali bi izbjegavati izvješćivanje odboru samo o broju skeniranja. Umjesto toga, trebaju izvješćivati o metrikama povjerenja u izdanja:

• Postotak produkcijskih implementacija povezanih s odobrenim zapisima promjena.
• Postotak produkcijskih artefakata koji su potpisani i sljedivi do commitova izvornog koda.
• Broj implementacija koje koriste iznimke ili hitna odobrenja.
• Postotak privilegiranih CI/CD korisnika s MFA i nedavnim pregledom pristupa.
• Broj aktivnih dugotrajnih vjerodajnica za implementaciju.
• Postotak kritičnih usluga koje koriste očvrsnute ili efemerne runnere.
• Prosječno vrijeme do opoziva ili periodične promjene tajnih vrijednosti cjevovoda nakon incidenta.
• Broj kritičnih dobavljačkih ovisnosti koje podupiru isporuku softvera.
• Stopa potpunosti dokaza za revizijski uzorkovana izdanja.

Te metrike podupiru vodstvo, planiranje i operativnu kontrolu prema ISO/IEC 27001:2022. Također podupiru nadzor uprave prema NIS2 Article 20 i očekivanja DORA u pogledu upravljanja.

Učinite svoj cjevovod revizijski provjerljivim prije incidenta

Upravljanje sigurnošću CI/CD cjevovoda u 2026. nije usporavanje razvoja. Riječ je o tome da isporuka softvera bude pouzdana, otporna i dokaziva. Najbolji programi koriste automatizaciju za ubrzavanje dokaza, a ne za zaobilaženje upravljanja.

Praktična Clarysec implementacija počinje s tri aktivnosti.

1. Upotrijebite Zenith Blueprint Zenith Blueprint kako biste sigurni DevOps, pristup izvornom kodu, razdvajanje okruženja i upravljanje promjenama ugradili u svoj plan implementacije ISO/IEC 27001:2022.
2. Upotrijebite Zenith Controls Zenith Controls za mapiranje CI/CD rizika kroz sigurni SDLC, IKT opskrbni lanac, kontrolu pristupa, upravljanje promjenama, prikupljanje dokaza, NIS2, DORA, GDPR, NIST CSF 2.0 i revizijske perspektive COBIT 2019.
3. Uvedite Clarysec predloške politika, uključujući Politiku sigurnog razvoja, Politiku upravljanja promjenama, Politiku testnih podataka i testnih okruženja, Politiku sigurnog razvoja za SME, Politiku zapisivanja događaja i praćenja za SME i Politiku prikupljanja dokaza i forenzike za SME, kako biste definirali tko odobrava izdanja, kako se artefakti prate, kako se runneri kontroliraju i koje dokaze treba zadržati.

Ako vaš sljedeći revizijski uzorak počne zahtjevom „pokažite nam trag produkcijskog izdanja”, vaš tim trebao bi moći odgovoriti u minutama, a ne tjednima. To je razlika između DevOps automatizacije i upravljane isporuke softvera.

Preuzmite Clarysec paket politika, pregledajte svoj CI/CD cjevovod prema Zenith Blueprint i Zenith Controls ili rezervirajte Clarysec procjenu kako biste svoj cjevovod pretvorili iz izvora revizijske tjeskobe u temelj digitalne otpornosti.