CI/CD-putkien tietoturvan hallinta vuoden 2026 auditointeja varten

On maanantaiaamu kello 08.17, ja kasvavan fintech-yhtiön tietoturvajohtaja saa viestin, jota jokainen tietoturvajohtaja pelkää:

“Tuotantokoonti näyttää puhtaalta, mutta artefaktin tiiviste ei täsmää lähdekoodin commitiin.”

Muutamassa minuutissa kehitystiimi vahvistaa, että julkaisu läpäisi yksikkötestit, käyttöönottotikettti on olemassa ja asiakasrajapinnan palvelu on vakaa. Putki kertoo kuitenkin toisen tarinan. Itse ylläpidettyä CI-runneria oli käytetty uudelleen eri projekteissa. Tilapäinen pilvitunnistetieto jäi aktiiviseksi aiottua pidemmäksi ajaksi. Artefaktirekisterissä näkyy allekirjoitettu konttikuva, mutta allekirjoitusavain oli käytettävissä samalta runnerilta, joka suoritti epäluotettavia koontiskriptejä.

Julkaisupäällikkö pystyy osoittamaan, että jotakin otettiin käyttöön. Organisaatio ei kuitenkaan pysty ainakaan riittävän nopeasti osoittamaan, mitä koottiin, kuka sen hyväksyi, oliko koontiympäristö puhdas ja säilyisikö näyttö auditoinnissa tai tietoturvapoikkeaman tutkinnassa.

Tämä ei ole enää vain DevOps-ongelma.

Vuonna 2026 CI/CD-putkien tietoturvan hallinta sijoittuu ohjelmistojen toimitusketjun turvallisuuden, toiminnallisen häiriönsietokyvyn, tietosuojan osoitusvelvollisuuden, tuoteturvallisuuden ja hallitustason kyberriskien valvonnan leikkauspisteeseen. NIS2 velvoittaa johtoa hyväksymään ja valvomaan kyberturvallisuuden riskienhallintatoimenpiteitä. DORA edellyttää finanssialan toimijoilta ICT-riskien, poikkeamien, testauksen ja kolmansien osapuolten riippuvuuksien hallintaa. GDPR edellyttää rekisterinpitäjiltä ja henkilötietojen käsittelijöiltä asianmukaisen turvallisuuden ja osoitusvelvollisuuden osoittamista henkilötietojen osalta. Cyber Resilience Act nostaa markkinoiden odotuksia digitaalisia elementtejä sisältävien tuotteiden turvallisuudesta, turvallisista päivityksistä ja haavoittuvuuksien käsittelystä. ISO/IEC 27001:2022 edellyttää ISMS:ää, joka muuttaa riskien käsittelyn hallituiksi ja näytöllä todennettaviksi toiminnoiksi.

Putkesta on tullut nykyaikaisen ohjelmistoluottamuksen auditointijälki.

Uusi vaatimustenmukaisuuskysymys: pystyttekö osoittamaan, mitä tuotantoon päätyi?

DevSecOps-ohjelmat keskittyivät vuosien ajan skannereiden lisäämiseen putkiin. Staattinen analyysi, riippuvuustarkistukset, salaisuuksien skannaus, konttiskannaus ja infrastruktuuri koodina -validointi yleistyivät. Näillä kontrolleilla on edelleen merkitystä, mutta ne eivät vastaa hallintakysymykseen, jonka auditoijat, valvontaviranomaiset, asiakkaat ja hallitukset nyt esittävät:

Pystyykö organisaatio osoittamaan, että jokainen tuotantokäyttöönotto perustui hyväksyttyyn lähdekoodiin, koottiin hallitussa ympäristössä, tuotti todennettavan artefaktin, läpäisi vaaditut tietoturvaportit, käytti hyväksyttyjä tunnistetietoja, noudatti muutoksenhallintaa ja tuotti säilytettävissä olevaa näyttöä?

Hyökkääjät tietävät, että koontijärjestelmät, pakettiriippuvuudet, kehittäjien tokenit, CI-runnerit, julkaisuautomaatio, artefaktirekisterit ja pilvikäyttöönoton roolit ovat arvokkaita kohteita. Vaarantunut putki voi ohittaa perinteiset puolustukset, koska se käyttää luotettua automaatiota haitallisen koodin viemiseen luotettuihin ympäristöihin.

