CI/CD-folyamatok biztonsági irányítása a 2026-os auditokra

Hétfő reggel 08:17 van, amikor egy növekvő fintech vállalat információbiztonsági vezetője megkapja azt az üzenetet, amelytől minden biztonsági vezető tart:

„Az éles build tisztának tűnik, de az artefaktum hash-e nem egyezik a forráskód-committal.”

Perceken belül a mérnöki csapat megerősíti, hogy a kiadás átment az egységteszteken, a telepítési jegy létezik, és az ügyféloldali szolgáltatás stabil. A CI/CD-folyamat azonban más történetet mutat. Egy saját üzemeltetésű CI-runner több projektben is újra lett használva. Egy ideiglenes felhőalapú hitelesítő adat a tervezettnél tovább maradt aktív. Az artefaktumtár aláírt konténerképet mutat, de az aláíró kulcs ugyanarról a runnerről volt elérhető, amely nem megbízható buildszkripteket futtatott.

A kiadásmenedzser bizonyítani tudja, hogy valami telepítésre került. Amit a szervezet nem tud bizonyítani, legalábbis nem elég gyorsan, az az, hogy pontosan mi készült el, ki hagyta jóvá, tiszta volt-e a buildkörnyezet, és a bizonyítékok megállnák-e a helyüket egy audit vagy incidensvizsgálat során.

Ez már nem pusztán DevOps-probléma.

2026-ban a CI/CD-folyamatok biztonsági irányítása a szoftverellátási lánc biztonsága, a működési reziliencia, az adatvédelmi elszámoltathatóság, a termékbiztonság és az igazgatósági szintű kiberkockázati felügyelet metszéspontjában helyezkedik el. A NIS2 arra kötelezi az irányító testületeket, hogy hagyják jóvá és felügyeljék a kiberbiztonsági kockázatkezelési intézkedéseket. A DORA megköveteli a pénzügyi szervezetektől az IKT-kockázat, az incidensek, a tesztelés és a harmadik felektől való függőségek irányítását. A GDPR előírja az adatkezelőknek és adatfeldolgozóknak, hogy igazolni tudják a személyes adatok megfelelő biztonságát és az elszámoltathatóságot. A Cyber Resilience Act növeli a piaci elvárásokat a digitális elemeket tartalmazó biztonságos termékekkel, a biztonságos frissítésekkel és a sérülékenységkezeléssel kapcsolatban. Az ISO/IEC 27001:2022 olyan IBIR-t követel meg, amely a kockázatkezelést szabályozott, bizonyítékokkal alátámasztott működéssé alakítja.

A CI/CD-folyamat a modern szoftverbizalom auditnyomává vált.

Az új megfelelési kérdés: bizonyítható, mi jutott éles környezetbe?

A DevSecOps programok évekig arra összpontosítottak, hogy vizsgálóeszközöket illesszenek a CI/CD-folyamatokba. A statikus elemzés, a függőség-ellenőrzések, a titokvizsgálat, a konténervizsgálat és az infrastructure-as-code ellenőrzése általánossá vált. Ezek a kontrollok továbbra is fontosak, de nem válaszolják meg azt az irányítási kérdést, amelyet ma az auditorok, szabályozó hatóságok, ügyfelek és igazgatóságok feltesznek:

Bizonyítani tudja-e a szervezet, hogy minden éles telepítés jóváhagyott forráskódból származott, szabályozott környezetben készült, ellenőrizhető artefaktumot eredményezett, teljesítette az előírt biztonsági kapukat, jóváhagyott hitelesítő adatokat használt, követte a változáskezelést, és megőrizhető bizonyítékokat hozott létre?

A támadók tudják, hogy a buildrendszerek, csomagfüggőségek, fejlesztői tokenek, CI-runnerek, kiadásautomatizálás, artefaktumtárak és felhőalapú telepítési szerepkörök nagy értékű célpontok. Egy kompromittálódott CI/CD-folyamat megkerülheti a hagyományos védelmi rétegeket, mert megbízható automatizálást használ rosszindulatú kód megbízható környezetekbe juttatására.

Egy érett CI/CD-folyamatbiztonsági irányítási modellhez ezért hat bizonyítéki pillér szükséges.

