CI/CD konvejerių saugumo valdysena 2026 m. auditams

Pirmadienio rytą, 08:17, sparčiai augančios finansinių technologijų bendrovės CISO gauna žinutę, kurios baiminasi kiekvienas saugumo vadovas:

„Produkcijos surinkimas atrodo tvarkingas, tačiau artefakto maišos reikšmė neatitinka pirminio kodo pakeitimo įrašo.“

Per kelias minutes inžinerijos komanda patvirtina, kad išleidimas praėjo vienetinius testus, diegimo užklausa yra, o klientams teikiama paslauga veikia stabiliai. Tačiau konvejeris rodo kitokią istoriją. Savarankiškai talpinama CI vykdyklė buvo pakartotinai naudojama keliuose projektuose. Laikinieji debesijos prieigos duomenys išliko aktyvūs ilgiau, nei buvo numatyta. Artefaktų registras rodo pasirašytą konteinerio atvaizdą, tačiau pasirašymo raktas buvo pasiekiamas iš tos pačios vykdyklės, kuri vykdė nepatikimus surinkimo scenarijus.

Išleidimo vadovas gali įrodyti, kad kažkas buvo įdiegta. Tačiau organizacija negali, bent jau pakankamai greitai, įrodyti, kas buvo surinkta, kas tai patvirtino, ar surinkimo aplinka buvo švari ir ar įrodymai išliktų tinkami auditui arba incidento tyrimui.

Tai nebėra vien DevOps problema.

2026 m. CI/CD konvejerių saugumo valdysena yra programinės įrangos tiekimo grandinės saugumo, veiklos atsparumo, privatumo atskaitomybės, produkto saugumo ir valdybos lygmens kibernetinės rizikos priežiūros sankirtoje. NIS2 įpareigoja valdymo organus tvirtinti ir prižiūrėti kibernetinio saugumo rizikos valdymo priemones. DORA reikalauja, kad finansų sektoriaus subjektai valdytų IRT riziką, incidentus, testavimą ir priklausomybes nuo trečiųjų šalių. GDPR reikalauja, kad duomenų valdytojai ir tvarkytojai galėtų pagrįsti tinkamą asmens duomenų saugumą ir atskaitomybę. Kibernetinio atsparumo aktas (CRA) didina rinkos lūkesčius dėl saugių produktų su skaitmeniniais elementais, saugių atnaujinimų ir pažeidžiamumų valdymo. ISO/IEC 27001:2022 reikalauja ISVS, kuri rizikos tvarkymą paverčia kontroliuojama, įrodymais pagrįsta veikla.

Konvejeris tapo šiuolaikinio pasitikėjimo programine įranga audito pėdsaku.

Naujas atitikties klausimas: ar galite įrodyti, kas pasiekė produkcinę aplinką?

Daugelį metų DevSecOps programos daugiausia dėmesio skyrė skenavimo priemonių įtraukimui į konvejerius. Statinė analizė, priklausomybių patikros, paslapčių skenavimas, konteinerių skenavimas ir infrastruktūros kaip kodo validavimas tapo įprasti. Šios kontrolės priemonės tebėra svarbios, tačiau jos neatsako į valdysenos klausimą, kurį dabar kelia auditoriai, reguliuotojai, klientai ir valdybos:

Ar organizacija gali įrodyti, kad kiekvienas produkcinės aplinkos diegimas buvo atliktas iš patvirtinto pirminio kodo, surinktas kontroliuojamoje aplinkoje, sukūrė patikrinamą artefaktą, perėjo privalomus saugumo vartus, naudojo patvirtintus prieigos duomenis, atitiko pakeitimų valdymo reikalavimus ir sugeneravo įrodymus, kuriuos galima išsaugoti?

Užpuolikai žino, kad surinkimo sistemos, paketų priklausomybės, kūrėjų prieigos raktai, CI vykdyklės, išleidimų automatizavimas, artefaktų registrai ir debesijos diegimo vaidmenys yra didelės vertės taikiniai. Kompromituotas konvejeris gali apeiti tradicines apsaugos priemones, nes pasitelkia patikimą automatizavimą piktavališkam kodui perkelti į patikimas aplinkas.