Kypsä CI/CD-putkien tietoturvan hallintamalli tarvitsee siksi kuusi näytön peruspilaria.

Tässä Clarysecin lähestymistapa eroaa tarkistuslistapohjaisesta vaatimustenmukaisuudesta. Käsittelemme CI/CD-alustaa hallinnoituna liiketoimintaprosessina, emme pelkästään teknisenä työkaluna. Prosessin on kuuluttava ISMS:n soveltamisalaan, sille on tehtävä riskien arviointi, ja sitä on kontrolloitava, seurattava, auditoitava ja parannettava.

Sisällytä CI/CD ISO/IEC 27001:2022 -standardin mukaiseen ISMS:ään

ISO/IEC 27001:2022 alkaa toimintaympäristöstä, sidosryhmistä ja soveltamisalasta. Kohdat 4.1–4.4 edellyttävät, että organisaatiot ymmärtävät sisäiset ja ulkoiset tekijät, määrittävät sidosryhmien vaatimukset, tunnistavat lakisääteiset, sääntelyyn perustuvat ja sopimusperusteiset vaatimukset sekä määrittelevät ISMS:n soveltamisalan ottaen huomioon riippuvuudet muihin organisaatioihin.

SaaS-palveluntarjoajalle, fintech-yhtiölle, hallinnoidulle palveluntarjoajalle, ohjelmistotoimittajalle tai pilvinatiiville liiketoiminnalle CI/CD kuuluu lähes aina tähän soveltamisalaan, koska se vaikuttaa suoraan palvelun tuottamiseen, asiakastietoihin, tuotantoinfrastruktuuriin ja sopimusvelvoitteisiin.

Kohdat 5.1–5.3 asettavat johdolle vastuun ISMS:stä. Tämä on olennaista, koska nykyaikainen julkaisuautomaatio sijoittuu kehityksen, tietoturvan, pilvioperaatioiden, hankinnan, vaatimustenmukaisuuden ja tuotehallinnan väliin. Jos yhdelläkään johtajalla ei ole omistajuutta tuotantokäyttöönoton automaation riskinottohalukkuudesta, organisaatio päätyy yleensä hajanaiseen työkalukenttään ja epäyhtenäiseen näyttöön.

Kohdat 6.1.1–6.1.3 muodostavat suunnittelun perustan. Organisaation on arvioitava luottamuksellisuuteen, eheyteen ja saatavuuteen kohdistuvat riskit, tunnistettava riskinomistajat, verrattava riskejä kriteereihin, valittava riskien käsittelytavat, verrattava valittuja kontrolleja liite A:han, laadittava soveltuvuuslausunto sekä hankittava hyväksyntä riskienkäsittelysuunnitelmalle ja jäännösriskille.

CI/CD-riskien arvioinnissa ei pidä tyytyä toteamukseen “ohjelmistotoimitusketjun riski”. Arvioinnissa on nimettävä realistiset skenaariot:

• Haitallinen koontiskripti siirtää allekirjoitusavaimet luvattomasti jaetulta runnerilta.
• Kehittäjä ohittaa haarasuojauksen ja ottaa katselmoimattoman koodin käyttöön.
• Vaarantunut kolmannen osapuolen toiminto muuttaa artefaktia koonnin aikana.
• Staging-ympäristön tunnistetieto antaa pääsyn tuotantoon.
• Käyttöönotto tapahtuu ilman siihen linkitettyä muutospyyntöä.
• Poikkeaman rekonstruointiin tarvittavat putkilokit ylikirjoitetaan seitsemän päivän jälkeen.
• Riippuvuuden myrkyttämiseen liittyvä poikkeama päätyy esituotantoon tai tuotantoon.

Kohta 8.1 edellyttää tämän jälkeen ISMS-prosessien suunniteltua ja hallittua toimintaa, dokumentoitua näyttöä, suunniteltujen muutosten hallintaa, tahattomien muutosten katselmointia sekä ISMS:n kannalta olennaisten ulkoisesti tuotettujen prosessien, tuotteiden tai palvelujen hallintaa. Jos putki muuttaa tuotantoa, sen on tuotettava näyttöä hallitusta toiminnasta.

Clarysecin kontrollimalli turvalliseen ohjelmistotoimitukseen