Itt tér el a Clarysec megközelítése a checklist-alapú megfeleléstől. A CI/CD-platformot irányított üzleti folyamatként kezeljük, nem pusztán technikai eszközként. Ezt a folyamatot az IBIR hatókörébe kell vonni, kockázatértékelésnek kell alávetni, kontrollálni, felügyelni, auditálni és fejleszteni kell.

Helyezze a CI/CD-t az ISO/IEC 27001:2022 szerinti IBIR-be

Az ISO/IEC 27001:2022 a kontextussal, az érdekelt felekkel és a hatókörrel indul. A 4.1–4.4 pontok előírják a szervezetek számára a belső és külső tényezők megértését, az érdekelt felek követelményeinek meghatározását, a jogi, szabályozási és szerződéses követelmények azonosítását, valamint az IBIR alkalmazási területének meghatározását, figyelembe véve a más szervezetekkel fennálló függőségeket.

Egy SaaS-szolgáltató, fintech, menedzselt szolgáltató, szoftverszállító vagy felhőnatív vállalkozás esetében a CI/CD szinte mindig ezen hatókörön belül van, mert közvetlenül befolyásolja a szolgáltatásnyújtást, az ügyféladatokat, az éles infrastruktúrát és a szerződéses vállalásokat.

Az 5.1–5.3 pontok a felső vezetést teszik felelőssé az IBIR-ért. Ez azért fontos, mert a modern kiadásautomatizálás a mérnöki terület, a biztonság, a felhőüzemeltetés, a beszerzés, a megfelelés és a termékmenedzsment között helyezkedik el. Ha egyetlen felső vezető sem felel az éles telepítési automatizálás kockázatvállalási hajlandóságáért, a szervezet rendszerint széttagolt eszközkészlettel és következetlen bizonyítékokkal működik.

A 6.1.1–6.1.3 pontok adják a tervezési alapot. A szervezetnek értékelnie kell a bizalmasságot, a sértetlenséget és a rendelkezésre állást érintő kockázatokat, ki kell jelölnie a kockázattulajdonosokat, össze kell vetnie a kockázatokat a kritériumokkal, kezelési módokat kell kiválasztania, a kiválasztott kontrollokat össze kell hasonlítania az A melléklettel, el kell készítenie az alkalmazhatósági nyilatkozatot, és jóváhagyást kell szereznie a kockázatkezelési tervre és a maradványkockázatra.

Egy CI/CD-kockázatértékelésnek nem elegendő annyit rögzítenie, hogy „szoftverellátási lánc kockázata”. Valószerű forgatókönyveket kell megneveznie:

• Egy rosszindulatú buildszkript aláíró kulcsokat visz ki egy megosztott runnerről.
• Egy fejlesztő megkerüli az ágvédelmi szabályokat, és felülvizsgálatlan kódot telepít.
• Egy kompromittálódott harmadik féltől származó workflow-elem módosít egy artefaktumot a build során.
• Egy előéles hitelesítő adat éles hozzáférést biztosít.
• Telepítés történik kapcsolódó változtatási kérelem nélkül.
• Az incidens rekonstrukciójához szükséges CI/CD-naplók hét nap után felülíródnak.
• Egy függőségmérgezési incidens eléri az előéles vagy éles környezetet.

A 8.1 pont ezt követően megköveteli az IBIR-folyamatok tervezett és szabályozott működését, a dokumentált bizonyítékokat, a tervezett változások kontrollját, a nem szándékolt változások felülvizsgálatát, valamint az IBIR szempontjából releváns külső folyamatok, termékek vagy szolgáltatások kontrollját. Ha a CI/CD-folyamat éles környezetet módosít, bizonyítékot kell előállítania a szabályozott működésről.

A Clarysec kontrollmodellje a biztonságos szoftverszállításhoz