Todėl brandžiam CI/CD konvejerių saugumo valdysenos modeliui reikia šešių įrodymų ramsčių.

Čia Clarysec požiūris skiriasi nuo kontrolinio sąrašo atitikties. CI/CD platformą traktuojame kaip valdomą verslo procesą, o ne tik kaip techninę priemonę. Šis procesas turi būti įtrauktas į ISVS taikymo sritį, įvertintas rizikos požiūriu, kontroliuojamas, stebimas, audituojamas ir tobulinamas.

Įtraukite CI/CD į ISO/IEC 27001:2022 ISVS

ISO/IEC 27001:2022 prasideda nuo konteksto, suinteresuotųjų šalių ir taikymo srities. 4.1–4.4 punktai reikalauja, kad organizacijos suprastų vidinius ir išorinius klausimus, nustatytų suinteresuotųjų šalių reikalavimus, identifikuotų teisinius, reglamentavimo ir sutartinius reikalavimus bei apibrėžtų ISVS taikymo sritį, atsižvelgdamos į priklausomybes nuo kitų organizacijų.

SaaS teikėjui, finansinių technologijų įmonei, valdomų paslaugų teikėjui, programinės įrangos tiekėjui ar debesijoje veikiančiam verslui CI/CD beveik visada patenka į šią taikymo sritį, nes tiesiogiai veikia paslaugos teikimą, klientų duomenis, produkcinę infrastruktūrą ir sutartinius įsipareigojimus.

5.1–5.3 punktai nustato vadovybės atsakomybę už ISVS. Tai svarbu, nes šiuolaikinis išleidimų automatizavimas yra tarp inžinerijos, saugumo, debesijos operacijų, pirkimų, atitikties ir produktų valdymo. Jei joks vadovas neprisiima atsakomybės už produkcinės aplinkos diegimo automatizavimo rizikos apetitą, organizacija paprastai lieka su fragmentuotomis priemonėmis ir nenuosekliais įrodymais.

6.1.1–6.1.3 punktai sudaro planavimo pagrindą. Organizacija turi įvertinti konfidencialumo, vientisumo ir prieinamumo rizikas, identifikuoti rizikos savininkus, palyginti rizikas su kriterijais, parinkti rizikos tvarkymo priemones, palyginti pasirinktas kontrolės priemones su A priedu, parengti Taikomumo pareiškimą ir gauti rizikos tvarkymo plano bei liekamosios rizikos patvirtinimą.

CI/CD rizikos vertinimas neturi apsiriboti formuluote „programinės įrangos tiekimo grandinės rizika“. Jis turi įvardyti realistiškus scenarijus:

• Piktavališkas surinkimo scenarijus iškelia pasirašymo raktus iš bendros vykdyklės.
• Kūrėjas apeina šakų apsaugą ir įdiegia neperžiūrėtą kodą.
• Kompromituotas trečiosios šalies veiksmas pakeičia artefaktą surinkimo metu.
• Parengiamosios aplinkos prieigos duomenys suteikia prieigą prie produkcinės aplinkos.
• Diegimas įvyksta be susieto pakeitimo prašymo.
• Incidento rekonstrukcijai reikalingi konvejerio žurnalai perrašomi po septynių dienų.
• Priklausomybės užnuodijimo incidentas pasiekia priešprodukcinę arba produkcinę aplinką.

8.1 punktas tuomet reikalauja suplanuotos ir kontroliuojamos ISVS procesų veiklos, dokumentuotų įrodymų, planuotų pakeitimų kontrolės, nenumatytų pakeitimų peržiūros ir išorėje teikiamų procesų, produktų ar paslaugų, svarbių ISVS, kontrolės. Jei konvejeris keičia produkcinę aplinką, jis turi pateikti kontroliuojamos veiklos įrodymus.

Clarysec kontrolės modelis saugiam programinės įrangos teikimui