Clarysec yhdistää politiikat, kontrollit ja auditointinäytön. Zenith Blueprint: auditoijan 30 vaiheen tiekartta Zenith Blueprint sijoittaa turvallisen DevOpsin ja turvallisen kehittämisen riskienhallintavaiheeseen, vaiheeseen 14. Sen mukaan organisaatioiden on suojattava CI/CD-työkalut, varmistettava, että vain valtuutettu henkilöstö voi käynnistää käyttöönottoja, käytettävä MFA:ta putken käyttöoikeuksissa, suojattava koontiartefaktien eheys sekä lokitettava ja valvottava CI/CD-toimia.

“DevOps-putken kontrollit: CI/CD-työkalut on suojattava – vain valtuutettu henkilöstö saa käynnistää käyttöönottoja; putken käyttöoikeuksissa on käytettävä MFA:ta; koontiartefaktien eheys on suojattava. CI/CD-toimet on kirjattava lokiin ja niitä on valvottava.”

Ohjeesta tulee toimiva, kun se muunnetaan politiikkalausekkeiksi ja näyttövaatimuksiksi.

P24 Turvallisen kehityksen politiikka Turvallisen kehityksen politiikka toteaa:

“Koontiartefaktit on allekirjoitettava ja niiden on oltava jäljitettävissä lähdekoodin committeihin.”

Tämä on yksi vahvimmista kontrolleista CI/CD-hallintaohjelmassa. Se kertoo kehitystiimille, että tuotantoartefaktilla on oltava todennettava yhteys takaisin lähdekoodin versionhallintaan. Se kertoo myös auditoijille, mitä testata: valitaan tuotantojulkaisu, tarkastetaan artefaktin allekirjoitus, validoidaan commit-viite, katselmoidaan pull request -hyväksyntä ja vahvistetaan putken koontitallenne.

Sama politiikka toteaa:

“Kaikkia kehitystoimia on seurattava hyväksyttyjen versionhallintajärjestelmien kautta siten, että pääsynhallinta, auditointijäljet ja haarasuojaukset on toteutettu.”

Tämä siirtää hallinnan ylävirtaan. Jos lähdekooditietovarastoja ei suojata, koonnin alkuperätiedot ovat heikkoja. Jos haarasuojaukset voidaan ohittaa, putki voi tunnollisesti koota hyväksymätöntä koodia. Jos auditointijäljet on poistettu käytöstä, poikkeaman rekonstruointi perustuu muistiin ja kuvakaappauksiin näytön sijaan.

Pienemmille organisaatioille Turvallisen kehityksen politiikka pk-yrityksille Turvallisen kehityksen politiikka pk-yrityksille sisältää käytännöllisen vähimmäisvaatimuksen:

“Koodiversion, käyttöönoton päivämäärän ja hyväksyjän seuranta”

Tämä yksinkertainen käyttöönottojen kirjanpito on vahva lähtökohta. Monet pk-yritykset eivät tarvitse raskasta julkaisujen hallintaa ensimmäisenä päivänä, mutta niiden on tiedettävä, mikä versio vietiin tuotantoon, milloin ja kuka sen hyväksyi.

Pk-yrityksille tarkoitettu politiikka toteaa myös:

“Pääsyä tuotantokäyttöönoton työkaluihin tai järjestelmiin on hallittava, lokitettava ja katselmoitava säännöllisesti toimitusjohtajan tai IT-palveluntarjoajan toimesta.”

Tämä on hallintavaihe, jonka monet pienemmät tiimit jättävät väliin. CI/CD-alusta, jolla on tuotannon pilvitunnistetiedot, on etuoikeutettu pääsypolku tuotantoympäristöön.

Kolme ISO/IEC 27002:2022 -kontrollialuetta turvallisen CI/CD:n taustalla

Zenith Controls: vaatimustenmukaisuuksien välinen opas Zenith Controls on Clarysecin kompassi virallisten standardien ja viitekehysten kytkemiseen käytännön kontrollisuhteiksi. CI/CD-putkien tietoturvan hallinnassa kolme ISO/IEC 27002:2022 -kontrollialuetta on keskeisiä.

Zenith Controls kuvaa kontrollin 5.21 ennaltaehkäisevänä kontrollina, joka tukee luottamuksellisuutta, eheyttä ja saatavuutta ja jossa toimittajasuhteiden turvallisuus on keskeinen operatiivinen kyvykkyys. Tämä sopii CI/CD:hen, koska nykyaikaiset putket ovat riippuvaisia ulkoisista palveluista: lähdekoodin versionhallinta-alustoista, isännöidyistä runnereista, konttirekistereistä, avoimen lähdekoodin pakettitietovarastoista, kolmannen osapuolen GitHub-toiminnoista, skannaustyökaluista, pilvikäyttöönoton ohjelmointirajapinnoista ja ulkoistetuista kehittäjistä.