A Clarysec összekapcsolja a szabályzatokat, a kontrollokat és az auditbizonyítékokat. A Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint a biztonságos DevOps-ot és a biztonságos fejlesztést a kockázatkezelési fázis 14. lépésébe helyezi. Kimondja, hogy a szervezeteknek biztosítaniuk kell a CI/CD-eszközök védelmét, gondoskodniuk kell arról, hogy csak engedélyezett munkatársak indíthassanak telepítéseket, MFA-t kell használniuk a CI/CD-hozzáféréshez, védeniük kell a build artefaktumok sértetlenségét, valamint naplózniuk és felügyelniük kell a CI/CD-műveleteket.

„DevOps pipeline-kontrollok: A CI/CD-eszközöket védeni kell – csak engedélyezett munkatársak indíthatnak telepítéseket; a CI/CD-hozzáféréshez MFA-t kell használni; védeni kell a build artefaktumok sértetlenségét. A CI/CD-műveleteket naplózni és felügyelni kell.”

Ez az iránymutatás akkor válik végrehajthatóvá, amikor szabályzati pontokra és bizonyítékkövetelményekre fordítjuk le.

A P24 Biztonságos fejlesztési szabályzat Biztonságos fejlesztési szabályzat kimondja:

„A build artefaktumokat alá kell írni, és visszakövethetővé kell tenni a forráskód-commitokhoz.”

Ez a CI/CD-irányítási program egyik legerősebb kontrollja. A mérnöki csapat számára egyértelművé teszi, hogy az éles artefaktumnak ellenőrizhető származási lánccal kell rendelkeznie egészen a forráskód-kezelésig. Az auditorok számára pedig kijelöli, mit kell tesztelni: ki kell választani egy éles kiadást, meg kell vizsgálni az artefaktum aláírását, ellenőrizni kell a commit-hivatkozást, felül kell vizsgálni a pull request jóváhagyását, és meg kell erősíteni a CI/CD buildbejegyzését.

Ugyanez a szabályzat kimondja:

„Minden fejlesztési tevékenységet jóváhagyott verziókezelő rendszerekben kell nyomon követni, érvényesített hozzáférés-szabályozással, auditnyomokkal és ágvédelmi mechanizmusokkal.”

Ez az irányítást a folyamat korábbi pontjára helyezi. Ha a forráskód-adattárak nincsenek védve, a build-eredetigazolás gyenge. Ha az ágvédelmi mechanizmusok megkerülhetők, a CI/CD-folyamat megbízhatóan építhet fel nem jóváhagyott kódot. Ha az auditnyomok ki vannak kapcsolva, az incidensrekonstrukció bizonyítékok helyett emlékezetre és képernyőképekre épül.

Kisebb szervezetek számára a Secure Development Policy-sme Secure Development Policy-sme - SME gyakorlati minimumkövetelményt tartalmaz:

„A kódverzió, a telepítési dátum és a jóváhagyó nyomon követése”

Ez az egyszerű telepítési nyilvántartás erős kiindulópont. Sok KKV-nak az első napon nincs szüksége nehézkes kiadásirányításra, de tudnia kell, melyik verzió mikor került élesbe, és ki hagyta jóvá.

A KKV-szabályzat azt is kimondja:

„Az éles telepítési eszközökhöz vagy rendszerekhez való hozzáférést kontrollálni, naplózni és időszakosan felülvizsgálni kell az ügyvezetőnek vagy az IT-szolgáltatónak.”

Ez az az irányítási lépés, amelyet sok kisebb csapat elmulaszt. Egy éles felhőalapú hitelesítő adatokkal rendelkező CI/CD-platform privilegizált éles hozzáférési útvonal.

Három ISO/IEC 27002:2022 kontrollterület a biztonságos CI/CD mögött

A Zenith Controls: The Cross-Compliance Guide Zenith Controls a Clarysec több megfelelési keretrendszert átfogó iránytűje, amely a hivatalos szabványokat és keretrendszereket gyakorlati kontrollkapcsolatokba rendezi. A CI/CD-folyamatok biztonsági irányításában három ISO/IEC 27002:2022 kontrollterület központi jelentőségű.