Clarysec susieja politiką, kontrolės priemones ir audito įrodymus. Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint saugų DevOps ir saugų kūrimą įtraukia į rizikos valdymo etapą, 14 žingsnį. Jame nurodoma, kad organizacijos turi apsaugoti CI/CD priemones, užtikrinti, kad diegimus galėtų inicijuoti tik įgalioti darbuotojai, naudoti MFA konvejerio prieigai, apsaugoti surinkimo artefaktų vientisumą ir registruoti bei stebėti CI/CD veiksmus.

„DevOps konvejerio kontrolės priemonės: CI/CD priemonės turi būti apsaugotos – diegimus gali inicijuoti tik įgalioti darbuotojai; konvejerio prieigai turi būti naudojamas MFA; turi būti saugomas surinkimo artefaktų vientisumas. CI/CD veiksmai turi būti registruojami ir stebimi.“

Šios gairės tampa įgyvendinamos, kai perkeliamos į politikos nuostatas ir įrodymų reikalavimus.

P24 Secure Development Policy Secure Development Policy nustato:

„Surinkimo artefaktai turi būti pasirašyti ir atsekami iki pirminio kodo pakeitimo įrašų.“

Tai viena stipriausių kontrolės priemonių CI/CD valdysenos programoje. Ji inžinerijos komandai nurodo, kad produkcinis artefaktas turi turėti patikrinamą kilmės grandinę iki pirminio kodo valdymo. Ji taip pat auditoriams nurodo, ką testuoti: pasirinkti produkcinį išleidimą, patikrinti artefakto parašą, validuoti pakeitimo įrašo nuorodą, peržiūrėti pull request patvirtinimą ir patvirtinti konvejerio surinkimo įrašą.

Ta pati politika nustato:

„Visa kūrimo veikla turi būti sekama per patvirtintas versijų kontrolės sistemas, kuriose taikomos prieigos kontrolės priemonės, audito pėdsakai ir šakų apsauga.“

Tai perkelia valdyseną aukščiau proceso grandinėje. Jei pirminio kodo saugyklos nėra apsaugotos, surinkimo kilmės įrodymai yra silpni. Jei šakų apsauga gali būti apeita, konvejeris gali tiksliai surinkti nepatvirtintą kodą. Jei audito pėdsakai išjungti, incidento rekonstrukcija priklauso nuo atminties ir ekrano kopijų, o ne nuo įrodymų.

Mažesnėms organizacijoms Secure Development Policy-sme Secure Development Policy-sme - SME apima praktišką minimalų reikalavimą:

„Kodo versijos, diegimo datos ir patvirtintojo sekimas“

Toks paprastas diegimo registras yra tvirtas pradinis taškas. Daugeliui MVĮ pirmąją dieną nereikia sudėtingos išleidimų valdysenos, tačiau jos turi žinoti, kuri versija buvo paleista, kada ir kas ją patvirtino.

MVĮ politika taip pat nustato:

„Prieiga prie produkcinės aplinkos diegimo priemonių ar sistemų turi būti kontroliuojama, registruojama žurnaluose ir periodiškai peržiūrima generalinio vadovo arba IT paslaugų teikėjo.“

Tai yra valdysenos žingsnis, kurio pasigenda daugelis mažesnių komandų. CI/CD platforma su produkcinės debesijos prieigos duomenimis yra privilegijuotas prieigos prie produkcinės aplinkos kelias.

Trys ISO/IEC 27002:2022 kontrolės sritys, kuriomis grindžiamas saugus CI/CD

Zenith Controls: The Cross-Compliance Guide Zenith Controls yra Clarysec daugialypės atitikties kompasas, skirtas oficialiems standartams ir sistemoms susieti su praktiniais kontrolės ryšiais. CI/CD konvejerių saugumo valdysenai svarbios trys ISO/IEC 27002:2022 kontrolės sritys.

Zenith Controls 5.21 apibūdina kaip prevencinę kontrolės priemonę, palaikančią konfidencialumą, vientisumą ir prieinamumą, o tiekėjų santykių saugumą – kaip pagrindinį operacinį gebėjimą. Tai tinka CI/CD, nes šiuolaikiniai konvejeriai priklauso nuo išorės paslaugų: pirminio kodo valdymo platformų, talpinamų vykdyklių, konteinerių registrų, atvirojo kodo paketų saugyklų, trečiųjų šalių GitHub veiksmų, skenavimo priemonių, debesijos diegimo API ir išorės kūrėjų.