5.21-kartoituksessa Zenith Controls kytkee ICT-toimitusketjun turvallisuuden kontrolleihin 5.19 Tietoturvallisuus toimittajasuhteissa, 5.20 Tietoturvallisuuden huomioiminen toimittajasopimuksissa, 8.27 Turvallinen järjestelmäarkkitehtuuri ja suunnitteluperiaatteet, 8.28 Turvallinen ohjelmointi, 8.29 Tietoturvatestaus kehittämisessä ja hyväksynnässä, 5.15 Pääsynhallinta, 5.28 Todistusaineiston kerääminen, 8.25 Turvallisen kehityksen elinkaari ja 8.30 Ulkoistettu kehittäminen.

Kontrollin 8.25 osalta Zenith Controls tunnistaa turvallisen kehityksen elinkaaren ennaltaehkäiseväksi kontrolliksi, joka suojaa luottamuksellisuutta, eheyttä ja saatavuutta. Se yhdistää tietoturvavaatimukset, arkkitehtuurin, ohjelmoinnin, testauksen, ulkoistetun kehittämisen ja 8.31:n mukaisen kehitys-, testi- ja tuotantoympäristöjen eriyttämisen.

Kontrollin 8.32 osalta Zenith Controls määrittää muutoksenhallinnan sillaksi kehityksen ja tuotannon välille. Se liittyy kontrolleihin 8.9 Konfiguraationhallinta, 8.8 Teknisten haavoittuvuuksien hallinta, turvallisen järjestelmäkehityksen elinkaari ja tietoturvaloukkausten hallinta. Siksi käyttöönottoautomaatio ei voi olla muutoksenhallintakäytännön ulkopuolella. Se on mekanismi, jonka kautta tuotantomuutos tapahtuu.

Koonnin alkuperätiedot: julkaisutarina, jota auditoija voi seurata

Koonnin alkuperätiedoilla tarkoitetaan kykyä vastata näytön avulla siihen, mistä ohjelmistoartefakti tuli ja miten se tuotettiin. Vahva alkuperätietue kertoo julkaisun tarinan:

1. Mitä lähdekooditietovarastoa ja committia käytettiin.
2. Mikä haara tai tagi käynnisti koonnin.
3. Mikä pull request, katselmoija ja hyväksyntä siihen liittyivät.
4. Mikä putkimääritys suoritettiin.
5. Mikä runner suoritti työn.
6. Mitä riippuvuuksia ja peruskuvia käytettiin.
7. Mitkä testit ja tietoturvaportit suoritettiin.
8. Mikä artefakti tuotettiin.
9. Mikä allekirjoitus tai tiiviste luotiin.
10. Mikä käyttöönotto käytti artefaktia.

P05 Muutoksenhallintapolitiikka Muutoksenhallintapolitiikka tarjoaa hallintakytkennän. Siinä todetaan:

“Työkalupohjaisten muutosten on edelleen noudatettava tätä politiikkaa ja oltava jäljitettävissä vastaavaan muutospyynnön tunnisteeseen.”

Tämä vastaa yleiseen väitteeseen, jonka mukaan automatisoidut käyttöönotot eivät tarvitse muutostikettejä. Automaatio ei poista muutoksenhallintaa. Se muuttaa tapaa, jolla näyttö syntyy.

Sama politiikka toteaa:

“Kaikki muutospyynnöt, katselmoinnit, hyväksynnät ja niitä tukeva näyttö on tallennettava keskitettyyn muutoksenhallintajärjestelmään.”

Käytännössä muutoksenhallintajärjestelmän tulee olla hakemisto, ei kaatopaikka. Tiketin tulee viitata lähdekooditietovarastoon, koontoajoon, artefaktin allekirjoitukseen, käyttöönoton lokiin ja palautussuunnitelmaan. Yksityiskohtainen näyttö voi jäädä kehitystyökaluihin, jos säilytys, pääsynhallinta ja siirrettävyys on määritelty.

Runnerien koventaminen: usein sivuutettu tuotantokontrolli