A Zenith Controls az 5.21-et megelőző kontrollként írja le, amely támogatja a bizalmasságot, a sértetlenséget és a rendelkezésre állást, és a beszállítói kapcsolatok biztonságát kulcsfontosságú működési képességként kezeli. Ez illeszkedik a CI/CD-hez, mert a modern CI/CD-folyamatok külső szolgáltatásoktól függenek: forráskód-kezelő platformoktól, hosztolt runnerektől, konténer-regiszterektől, nyílt forráskódú csomagadattáraktól, harmadik féltől származó GitHub Actions-műveletektől, vizsgálóeszközöktől, felhőalapú telepítési API-któl és kiszervezett fejlesztőktől.

Az 5.21 leképezésében a Zenith Controls az IKT-ellátási lánc biztonságát a 5.19 Beszállítói kapcsolatok információbiztonsága, a 5.20 Információbiztonság kezelése beszállítói megállapodásokban, a 8.27 Biztonságos rendszerarchitektúra és mérnöki alapelvek, a 8.28 Biztonságos kódolás, a 8.29 Biztonsági tesztelés fejlesztésben és átvételben, a 5.15 Hozzáférés-szabályozás, a 5.28 Bizonyítékgyűjtés, a 8.25 Biztonságos fejlesztési életciklus és a 8.30 Kiszervezett fejlesztés kontrollokhoz kapcsolja.

A 8.25 esetében a Zenith Controls a biztonságos fejlesztési életciklust a bizalmasságot, a sértetlenséget és a rendelkezésre állást védő megelőző kontrollként azonosítja. Összekapcsolja a biztonsági követelményeket, az architektúrát, a kódolást, a tesztelést, a kiszervezett fejlesztést és a 8.31 Fejlesztési, teszt- és éles környezetek szétválasztása kontrollt.

A 8.32 esetében a Zenith Controls a változáskezelést a fejlesztés és az üzemeltetés közötti hídként értelmezi. Kapcsolódik a 8.9 Konfigurációkezeléshez, a 8.8 Technikai sérülékenységek kezeléséhez, a biztonságos SDLC-hez és az incidensreagáláshoz. Ezért a telepítési automatizálás nem helyezhető a változásirányításon kívülre. Ez az a mechanizmus, amelyen keresztül az éles változtatások megtörténnek.

Build-eredetigazolás: a kiadási történet, amelyet az auditor követni tud

A build-eredetigazolás annak bizonyítékokkal alátámasztott megválaszolása, hogy honnan származik egy szoftverartefaktum, és hogyan állították elő. Egy erős eredetigazolási bejegyzés elmeséli a kiadás történetét:

1. Melyik forráskód-adattárat és commitot használták.
2. Melyik ág vagy tag indította a buildet.
3. Melyik pull request, felülvizsgáló és jóváhagyás kapcsolódott hozzá.
4. Melyik CI/CD-folyamatdefiníció futott le.
5. Melyik runner hajtotta végre a feladatot.
6. Mely függőségeket és alap rendszerképeket használták.
7. Mely tesztek és biztonsági kapuk futottak le.
8. Melyik artefaktum készült el.
9. Melyik aláírás vagy hash jött létre.
10. Melyik telepítés használta fel az artefaktumot.

A P05 Változáskezelési szabályzat Változáskezelési szabályzat biztosítja az irányítási kapcsolatot. Kimondja:

„Az eszközalapú változtatásoknak továbbra is meg kell felelniük ennek a szabályzatnak, és visszakövethetőnek kell lenniük egy megfelelő változtatási kérelem ID-hoz.”

Ez kezeli azt a gyakori érvet, hogy az automatizált telepítésekhez nincs szükség változásjegyekre. Az automatizálás nem szünteti meg a változásirányítást. A bizonyítékok előállításának módját változtatja meg.

Ugyanez a szabályzat kimondja:

„Minden változtatási kérelmet, felülvizsgálatot, jóváhagyást és alátámasztó bizonyítékot a központi Változáskezelő Rendszerben kell rögzíteni.”

A gyakorlatban a változáskezelő rendszernek indexként kell működnie, nem bizonyítéktárolóként. A jegynek hivatkoznia kell a forráskód-adattárra, a buildfuttatásra, az artefaktum aláírására, a telepítési naplóra és a visszaállítási tervre. A részletes bizonyítékok a mérnöki eszközökben maradhatnak, ha a megőrzés, a hozzáférés-szabályozás és az exportálhatóság meghatározott.