5.21 susiejime Zenith Controls sieja IRT tiekimo grandinės saugumą su 5.19 Informacijos saugumu tiekėjų santykiuose, 5.20 Informacijos saugumo įtraukimu į tiekėjų susitarimus, 8.27 Saugios sistemos architektūros ir inžinerijos principais, 8.28 Saugiu programavimu, 8.29 Saugumo testavimu kūrimo ir priėmimo metu, 5.15 prieigos kontrole, 5.28 Įrodymų rinkimu, 8.25 Saugiu programinės įrangos kūrimo gyvavimo ciklu ir 8.30 Išoriniu kūrimu.

8.25 srityje Zenith Controls identifikuoja saugų programinės įrangos kūrimo gyvavimo ciklą kaip prevencinę kontrolės priemonę, saugančią konfidencialumą, vientisumą ir prieinamumą. Ji susieja saugumo reikalavimus, architektūrą, programavimą, testavimą, išorinį kūrimą ir 8.31 kūrimo, testavimo ir produkcinės aplinkų atskyrimą.

8.32 srityje Zenith Controls pateikia pakeitimų valdymą kaip tiltą tarp kūrimo ir operacijų. Jis siejamas su 8.9 Konfigūracijų valdymu, 8.8 Techninių pažeidžiamumų valdymu, saugiu SDLC ir reagavimu į incidentus. Todėl diegimo automatizavimas negali būti už pakeitimų valdysenos ribų. Tai yra mechanizmas, kuriuo vykdomi produkcinės aplinkos pakeitimai.

Surinkimo kilmės įrodymai: išleidimo istorija, kurią auditoriai gali atsekti

Surinkimo kilmės įrodymai – tai gebėjimas įrodymais atsakyti, iš kur kilo programinės įrangos artefaktas ir kaip jis buvo sukurtas. Tvirtas kilmės įrašas papasakoja išleidimo istoriją:

1. Kuri pirminio kodo saugykla ir pakeitimo įrašas buvo naudojami.
2. Kuri šaka arba žyma inicijavo surinkimą.
3. Kuris pull request, peržiūrėtojas ir patvirtinimas buvo susieti.
4. Kuri konvejerio apibrėžtis buvo vykdoma.
5. Kuri vykdyklė vykdė užduotį.
6. Kokios priklausomybės ir baziniai atvaizdai buvo naudojami.
7. Kokie testai ir saugumo vartai buvo įvykdyti.
8. Koks artefaktas buvo sukurtas.
9. Koks parašas arba maišos reikšmė buvo sugeneruota.
10. Kuris diegimas panaudojo artefaktą.

P05 Change Management Policy Change Management Policy suteikia valdysenos sąsają. Joje nustatyta:

„Priemonėmis pagrįsti pakeitimai vis tiek turi atitikti šią politiką ir būti atsekami iki atitinkamo pakeitimo prašymo ID.“

Tai atsako į dažną argumentą, kad automatizuotiems diegimams nereikia pakeitimų prašymų. Automatizavimas nepanaikina pakeitimų valdysenos. Jis pakeičia tai, kaip generuojami įrodymai.

Ta pati politika nustato:

„Visi pakeitimo prašymai, peržiūros, patvirtinimai ir pagalbiniai įrodymai turi būti registruojami centralizuotoje Pakeitimų valdymo sistemoje.“

Praktikoje pakeitimų valdymo sistema turi būti indeksas, o ne įrodymų sąvartynas. Prašymas turi nurodyti pirminio kodo saugyklą, surinkimo vykdymą, artefakto parašą, diegimo žurnalą ir grąžinimo į ankstesnę būseną planą. Išsamūs įrodymai gali likti inžinerijos priemonėse, jeigu apibrėžtas jų saugojimas, prieigos kontrolė ir eksportuojamumas.

Vykdyklių saugumo stiprinimas: dažnai nepastebima produkcinės aplinkos kontrolė