CI/CD-runnereita käsitellään usein kertakäyttöisenä infrastruktuurina, mutta ne ovat korkean riskin suoritusympäristöjä. Runnerilla voi olla pääsy lähdekoodiin, salaisuuksiin, koontivälimuisteihin, pakettitietovarastoihin, allekirjoitusavaimiin, artefaktirekistereihin ja pilvikäyttöönoton rooleihin. Jos runner on pysyvä, jaettu, ylioikeutettu tai heikosti valvottu, siitä tulee etuoikeutettu pivot-piste.

Turvallinen hallintakanta on yksinkertainen: tuotantokoodia koostavat tai käyttöönottoja tekevät runnerit on kovennettava kuten tuotantoinfrastruktuuri.

Testidataa ja testiympäristöjä koskeva politiikka Testidataa ja testiympäristöjä koskeva politiikka toteaa:

“Integraatiossa CI/CD-putkiin on toteutettava ympäristöjen ja todentamistietojen eriyttäminen.”

Runner, joka voi ottaa käyttöön sekä staging- että tuotantoympäristöön samalla tunnistetietomallilla, rikkoo ympäristöjen eriyttämisen periaatetta, vaikka infrastruktuuri olisi loogisesti erotettu. Clarysec suosittelee tyypillisesti erillisiä käyttöönottoidentiteettejä ympäristöittäin, erillisiä tuotannon hyväksyntäportteja sekä nimenomaisia kontrolleja, jotka estävät alemman ympäristön töitä käyttämästä tuotantosalaisuuksia.

Zenith Blueprintin Controls in Action -vaihe, vaihe 21, vahvistaa tämän kehitys-, testi- ja tuotantoympäristöjen eriyttämisen kautta:

“Jos CI/CD on käytössä, varmista, että käyttöönoton promootio ympäristöjen välillä on hallittua ja edellyttää katselmointia tai hyväksyntää. Dokumentoi tämä ympäristöjen hallintamenettelyssä ja liitä tueksi kuvakaappaukset tai konsoliviennit.”

Todellisessa auditoinnissa pelkkä kaavio ei riitä auditoijalle. Auditoijan on nähtävä konsoliviennit, jotka osoittavat ympäristökohtaiset tunnistetiedot, suojatut käyttöönottoympäristöt, hyväksyntäportit ja lokit, jotka todistavat promootion olleen hallittu.

Käyttöönottonäyttö: vaatimustenmukaisuusartefakti, joka on näkyvillä mutta usein huomaamatta

Kypsimmät DevSecOps-tiimit eivät käsittele näytön keräämistä neljännesvuosittaisena paniikkina. Ne suunnittelevat putket tuottamaan näytön automaattisesti.

Lokitus- ja valvontapolitiikka pk-yrityksille Lokitus- ja valvontapolitiikka pk-yrityksille tunnistaa olennaisiksi lokitapahtumiksi:

“Järjestelmälokit: konfiguraatiomuutokset, hallinnolliset toimet, ohjelmistoasennukset, paikkaustoiminta”

CI/CD-järjestelmät tuottavat kaikki neljä kategoriaa. Putken konfiguraatiomuutokset vaikuttavat siihen, miten ohjelmisto koostetaan. Hallinnolliset toimet muuttavat sitä, kuka voi hyväksyä käyttöönoton tai tehdä sen. Ohjelmistoasennuksia tapahtuu koontikuvissa ja käyttöönoton kohteissa. Paikkaustoiminta voi kulkea automatisoitujen julkaisuprosessien kautta. Nämä tapahtumat on lokitettava, säilytettävä ja katselmoitava riskiperusteisesti.

Tutkintavalmiuden kannalta P31S Todisteiden keräämisen ja forensiikan politiikka pk-yrityksille Todisteiden keräämisen ja forensiikan politiikka pk-yrityksille toteaa:

“Kuvakaappaukset, viedyt lokit ja tiedostojen tiivisteet on säilytettävä hallussapitoketjutiedoston rinnalla.”

Tämä on erityisen tärkeää epäillyn putken vaarantumisen jälkeen. Pelkät kuvakaappaukset ovat heikkoa näyttöä. Lokit ilman tiivisteitä voidaan kyseenalaistaa. Hallussapitoketjutiedosto ilman lähdeviitteitä on puutteellinen.

Puolustettavissa olevan tuotantokäyttöönoton tallenteen tulee sisältää seuraavat osat.