Runner-környezetek megerősítése: az elhanyagolt éles kontroll

A CI/CD-runnereket gyakran eldobható infrastruktúraként kezelik, pedig magas kockázatú végrehajtási környezetek. Egy runner hozzáférhet forráskódhoz, titkos adatokhoz, build cache-ekhez, csomagadattárakhoz, aláíró kulcsokhoz, artefaktumtárakhoz és felhőalapú telepítési szerepkörökhöz. Ha tartós, megosztott, túlzott jogosultságú vagy gyengén felügyelt, privilegizált pivotponttá válik.

A biztonságos irányítási álláspont egyszerű: az éles kódot építő vagy telepítő runnereket az éles infrastruktúrához hasonlóan kell megerősíteni.

A Tesztadat- és tesztkörnyezet-kezelési szabályzat Tesztadat- és tesztkörnyezet-kezelési szabályzat kimondja:

„A CI/CD pipeline-okkal való integrációnak érvényesítenie kell a környezetek és a hitelesítő adatok szétválasztását.”

Az a runner, amely ugyanazzal a hitelesítési modellel képes előéles és éles környezetbe telepíteni, sérti a környezetek szétválasztásának célját, még akkor is, ha az infrastruktúra logikailag elkülönül. A Clarysec jellemzően külön telepítési identitásokat javasol környezetenként, külön jóváhagyási kapukat az éles környezethez, valamint kifejezett kontrollokat, amelyek megakadályozzák, hogy alacsonyabb környezetek feladatai éles titkos adatokhoz férjenek hozzá.

A Zenith Blueprint Kontrollok működésben fázisának 21. lépése ezt a fejlesztési, teszt- és éles környezetek szétválasztásán keresztül erősíti meg:

„CI/CD használata esetén ellenőrizze, hogy a környezetek közötti telepítési promóció kontrollált, és felülvizsgálatot vagy jóváhagyást igényel. Dokumentálja ezt az Environment Management Procedure eljárásban, és alátámasztásként készítsen képernyőképeket vagy konzolexportokat.”

Egy valós audit során ez azt jelenti, hogy az auditor ne csak diagramot lásson. Látnia kell olyan konzolexportokat, amelyek környezetenkénti hitelesítő adatokat, védett telepítési környezeteket, jóváhagyási kapukat és olyan naplókat mutatnak, amelyek bizonyítják, hogy a promóció kontrollált volt.

Telepítési bizonyíték: a szem előtt rejtőző megfelelési artefaktum

A legérettebb DevSecOps csapatok nem negyedéves kapkodásként kezelik a bizonyítékgyűjtést. Úgy tervezik meg a CI/CD-folyamatokat, hogy automatikusan állítsanak elő bizonyítékokat.

A Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME a releváns naplóeseményeket így azonosítja:

„Rendszernaplók: Konfigurációváltozások, adminisztratív műveletek, szoftvertelepítések, javításkezelési tevékenység”

A CI/CD-rendszerek mind a négy kategóriát előállítják. A CI/CD-konfiguráció változásai befolyásolják a szoftver buildelésének módját. Az adminisztratív műveletek megváltoztatják, ki hagyhat jóvá vagy telepíthet. Szoftvertelepítések történnek a build rendszerképekben és a telepítési célrendszereken. A javításkezelési tevékenység automatizált kiadási folyamatokon keresztül is megvalósulhat. Ezeket az eseményeket kockázat alapján naplózni, megőrizni és felülvizsgálni kell.

A vizsgálati felkészültség érdekében a P31S Bizonyítékgyűjtési és forenzikai szabályzat-sme Evidence Collection and Forensics Policy-sme - SME kimondja:

„A képernyőképeket, exportált naplókat és fájlhasheket a bizonyítéklánc-fájllal együtt kell tárolni.”

Ez különösen fontos egy feltételezett CI/CD-kompromittálódás után. A képernyőképek önmagukban gyenge bizonyítékok. A hash nélküli naplókat vitathatják. A forráshivatkozások nélküli bizonyítéklánc-fájl hiányos.

Egy igazolható éles telepítési bejegyzésnek a következőket kell tartalmaznia.