CI/CD vykdyklės dažnai laikomos vienkartine infrastruktūra, tačiau jos yra didelės rizikos vykdymo aplinkos. Vykdyklė gali pasiekti pirminį kodą, paslaptis, surinkimo podėlius, paketų saugyklas, pasirašymo raktus, artefaktų registrus ir debesijos diegimo vaidmenis. Jei ji yra nuolatinė, bendra, per daug privilegijuota arba prastai stebima, ji tampa privilegijuotu šoninio judėjimo tašku.

Saugios valdysenos pozicija paprasta: vykdyklės, kurios surenka arba diegia produkcinį kodą, turi būti stiprinamos kaip produkcinė infrastruktūra.

Test Data and Test Environment Policy Test Data and Test Environment Policy nustato:

„Integracija su CI/CD konvejeriais turi užtikrinti aplinkų ir autentifikavimo duomenų atskyrimą.“

Vykdyklė, galinti diegti į parengiamąją ir produkcinę aplinką naudodama tą patį prieigos duomenų modelį, iš esmės pažeidžia aplinkų atskyrimą, net jei infrastruktūra logiškai atskirta. Clarysec paprastai rekomenduoja atskiras diegimo tapatybes kiekvienai aplinkai, atskirus produkcinės aplinkos patvirtinimo vartus ir aiškias kontrolės priemones, neleidžiančias žemesnių aplinkų užduotims pasiekti produkcinių paslapčių.

Zenith Blueprint kontrolės priemonių taikymo etapo 21 žingsnyje tai sustiprina per kūrimo, testavimo ir produkcinės aplinkų atskyrimą:

„Jei naudojamas CI/CD, patvirtinkite, kad diegimo perkėlimas tarp aplinkų yra kontroliuojamas ir reikalauja peržiūros arba patvirtinimo. Dokumentuokite tai savo Aplinkų valdymo procedūroje ir pridėkite ekrano kopijų arba konsolės eksportų kaip pagrindimą.“

Tikrame audite tai reiškia, kad auditorius neturėtų matyti vien diagramos. Jis turi matyti konsolės eksportus, rodančius aplinkai specifinius prieigos duomenis, apsaugotas diegimo aplinkas, patvirtinimo vartus ir žurnalus, įrodančius, kad perkėlimas buvo kontroliuojamas.

Diegimo įrodymai: atitikties artefaktas, paslėptas akivaizdoje

Brandžiausios DevSecOps komandos įrodymų rinkimo nelaiko ketvirtiniu skubėjimu. Jos projektuoja konvejerius taip, kad įrodymai būtų generuojami automatiškai.

Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME kaip aktualius žurnalų įvykius nurodo:

„Sistemų žurnalai: konfigūracijos pakeitimai, administraciniai veiksmai, programinės įrangos diegimai, pataisų diegimo veikla“

CI/CD sistemos generuoja visas keturias kategorijas. Konvejerio konfigūracijos pakeitimai veikia tai, kaip surenkama programinė įranga. Administraciniai veiksmai keičia, kas gali patvirtinti arba diegti. Programinės įrangos diegimai vyksta surinkimo atvaizduose ir diegimo tiksluose. Pataisų diegimo veikla gali vykti per automatizuotus išleidimo procesus. Šie įvykiai turi būti registruojami žurnaluose, saugomi ir peržiūrimi pagal riziką.

Pasirengimui tyrimui P31S Evidence Collection and Forensics Policy-sme Evidence Collection and Forensics Policy-sme - SME nustato:

„Ekrano kopijos, eksportuoti žurnalai ir rinkmenų maišos reikšmės turi būti saugomos kartu su perdavimo grandinės rinkmena.“

Tai ypač svarbu po įtariamo konvejerio kompromitavimo. Vien ekrano kopijos yra silpni įrodymai. Žurnalai be maišos reikšmių gali būti ginčijami. Perdavimo grandinės rinkmena be šaltinio nuorodų yra neišsami.

Pagrįstas produkcinės aplinkos diegimo įrašas turi apimti toliau nurodytus elementus.