Tämä paketti muuttaa CI/CD:n teknisten vaiheiden sarjasta hallinnan, kontrollin ja huolellisuuden tarinaksi.

CI/CD-hallinnan kytkeminen NIS2:een, DORA:an, GDPR:ään ja CRA:han

NIS2 koskee monia keskeisiä ja tärkeitä toimijoita, mukaan lukien digitaalinen infrastruktuuri, ICT-palvelunhallinta ja digitaalisten palvelujen tarjoajat, kun kriteerit täyttyvät. Article 20 on erityisen olennainen, koska se luo johdon tason kyberturvallisuusvelvoitteita. Johtoelinten on hyväksyttävä kyberturvallisuuden riskienhallintatoimenpiteet, valvottava niiden toteutusta ja saatava koulutusta.

Article 21 muodostaa riskienhallinnan perustason. Se edellyttää asianmukaisia ja oikeasuhteisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä, jotka kattavat riskianalyysin, politiikat, poikkeamien käsittelyn, liiketoiminnan jatkuvuuden, toimitusketjun turvallisuuden, turvallisen hankinnan, kehittämisen ja ylläpidon, haavoittuvuuksien käsittelyn, vaikuttavuuden arvioinnin, kyberhygienian, kryptografian, HR-turvallisuuden, pääsynhallinnan, omaisuudenhallinnan ja tarvittaessa MFA:n.

Article 23 lisää vaiheistetun merkittävien poikkeamien raportoinnin, mukaan lukien ennakkovaroitus 24 tunnin kuluessa tiedoksisaannista, poikkeamailmoitus 72 tunnin kuluessa ja loppuraportti viimeistään kuukauden kuluttua poikkeamailmoituksesta. Jos CI/CD:n vaarantuminen voisi aiheuttaa vakavan toiminnallisen häiriön, taloudellisen menetyksen tai olennaista vahinkoa muille, poikkeamien luokitteluprosessin on oltava valmis ennen poikkeamaa.

Finanssialan toimijoihin DORA:a sovelletaan 17. tammikuuta 2025 alkaen, ja se kattaa ICT-riskien hallinnan, poikkeamaraportoinnin, häiriönsietokyvyn testauksen, tietojenvaihdon, ICT-kolmansien osapuolten riskienhallinnan ja sopimusvaatimukset. Article 5 edellyttää sisäistä hallinto- ja kontrollikehystä ICT-riskille sekä johtoelimen vastuuta. Article 6 edellyttää dokumentoitua ICT-riskienhallinnan viitekehystä, joka on integroitu yleiseen riskienhallintaan.

Articles 8–14 kytkeytyvät suoraan CI/CD-putkien hallintaan. Finanssialan toimijoiden on tunnistettava ja luokiteltava ICT-tuetut liiketoimintatoiminnot, omaisuuserät, riippuvuudet, uhat ja haavoittuvuudet. Niiden on suojattava ICT-järjestelmiä politiikoilla, pääsynhallinnalla, vahvalla tunnistautumisella, kryptografisten avainten suojauksella, hallitulla ICT-muutoksenhallinnalla, paikkauksella ja segmentoinnilla. Niiden on havaittava poikkeamat, reagoitava niihin, palauduttava niistä ja opittava poikkeamista.

Articles 28–30 ovat yhtä tärkeitä, koska CI/CD-alustat, lähdekoodin versionhallinnan tarjoajat, artefaktirekisterit, pilvikoontijärjestelmät ja ulkoistetut kehittäjät voivat olla ICT-kolmansien osapuolten riippuvuuksia. DORA odottaa huolellisuutta, sopimusperusteisia suojatoimia, keskittymäriskin arviointia, auditointi- ja tarkastusoikeuksia, päättämisperusteita, exit-strategioita ja palvelutasolausekkeita.

GDPR lisää osoitusvelvollisuuden näkökulman. Article 5 edellyttää, että henkilötietoja käsitellään lainmukaisesti, kohtuullisesti, läpinäkyvästi, määriteltyihin tarkoituksiin, minimoidusti, täsmällisesti, vain tarvittavan ajan säilyttäen ja suojaten luvattomalta tai lainvastaiselta käsittelyltä sekä vahingossa tapahtuvalta häviämiseltä, tuhoutumiselta tai vahingoittumiselta. Article 5(2) edellyttää, että rekisterinpitäjä osoittaa vaatimustenmukaisuuden.