Ez a csomag a CI/CD-t technikai lépések sorozatából az irányítás, kontroll és kellő gondosság történetévé alakítja.

A CI/CD-irányítás leképezése NIS2, DORA, GDPR és CRA követelményekre

A NIS2 számos alapvető és fontos szervezetre alkalmazandó, beleértve a digitális infrastruktúrát, az IKT-szolgáltatásmenedzsmentet és a digitális szolgáltató szervezeteket, ahol a kritériumok teljesülnek. Az Article 20 különösen releváns, mert vezetői szintű kiberbiztonsági kötelezettségeket hoz létre. Az irányító testületeknek jóvá kell hagyniuk a kiberbiztonsági kockázatkezelési intézkedéseket, felügyelniük kell azok végrehajtását, és képzésben kell részesülniük.

Az Article 21 adja a kockázatkezelési alapot. Megfelelő és arányos technikai, operatív és szervezeti intézkedéseket ír elő, amelyek kiterjednek a kockázatelemzésre, szabályzatokra, incidenskezelésre, üzletmenet-folytonosságra, ellátási lánc biztonságára, biztonságos beszerzésre, fejlesztésre és karbantartásra, sérülékenységkezelésre, eredményességértékelésre, kiberhigiéniára, kriptográfiára, HR-biztonságra, hozzáférés-szabályozásra, eszközkezelésre és szükség szerint MFA-ra.

Az Article 23 szakaszos jelentős incidensjelentést ír elő, beleértve a tudomásszerzéstől számított 24 órán belüli korai figyelmeztetést, a 72 órán belüli incidensbejelentést és az incidensbejelentést követő legkésőbb egy hónapon belüli zárójelentést. Ha egy CI/CD-kompromittálódás súlyos működési zavart, pénzügyi veszteséget vagy másoknak okozott jelentős kárt eredményezhet, az incidensbesorolási folyamatnak már az incidens előtt készen kell állnia.

A pénzügyi szervezetekre a DORA 2025. január 17-től alkalmazandó, és lefedi az IKT-kockázatkezelést, az incidensjelentést, a rezilienciatesztelést, az információmegosztást, az IKT harmadik fél kockázatkezelést és a szerződéses követelményeket. Az Article 5 belső irányítási és kontrollkeretrendszert követel meg az IKT-kockázatra, irányító testületi felelősséggel. Az Article 6 dokumentált, az átfogó kockázatkezelésbe integrált IKT-kockázatkezelési keretrendszert ír elő.

Az Articles 8 to 14 közvetlenül leképezhetők a CI/CD-folyamatok irányítására. A pénzügyi szervezeteknek azonosítaniuk és osztályozniuk kell az IKT által támogatott üzleti funkciókat, vagyonelemeket, függőségeket, fenyegetéseket és sérülékenységeket. Szabályzatokkal, hozzáférés-szabályozással, erős hitelesítéssel, kriptográfiai kulcsok védelmével, kontrollált IKT-változáskezeléssel, javításkezeléssel és szegmentálással kell védeniük az IKT-rendszereket. Észlelniük kell az anomáliákat, reagálniuk kell, helyre kell állniuk, és tanulniuk kell az incidensekből.

Az Articles 28 to 30 ugyanilyen fontosak, mert a CI/CD-platformok, forráskód-kezelő szolgáltatók, artefaktumtárak, felhőalapú buildrendszerek és kiszervezett fejlesztők IKT harmadik fél függőségek lehetnek. A DORA kellő gondosságot, szerződéses védelmi intézkedéseket, koncentrációs kockázat értékelését, auditálási és ellenőrzési jogokat, megszüntetési kiváltó okokat, kilépési stratégiákat és szolgáltatási szintre vonatkozó záradékokat vár el.

A GDPR az elszámoltathatósági nézőpontot adja hozzá. Az Article 5 előírja, hogy a személyes adatokat jogszerűen, tisztességesen, átláthatóan, meghatározott célokra, adattakarékosan, pontosan, csak a szükséges ideig megőrizve, valamint a jogosulatlan vagy jogellenes adatkezeléssel és a véletlen elvesztéssel, megsemmisüléssel vagy károsodással szemben védetten kell kezelni. Az Article 5(2) megköveteli, hogy az adatkezelő igazolni tudja a megfelelést.