Šis paketas CI/CD paverčia ne techninių žingsnių seka, o valdysenos, kontrolės ir deramo rūpestingumo istorija.

CI/CD valdysenos susiejimas su NIS2, DORA, GDPR ir CRA

NIS2 taikoma daugeliui esminių ir svarbių subjektų, įskaitant skaitmeninę infrastruktūrą, IRT paslaugų valdymą ir skaitmeninių paslaugų teikėjus, kai tenkinami kriterijai. Article 20 yra ypač aktualus, nes nustato vadovybės lygmens kibernetinio saugumo pareigas. Valdymo organai turi tvirtinti kibernetinio saugumo rizikos valdymo priemones, prižiūrėti jų įgyvendinimą ir dalyvauti mokymuose.

Article 21 nustato rizikos valdymo pagrindą. Jame reikalaujama tinkamų ir proporcingų techninių, operacinių ir organizacinių priemonių, apimančių rizikos analizę, politikas, incidentų valdymą, veiklos tęstinumą, tiekimo grandinės saugumą, saugų įsigijimą, kūrimą ir priežiūrą, pažeidžiamumų valdymą, veiksmingumo vertinimą, kibernetinę higieną, kriptografiją, personalo saugumą, prieigos kontrolę, turto valdymą ir MFA, kai taikoma.

Article 23 papildo etapais vykdomą pranešimą apie reikšmingus incidentus, įskaitant ankstyvą įspėjimą per 24 valandas nuo sužinojimo, pranešimą apie incidentą per 72 valandas ir galutinę ataskaitą ne vėliau kaip per vieną mėnesį nuo pranešimo apie incidentą. Jei CI/CD kompromitavimas galėtų sukelti didelį veiklos sutrikimą, finansinių nuostolių ar reikšmingą žalą kitiems, incidentų klasifikavimo procesas turi būti parengtas dar iki incidento.

Finansų sektoriaus subjektams DORA taikomas nuo 2025 m. sausio 17 d. ir apima IRT rizikos valdymą, pranešimą apie incidentus, atsparumo testavimą, dalijimąsi informacija, IRT trečiųjų šalių rizikos valdymą ir sutartinius reikalavimus. Article 5 reikalauja vidaus valdysenos ir kontrolės sistemos IRT rizikai, už kurią atsakingas valdymo organas. Article 6 reikalauja dokumentuotos IRT rizikos valdymo sistemos, integruotos į bendrą rizikos valdymą.

Articles 8 to 14 tiesiogiai susiejami su CI/CD konvejerių valdysena. Finansų sektoriaus subjektai turi identifikuoti ir klasifikuoti IRT palaikomas verslo funkcijas, turtą, priklausomybes, grėsmes ir pažeidžiamumus. Jie turi apsaugoti IRT sistemas taikydami politikas, prieigos kontrolės priemones, stiprų autentifikavimą, kriptografinių raktų apsaugą, kontroliuojamą IRT pakeitimų valdymą, pataisų diegimą ir segmentavimą. Jie turi aptikti anomalijas, reaguoti, atkurti veiklą ir mokytis iš incidentų.

Articles 28 to 30 yra ne mažiau svarbūs, nes CI/CD platformos, pirminio kodo valdymo teikėjai, artefaktų registrai, debesijos surinkimo sistemos ir išorės kūrėjai gali būti IRT trečiųjų šalių priklausomybės. DORA tikisi deramo rūpestingumo, sutartinių apsaugos priemonių, koncentracijos rizikos vertinimo, audito ir patikrinimo teisių, nutraukimo sąlygų, išėjimo strategijų ir paslaugų lygio sąlygų.

GDPR prideda atskaitomybės perspektyvą. Article 5 reikalauja, kad asmens duomenys būtų tvarkomi teisėtai, sąžiningai, skaidriai, apibrėžtais tikslais, minimizuojami, tikslūs, saugomi tik tiek, kiek reikia, ir apsaugoti nuo neteisėto ar neautorizuoto tvarkymo bei atsitiktinio praradimo, sunaikinimo ar sugadinimo. Article 5(2) reikalauja, kad duomenų valdytojas galėtų įrodyti atitiktį.