CI/CD-putket ovat GDPR:n kannalta merkityksellisiä, koska kehittäjät voivat käyttää tuotantodataa testiympäristöissä, putkilokit voivat paljastaa henkilötietoja tai tokeneita, julkaisut voivat muuttaa käsittelylogiikkaa ja vaarantuneet artefaktit voivat aiheuttaa henkilötietojen tietoturvaloukkauksia. Kun ohjelmistomuutokset vaikuttavat tietosuojakontrolleihin, muutostallenteen on sisällettävä tietosuojavaikutus. Kun putkipoikkeama aiheuttaa luvattoman pääsyn henkilötietoihin, tietoturvaloukkauksen arviointi on kytkettävä poikkeamien käsittelyyn.

CRA:n odotukset lisäävät tuoteturvallisuuden ja turvallisten päivitysten näyttöä. Valmistajilta ja ohjelmistotoimittajilta, jotka saattavat digitaalisia elementtejä sisältäviä tuotteita EU:n markkinoille, asiakkaat odottavat yhä useammin tuoteturvallisuustiedostoja, haavoittuvuuksien käsittelynäyttöä, turvallisia päivityskontrolleja ja julkaisun eheyttä. CI/CD-hallinta tuottaa suuren osan tästä näytöstä lähdekoodin jäljitettävyyden, allekirjoitettujen artefaktien, haavoittuvuusskannausten tulosten, julkaisutiedotteiden, tietoturvakorjausten ja päivitysten jakelutallenteiden kautta.

NIST CSF 2.0 ja COBIT 2019: auditointinäkökulma ISO:n ulkopuolella

NIST CSF 2.0 tarjoaa integraatiokerroksen kyberturvallisuuden hallintaan. Sen Core, Organizational Profiles ja Tiers auttavat organisaatioita ymmärtämään nykyisen ja tavoitellun tilan, priorisoimaan oikeudellisiin ja sääntelyvaatimuksiin sovitetut toimet sekä viestimään kyberriskeistä.

CI/CD:tä varten Clarysec luo usein Software Delivery Pipeline Profile -profiilin. Current Profile kuvaa, miten lähdekoodin versionhallinta, runnerit, artefaktien allekirjoittaminen ja käyttöönottojen hyväksynnät toimivat nykyisin. Target Profile määrittää vaaditun tilan säännellylle toiminnalle. Puuteanalyysin suunnitelmasta tulee toteutuksen tiekartta.

NISTin GOVERN-toiminto on erityisen olennainen. GV.OC-03 edellyttää, että oikeudelliset, sääntelyyn perustuvat ja sopimusperusteiset kyberturvallisuusvaatimukset ymmärretään ja niitä hallitaan. GV.RM kattaa riskinottohalukkuuden ja yhdenmukaisen riskien priorisoinnin. GV.RR osoittaa johdon vastuun, roolit ja resurssit. GV.PO edellyttää, että kyberturvallisuusriskien politiikat laaditaan, otetaan käyttöön, katselmoidaan ja päivitetään. GV.OV kattaa valvonnan ja suorituskyvyn arvioinnin.

COBIT 2019- tai ISACA-tyyppinen auditoija tarkastelee usein vähemmän artefaktin allekirjoittamisen kryptografisia yksityiskohtia ja enemmän hallintorakennetta. Hän kysyy, onko omistajuus määritelty, onko muutosten käyttöönoton mahdollistaminen hallittua, hallitaanko kolmannen osapuolen palveluja riskiperusteisesti, tuottaako valvonta varmuutta, hyväksytäänkö poikkeukset ja saako johto merkityksellistä raportointia.

Yleiset CI/CD-auditointihavainnot ja hallitustason mittarit

Useimmat CI/CD-auditointihavainnot ovat ennakoitavissa. Ensimmäinen on linkittämätön näyttö. Tiimillä on Git-lokit, putkilokit ja käyttöönoton lokit, mutta mikään yksittäinen muutostallenne ei yhdistä niitä. Toinen on ylioikeutettu automaatio, jossa yksi työ voi lukea tuotantosalaisuuksia, työntää artefakteja, hyväksyä käyttöönottoja ja muuttaa putkimäärityksiä. Kolmas on pysyvät jaetut runnerit, jotka aiheuttavat kontaminaatioriskin projektien välillä ja vaikeuttavat forensista rajausta vaarantumisen jälkeen.