A CI/CD-folyamatok a GDPR szempontjából azért fontosak, mert a fejlesztők éles adatokat használhatnak tesztkörnyezetekben, a CI/CD-naplók személyes adatokat vagy tokeneket fedhetnek fel, a kiadások módosíthatják az adatkezelési logikát, és a kompromittálódott artefaktumok személyesadat-sértést okozhatnak. Ahol a szoftverváltozások adatvédelmi kontrollokat érintenek, a változásbejegyzésnek rögzítenie kell az adatvédelmi hatást. Ahol egy CI/CD-incidens jogosulatlan hozzáférést okoz személyes adatokhoz, az incidenskezeléshez hozzá kell kapcsolni az adatsértési értékelést.

A CRA elvárásai termékbiztonsági és biztonságos frissítési bizonyítékokat adnak hozzá. Az EU piacán digitális elemeket tartalmazó termékeket forgalomba hozó gyártók és szoftverszolgáltatók esetében az ügyfelek egyre inkább elvárják a termékbiztonsági dokumentációt, a sérülékenységkezelési bizonyítékokat, a biztonságos frissítési kontrollokat és a kiadások sértetlenségét. A CI/CD-irányítás e bizonyítékok jelentős részét biztosítja a forrás-visszakövethetőségen, aláírt artefaktumokon, sérülékenységvizsgálati eredményeken, kiadási megjegyzéseken, biztonsági javításokon és frissítésterjesztési bejegyzéseken keresztül.

NIST CSF 2.0 és COBIT 2019: az ISO-n túli auditnézőpont

A NIST CSF 2.0 integrációs réteget biztosít a kiberbiztonsági irányításhoz. Magja, szervezeti profiljai és szintjei segítik a szervezeteket a jelenlegi és célállapot megértésében, a jogi és szabályozási követelményekkel összhangban álló intézkedések priorizálásában, valamint a kiberkockázat kommunikálásában.

CI/CD esetében a Clarysec gyakran készít szoftverszállítási folyamatprofilt. A jelenlegi profil rögzíti, hogyan működik ma a forráskód-kezelés, a runnerek, az artefaktum-aláírás és a telepítési jóváhagyások. A célprofil meghatározza a szabályozott működéshez szükséges állapotot. A hiányelemzésből megvalósítási ütemterv lesz.

A NIST GOVERN funkció különösen releváns. A GV.OC-03 előírja a jogi, szabályozási és szerződéses kiberbiztonsági követelmények megértését és kezelését. A GV.RM lefedi a kockázatvállalási hajlandóságot és a szabványosított kockázati priorizálást. A GV.RR vezetői elszámoltathatóságot, szerepköröket és erőforrásokat rendel hozzá. A GV.PO előírja a kiberbiztonsági kockázati szabályzatok létrehozását, betartatását, felülvizsgálatát és frissítését. A GV.OV a felügyeletet és a teljesítményértékelést fedi le.

Egy COBIT 2019 vagy ISACA szemléletű auditor gyakran kevésbé az artefaktum-aláírás kriptográfiai részleteit, inkább az irányítási kialakítást vizsgálja. Megkérdezi, meghatározott-e a felelősség, kontrollált-e a változásengedélyezés, kockázatkezeltek-e a harmadik fél szolgáltatások, a felügyelet biztosít-e bizonyosságot, jóváhagyottak-e a kivételek, és kap-e a vezetés érdemi jelentést.

Gyakori CI/CD auditmegállapítások és igazgatósági szintű mutatók

A legtöbb CI/CD auditmegállapítás előre látható. Az első a nem összekapcsolt bizonyíték. A csapat rendelkezik Git-naplókkal, CI/CD-naplókkal és telepítési naplókkal, de nincs egyetlen változásbejegyzés, amely összekapcsolná őket. A második a túlzott jogosultságú automatizálás, ahol egyetlen feladat képes éles titkos adatokat olvasni, artefaktumokat feltölteni, telepítéseket jóváhagyni és CI/CD-folyamatdefiníciókat módosítani. A harmadik a tartósan megosztott runner, amely projektek közötti szennyeződési kockázatot hoz létre, és kompromittálódás után megnehezíti a forenzikus hatókör meghatározását.