CI/CD konvejeriai svarbūs GDPR, nes kūrėjai gali naudoti produkcinius duomenis testavimo aplinkose, konvejerio žurnalai gali atskleisti asmens duomenis ar prieigos raktus, išleidimai gali pakeisti tvarkymo logiką, o kompromituoti artefaktai gali sukelti asmens duomenų saugumo pažeidimus. Kai programinės įrangos pakeitimai veikia privatumo kontrolės priemones, pakeitimo įrašas turi užfiksuoti poveikį privatumui. Kai konvejerio incidentas sukelia neautorizuotą prieigą prie asmens duomenų, pažeidimo vertinimas turi būti susietas su incidentų valdymu.

CRA lūkesčiai papildo produkto saugumo ir saugaus atnaujinimo įrodymus. Gamintojams ir programinės įrangos teikėjams, ES rinkai pateikiantiems produktus su skaitmeniniais elementais, klientai vis dažniau tikisi produkto saugumo bylų, pažeidžiamumų valdymo įrodymų, saugių atnaujinimų kontrolės priemonių ir išleidimo vientisumo. CI/CD valdysena pateikia didelę dalį šių įrodymų per pirminio kodo atsekamumą, pasirašytus artefaktus, pažeidžiamumų skenavimo rezultatus, išleidimo pastabas, saugumo pataisas ir atnaujinimų platinimo įrašus.

NIST CSF 2.0 ir COBIT 2019: audito perspektyva už ISO ribų

NIST CSF 2.0 suteikia integracinį sluoksnį kibernetinio saugumo valdysenai. Jo branduolys, organizaciniai profiliai ir pakopos padeda organizacijoms suprasti esamą ir tikslinę būklę, prioritetizuoti veiksmus pagal teisinius ir reglamentavimo reikalavimus bei komunikuoti kibernetinę riziką.

CI/CD atveju Clarysec dažnai sukuria programinės įrangos teikimo konvejerio profilį. Esamas profilis užfiksuoja, kaip šiandien veikia pirminio kodo valdymas, vykdyklės, artefaktų pasirašymas ir diegimo patvirtinimai. Tikslinis profilis apibrėžia reikalaujamą būseną reglamentuojamai veiklai. Spragų planas tampa įgyvendinimo veiksmų planu.

NIST GOVERN funkcija yra ypač aktuali. GV.OC-03 reikalauja suprasti ir valdyti teisinius, reglamentavimo ir sutartinius kibernetinio saugumo reikalavimus. GV.RM apima rizikos apetitą ir standartizuotą rizikos prioritetizavimą. GV.RR priskiria vadovybės atskaitomybę, vaidmenis ir išteklius. GV.PO reikalauja nustatyti, taikyti, peržiūrėti ir atnaujinti kibernetinio saugumo rizikos politikas. GV.OV apima priežiūrą ir veiklos vertinimą.

COBIT 2019 arba ISACA tipo auditorius dažnai mažiau gilinsis į artefaktų pasirašymo kriptografines detales ir daugiau į valdysenos projektavimą. Jis klaus, ar apibrėžta savininkystė, ar pakeitimų įgalinimas kontroliuojamas, ar trečiųjų šalių paslaugos valdomos pagal riziką, ar stebėsena suteikia patikinimą, ar išimtys patvirtinamos ir ar vadovybė gauna prasmingas ataskaitas.

Dažnos CI/CD audito nesėkmės ir valdybos lygmens rodikliai

Dauguma CI/CD audito išvadų yra nuspėjamos. Pirmoji – nesusieti įrodymai. Komanda turi Git žurnalus, konvejerio žurnalus ir diegimo žurnalus, tačiau nėra vieno pakeitimo įrašo, kuris juos sujungtų. Antroji – per daug privilegijuotas automatizavimas, kai viena užduotis gali skaityti produkcines paslaptis, siųsti artefaktus, tvirtinti diegimus ir keisti konvejerio apibrėžtis. Trečioji – nuolatinės bendros vykdyklės, kurios sukuria užteršimo riziką tarp projektų ir apsunkina skaitmeninės ekspertizės apimties nustatymą po kompromitavimo.