Muita yleisiä puutteita ovat allekirjoittamattomat tai ylikirjoitetut artefaktit, epämuodolliset skannausohitukset, toimittajanäkymän puuttuminen ja tietosuojavuodot lokeissa. Hyvä putki sallii poikkeukset, mutta edellyttää hyväksyntää, voimassaolon päättymistä, riskinomistajuutta ja katselmointia.

Tietoturvajohtajien tulee välttää pelkkien skannerimäärien raportointia hallitukselle. Sen sijaan kannattaa raportoida julkaisuluottamuksen mittareita:

• Prosenttiosuus tuotantokäyttöönotosta, jotka on linkitetty hyväksyttyihin muutostallenteisiin.
• Prosenttiosuus tuotantoartefakteista, jotka on allekirjoitettu ja jäljitettävissä lähdekoodin committeihin.
• Poikkeuksia tai hätähyväksyntöjä käyttävien käyttöönottojen määrä.
• Prosenttiosuus etuoikeutetuista CI/CD-käyttäjistä, joilla on MFA ja tuore käyttöoikeuskatselmointi.
• Aktiivisten pitkäikäisten käyttöönoton tunnistetietojen määrä.
• Prosenttiosuus kriittisistä palveluista, jotka käyttävät kovennettuja tai kertakäyttöisiä runnereita.
• Keskimääräinen aika putken salaisuuksien peruuttamiseen tai kiertoon poikkeaman jälkeen.
• Ohjelmistotoimitusta tukevien kriittisten toimittajariippuvuuksien määrä.
• Näytön täydellisyysaste auditointiotteeseen valituissa julkaisuissa.

Nämä mittarit tukevat ISO/IEC 27001:2022 -standardin johtamista, suunnittelua ja operatiivista hallintaa. Ne tukevat myös NIS2 Article 20:n mukaista johdon valvontaa ja DORA:n hallintaodotuksia.

Tee putkesta auditoitava ennen poikkeamaa

CI/CD-putkien tietoturvan hallinta vuonna 2026 ei tarkoita kehityksen hidastamista. Sen tarkoitus on tehdä ohjelmistotoimituksesta luotettavaa, häiriönsietokykyistä ja todennettavaa. Parhaat ohjelmat käyttävät automaatiota näytön nopeuttamiseen, eivät hallinnan ohittamiseen.

Käytännön Clarysec-toteutus alkaa kolmesta toimenpiteestä.

1. Käytä Zenith Blueprintiä Zenith Blueprint sijoittaaksesi turvallisen DevOpsin, lähdekoodin käyttöoikeudet, ympäristöjen eriyttämisen ja muutoksenhallinnan ISO/IEC 27001:2022 -toteutuksen tiekarttaan.
2. Käytä Zenith Controlsia Zenith Controls kartoittaaksesi CI/CD-riskit turvallisen järjestelmäkehityksen elinkaaren, ICT-toimitusketjun, pääsynhallinnan, muutoksenhallinnan, todistusaineiston keräämisen, NIS2:n, DORA:n, GDPR:n, NIST CSF 2.0:n ja COBIT 2019 -auditointinäkökulmien yli.
3. Ota käyttöön Clarysecin politiikkamallit, mukaan lukien Turvallisen kehityksen politiikka, Muutoksenhallintapolitiikka, Testidataa ja testiympäristöjä koskeva politiikka, Turvallisen kehityksen politiikka pk-yrityksille, Lokitus- ja valvontapolitiikka pk-yrityksille ja Todisteiden keräämisen ja forensiikan politiikka pk-yrityksille, määrittääksesi, kuka hyväksyy julkaisut, miten artefaktit jäljitetään, miten runnereita hallitaan ja mitä näyttöä on säilytettävä.

Jos seuraava auditointiotos alkaa pyynnöllä “näyttäkää tuotantojulkaisun jälki”, tiimin tulee pystyä vastaamaan minuuteissa, ei viikoissa. Tämä erottaa DevOps-automaation hallinnoidusta ohjelmistotoimituksesta.

Lataa Clarysecin politiikkatyökalupaketti, arvioi CI/CD-putkesi Zenith Blueprintin ja Zenith Controlsin avulla tai varaa Clarysec-arviointi, jotta putkesi muuttuu auditointihuolen lähteestä digitaalisen häiriönsietokyvyn kulmakiveksi.