További gyakori hibák az aláíratlan vagy felülírt artefaktumok, az informális vizsgálati felülbírálások, a beszállítói vakfoltok és az adatvédelmi szivárgás a naplókban. Egy jó CI/CD-folyamat lehetővé teszi a kivételeket, de jóváhagyást, lejáratot, kockázattulajdonost és felülvizsgálatot követel meg.

A biztonsági vezetőknek kerülniük kell, hogy az igazgatóság felé csak a vizsgálati darabszámokat jelentsék. Ehelyett kiadásbizalmi mutatókat kell jelenteniük:

• Jóváhagyott változásbejegyzésekhez kapcsolt éles telepítések aránya.
• Aláírt és forráskód-commitokhoz visszakövethető éles artefaktumok aránya.
• Kivételekkel vagy sürgősségi jóváhagyásokkal végrehajtott telepítések száma.
• MFA-val és friss hozzáférési felülvizsgálattal rendelkező privilegizált CI/CD-felhasználók aránya.
• Aktív, hosszú élettartamú telepítési hitelesítő adatok száma.
• Megerősített vagy efemer runnereket használó kritikus szolgáltatások aránya.
• CI/CD-titkok incidens utáni visszavonásához vagy rotációjához szükséges átlagos idő.
• A szoftverszállítást támogató kritikus beszállítói függőségek száma.
• Auditmintába került kiadások bizonyíték-teljességi aránya.

Ezek a mutatók támogatják az ISO/IEC 27001:2022 szerinti vezetést, tervezést és működési kontrollt. Támogatják továbbá a NIS2 Article 20 szerinti vezetői felügyeletet és a DORA irányítási elvárásait.

Tegye auditálhatóvá a CI/CD-folyamatot az incidens előtt

A CI/CD-folyamatok biztonsági irányítása 2026-ban nem a mérnöki munka lassításáról szól. Arról szól, hogy a szoftverszállítás megbízható, reziliens és bizonyítható legyen. A legjobb programok az automatizálást a bizonyítékok gyorsítására használják, nem az irányítás megkerülésére.

Egy gyakorlati Clarysec bevezetés három intézkedéssel indul.

1. Használja a Zenith Blueprint Zenith Blueprint útmutatót, hogy a biztonságos DevOps-ot, a forráskód-hozzáférést, a környezetek szétválasztását és a változáskezelést beépítse az ISO/IEC 27001:2022 megvalósítási ütemtervébe.
2. Használja a Zenith Controls Zenith Controls útmutatót a CI/CD-kockázatok leképezésére a biztonságos SDLC, az IKT-ellátási lánc, a hozzáférés-szabályozás, a változáskezelés, a bizonyítékgyűjtés, a NIS2, a DORA, a GDPR, a NIST CSF 2.0 és a COBIT 2019 auditnézőpontjai között.
3. Vezesse be a Clarysec szabályzatsablonokat, beleértve a Biztonságos fejlesztési szabályzat, Változáskezelési szabályzat, Tesztadat- és tesztkörnyezet-kezelési szabályzat, Secure Development Policy-sme - SME, Logging and Monitoring Policy-sme - SME és Evidence Collection and Forensics Policy-sme - SME sablonokat, hogy meghatározza, ki hagyja jóvá a kiadásokat, hogyan követhetők vissza az artefaktumok, hogyan kontrollálják a runnereket, és milyen bizonyítékokat kell megőrizni.

Ha a következő auditminta azzal kezdődik, hogy „mutassák meg az éles kiadás nyomvonalát”, a csapatának percek alatt, nem hetek alatt kell tudnia válaszolni. Ez a különbség a DevOps automatizálás és az irányított szoftverszállítás között.

Töltse le a Clarysec szabályzati eszköztárát, vizsgálja felül CI/CD-folyamatát a Zenith Blueprint és a Zenith Controls alapján, vagy foglaljon Clarysec értékelést, hogy CI/CD-folyamata az audit miatti bizonytalanság forrásából a digitális reziliencia sarokkövévé váljon.