Kitos dažnos nesėkmės – nepasirašyti arba perrašyti artefaktai, neformalūs skenavimo apeinimai, tiekėjų nematomumas ir privatumo duomenų nutekėjimas žurnaluose. Geras konvejeris leidžia išimtis, tačiau reikalauja patvirtinimo, galiojimo pabaigos, rizikos savininkystės ir peržiūros.

Saugumo vadovai neturėtų valdybai teikti vien skenavimo priemonių skaičiaus. Vietoj to reikia teikti išleidimų pasitikėjimo rodiklius:

• Produkcinės aplinkos diegimų, susietų su patvirtintais pakeitimų įrašais, procentinė dalis.
• Produkcinių artefaktų, kurie yra pasirašyti ir atsekami iki pirminio kodo pakeitimo įrašų, procentinė dalis.
• Diegimų, naudojančių išimtis arba neatidėliotinus patvirtinimus, skaičius.
• Privilegijuotų CI/CD naudotojų, turinčių MFA ir neseniai atliktą prieigos peržiūrą, procentinė dalis.
• Aktyvių ilgalaikių diegimo prieigos duomenų skaičius.
• Kritinių paslaugų, naudojančių sustiprintas arba laikinąsias vykdykles, procentinė dalis.
• Vidutinis laikas atšaukti arba periodiškai pakeisti konvejerio paslaptis po incidento.
• Kritinių tiekėjų priklausomybių, palaikančių programinės įrangos teikimą, skaičius.
• Įrodymų išsamumo rodiklis audito imtimi atrinktiems išleidimams.

Šie rodikliai palaiko ISO/IEC 27001:2022 lyderystę, planavimą ir operacinę kontrolę. Jie taip pat palaiko NIS2 Article 20 vadovybės priežiūrą ir DORA valdysenos lūkesčius.

Padarykite konvejerį audituojamą prieš incidentą

CI/CD konvejerių saugumo valdysena 2026 m. nėra skirta lėtinti inžineriją. Ji skirta užtikrinti, kad programinės įrangos teikimas būtų patikimas, atsparus ir įrodomas. Geriausios programos naudoja automatizavimą įrodymams pagreitinti, o ne valdysenai apeiti.

Praktinis Clarysec įgyvendinimas prasideda nuo trijų veiksmų.

1. Naudokite Zenith Blueprint Zenith Blueprint, kad saugų DevOps, pirminio kodo prieigą, aplinkų atskyrimą ir pakeitimų valdymą įtrauktumėte į savo ISO/IEC 27001:2022 įgyvendinimo veiksmų planą.
2. Naudokite Zenith Controls Zenith Controls, kad susietumėte CI/CD rizikas per saugų SDLC, IRT tiekimo grandinę, prieigos kontrolę, pakeitimų valdymą, įrodymų rinkimą, NIS2, DORA, GDPR, NIST CSF 2.0 ir COBIT 2019 audito perspektyvas.
3. Įdiekite Clarysec politikų šablonus, įskaitant Secure Development Policy, Change Management Policy, Test Data and Test Environment Policy, Secure Development Policy-sme - SME, Logging and Monitoring Policy-sme - SME ir Evidence Collection and Forensics Policy-sme - SME, kad apibrėžtumėte, kas tvirtina išleidimus, kaip atsekami artefaktai, kaip kontroliuojamos vykdyklės ir kokie įrodymai turi būti saugomi.

Jei kita jūsų audito imtis prasidės prašymu „parodykite produkcinio išleidimo pėdsaką“, jūsų komanda turi gebėti atsakyti per kelias minutes, o ne savaites. Tai yra skirtumas tarp DevOps automatizavimo ir valdomo programinės įrangos teikimo.

Atsisiųskite Clarysec politikų rinkinį, peržiūrėkite savo CI/CD konvejerį pagal Zenith Blueprint ir Zenith Controls arba užsisakykite Clarysec vertinimą, kad konvejerį iš audito nerimo šaltinio paverstumėte skaitmeninio atsparumo kertiniu akmeniu.