Governance voor beveiligde CI/CD-pipelines bij audits in 2026

Het is 08:17 op maandagochtend wanneer de CISO van een snelgroeiende fintech het bericht ontvangt waar iedere beveiligingsverantwoordelijke voor vreest:

“De productiebuild ziet er schoon uit, maar de artefacthash komt niet overeen met de broncommit.”

Binnen enkele minuten bevestigt engineering dat de release de unit tests heeft doorstaan, het uitrolticket bestaat en de klantgerichte dienst stabiel is. Maar de pipeline vertelt een ander verhaal. Een self-hosted CI-runner is opnieuw gebruikt voor meerdere projecten. Een tijdelijke cloudreferentie bleef langer actief dan bedoeld. Het artefactregister toont een ondertekende containerimage, maar de ondertekeningssleutel was toegankelijk vanaf dezelfde runner die niet-vertrouwde buildscripts uitvoerde.

De releasemanager kan aantonen dat er iets is uitgerold. Wat de organisatie niet kan aantonen, althans niet snel genoeg, is wat er is gebouwd, wie het heeft goedgekeurd, of de buildomgeving schoon was en of het bewijsmateriaal standhoudt bij een audit of incidentonderzoek.

Dat is niet langer alleen een DevOps-probleem.

In 2026 bevindt governance voor CI/CD-pipelinebeveiliging zich op het snijvlak van beveiliging van de softwaretoeleveringsketen, operationele weerbaarheid, privacyverantwoording, productbeveiliging en toezicht op cyberrisico’s op bestuursniveau. NIS2 verplicht bestuursorganen om maatregelen voor cyberbeveiligingsrisicobeheer goed te keuren en daarop toezicht te houden. DORA vereist dat financiële entiteiten ICT-risico’s, incidenten, testen en afhankelijkheden van derden besturen. GDPR vereist dat verwerkingsverantwoordelijken en verwerkers passende beveiliging en verantwoordingsplicht voor persoonsgegevens aantonen. De Cyber Resilience Act verhoogt de marktverwachtingen voor veilige producten met digitale elementen, veilige updates en kwetsbaarhedenbeheer. ISO/IEC 27001:2022 vereist een ISMS dat risicobehandeling omzet in beheerste, met bewijsmateriaal onderbouwde bedrijfsvoering.

De pipeline is de audittrail geworden voor modern vertrouwen in software.

De nieuwe compliancevraag: kunt u aantonen wat productie heeft bereikt?

Jarenlang richtten DevSecOps-programma’s zich op het toevoegen van scanners aan pipelines. Statische analyse, afhankelijkheidscontroles, secret scanning, containerscanning en validatie van infrastructure-as-code werden gangbaar. Die beheersmaatregelen blijven relevant, maar ze beantwoorden niet de governancevraag die auditors, toezichthouders, klanten en bestuurders nu stellen:

Kan de organisatie aantonen dat elke uitrol naar productie afkomstig was uit goedgekeurde broncode, in een beheerste omgeving is gebouwd, een verifieerbaar artefact heeft opgeleverd, de vereiste beveiligingspoorten heeft doorlopen, goedgekeurde referenties heeft gebruikt, wijzigingsbeheer heeft gevolgd en bewijsmateriaal heeft gegenereerd dat kan worden bewaard?

Aanvallers weten dat buildsystemen, pakketafhankelijkheden, ontwikkelaarstokens, CI-runners, releaseautomatisering, artefactregisters en cloudrollen voor uitrol waardevolle doelwitten zijn. Een gecompromitteerde pipeline kan traditionele verdedigingsmechanismen omzeilen omdat zij vertrouwde automatisering gebruikt om kwaadaardige code naar vertrouwde omgevingen te brengen.

Een volwassen governancemodel voor CI/CD-pipelinebeveiliging heeft daarom zes bewijspijlers nodig.

Hierin verschilt de aanpak van Clarysec van checklistmatige naleving. Wij behandelen het CI/CD-platform als een bestuurd bedrijfsproces, niet alleen als een technische tool. Dat proces moet in het ISMS worden afgebakend, op risico worden beoordeeld, worden beheerst, gemonitord, geaudit en verbeterd.

Breng CI/CD onder in het ISO/IEC 27001:2022-ISMS

ISO/IEC 27001:2022 begint met context, belanghebbenden en toepassingsgebied. Clausules 4.1 tot en met 4.4 vereisen dat organisaties interne en externe kwesties begrijpen, eisen van belanghebbenden bepalen, wettelijke, regelgevende en contractuele eisen identificeren, en het ISMS-toepassingsgebied definiëren met inachtneming van afhankelijkheden met andere organisaties.

Voor een SaaS-aanbieder, fintech, managed service provider, softwareleverancier of cloud-native organisatie valt CI/CD vrijwel altijd binnen dat toepassingsgebied, omdat het rechtstreeks invloed heeft op dienstverlening, klantgegevens, productie-infrastructuur en contractuele verplichtingen.

Clausules 5.1 tot en met 5.3 maken het leiderschap verantwoordelijk voor het ISMS. Dit is belangrijk omdat moderne releaseautomatisering zich bevindt tussen engineering, beveiliging, cloudoperaties, inkoop, compliance en productmanagement. Als geen enkele leidinggevende eigenaar is van de risicobereidheid voor automatisering van productie-uitrol, eindigt de organisatie meestal met gefragmenteerde tooling en inconsistent bewijsmateriaal.

Clausules 6.1.1 tot en met 6.1.3 vormen de planningsbasis. De organisatie moet risico’s voor vertrouwelijkheid, integriteit en beschikbaarheid beoordelen, risico-eigenaren identificeren, risico’s vergelijken met criteria, behandelingen selecteren, gekozen beheersmaatregelen vergelijken met Annex A, een Verklaring van Toepasselijkheid opstellen en goedkeuring verkrijgen voor het risicobehandelingsplan en het restrisico.

Een CI/CD-risicobeoordeling mag niet slechts spreken van “risico in de softwaretoeleveringsketen”. Zij moet realistische scenario’s benoemen:

• Een kwaadaardig buildscript exfiltreert ondertekeningssleutels vanaf een gedeelde runner.
• Een ontwikkelaar omzeilt branch-protectionregels en rolt niet-beoordeelde code uit.
• Een gecompromitteerde actie van een derde partij wijzigt een artefact tijdens de build.
• Een stagingreferentie verleent productietoegang.
• Een uitrol vindt plaats zonder gekoppeld wijzigingsverzoek.
• Pipelinelogboeken die nodig zijn voor incidentreconstructie worden na zeven dagen overschreven.
• Een incident met dependency poisoning bereikt pre-productie of productie.

Clausule 8.1 vereist vervolgens geplande en beheerste uitvoering van ISMS-processen, gedocumenteerd bewijsmateriaal, beheersing van geplande wijzigingen, beoordeling van onbedoelde wijzigingen en beheersing van extern geleverde processen, producten of diensten die relevant zijn voor het ISMS. Als de pipeline productie wijzigt, moet zij bewijsmateriaal van beheerste uitvoering opleveren.

Het Clarysec-beheersmodel voor veilige softwarelevering

Clarysec verbindt beleid, beheersmaatregelen en auditbewijsmateriaal. De Zenith Blueprint: een 30-stappenroadmap voor auditors Zenith Blueprint plaatst veilige DevOps en veilige ontwikkeling in de fase Risicobeheer, stap 14. Daarin staat dat organisaties CI/CD-tools moeten beveiligen, ervoor moeten zorgen dat alleen geautoriseerd personeel uitrollen kan starten, MFA voor pipelinetoegang moeten gebruiken, de integriteit van buildartefacten moeten beschermen en CI/CD-acties moeten loggen en monitoren.

“Beheersmaatregelen voor DevOps-pipelines: CI/CD-tools moeten worden beveiligd – alleen geautoriseerd personeel mag uitrollen starten; gebruik MFA voor pipelinetoegang; bescherm de integriteit van buildartefacten. Log en monitor CI/CD-acties.”

Die richtlijn wordt uitvoerbaar wanneer zij wordt vertaald naar beleidsclausules en eisen voor bewijsmateriaal.

Het P24 Beleid voor veilige ontwikkeling Beleid voor veilige ontwikkeling bepaalt:

“Buildartefacten moeten worden ondertekend en herleidbaar zijn tot broncommits.”

Dit is een van de sterkste beheersmaatregelen in een CI/CD-governanceprogramma. Het maakt voor engineering duidelijk dat een productieartefact een verifieerbare herkomstlijn terug naar versiebeheer moet hebben. Het maakt voor auditors ook duidelijk wat zij moeten testen: selecteer een productierelease, inspecteer de artefacthandtekening, valideer de commitreferentie, beoordeel de goedkeuring van de pull request en bevestig de pipelinebuildregistratie.

Hetzelfde beleid bepaalt:

“Alle ontwikkelactiviteiten moeten worden gevolgd via goedgekeurde versiebeheersystemen met afgedwongen toegangscontrole, audittrails en branch-protectionregels.”

Dit verplaatst governance stroomopwaarts. Als broncoderepositories niet worden beschermd, is buildprovenance zwak. Als branch-protectionregels kunnen worden omzeild, kan de pipeline op correcte wijze niet-goedgekeurde code bouwen. Als audittrails zijn uitgeschakeld, is incidentreconstructie afhankelijk van geheugen en schermopnamen in plaats van bewijsmateriaal.

Voor kleinere organisaties bevat de mkb-variant van het Beleid voor veilige ontwikkeling Beleid voor veilige ontwikkeling - mkb een pragmatische minimumeis:

“Het volgen van codeversie, uitroldatum en goedkeurder”

Dat eenvoudige uitrolregister is een sterk startpunt. Veel mkb-organisaties hebben op dag één geen zware releasegovernance nodig, maar zij moeten wel weten welke versie live is gegaan, wanneer en wie dit heeft goedgekeurd.

Het mkb-beleid bepaalt ook:

“Toegang tot tools of systemen voor productie-uitrol moet worden beheerst, gelogd en periodiek worden beoordeeld door de algemeen directeur of IT-dienstverlener.”

Dat is de governancestap die veel kleinere teams missen. Een CI/CD-platform met cloudreferenties voor productie is een geprivilegieerd toegangspad naar productie.

Drie ISO/IEC 27002:2022-beheersgebieden achter veilige CI/CD

De Zenith Controls: gids voor compliance-mapping over kaders heen Zenith Controls is Clarysec’s kompas voor het koppelen van officiële normen en raamwerken aan praktische relaties tussen beheersmaatregelen. Voor governance van CI/CD-pipelinebeveiliging staan drie ISO/IEC 27002:2022-beheersgebieden centraal.

Zenith Controls beschrijft 5.21 als een preventieve beheersmaatregel ter ondersteuning van vertrouwelijkheid, integriteit en beschikbaarheid, waarbij beveiliging in leveranciersrelaties een belangrijke operationele capaciteit is. Dat past bij CI/CD omdat moderne pipelines afhankelijk zijn van externe diensten: platforms voor versiebeheer, gehoste runners, containerregisters, open-source pakketrepositories, GitHub-acties van derden, scantools, cloud-API’s voor uitrol en externe ontwikkelaars.

In de mapping van 5.21 koppelt Zenith Controls beveiliging van de ICT-toeleveringsketen aan 5.19 Informatiebeveiliging in leveranciersrelaties, 5.20 Behandeling van informatiebeveiliging binnen leveranciersovereenkomsten, 8.27 Veilige systeemarchitectuur en engineeringprincipes, 8.28 Veilig programmeren, 8.29 Beveiligingstesten bij ontwikkeling en acceptatie, 5.15 Toegangscontrole, 5.28 Verzameling van bewijsmateriaal, 8.25 Veilige ontwikkelcyclus en 8.30 Uitbestede ontwikkeling.

Voor 8.25 identificeert Zenith Controls de veilige ontwikkelcyclus als een preventieve beheersmaatregel die vertrouwelijkheid, integriteit en beschikbaarheid beschermt. Zij verbindt beveiligingseisen, architectuur, codering, testen, uitbestede ontwikkeling en 8.31 Scheiding van ontwikkel-, test- en productieomgevingen.

Voor 8.32 positioneert Zenith Controls Wijzigingsbeheer als de brug tussen ontwikkeling en operations. Het houdt verband met 8.9 Configuratiebeheer, 8.8 Beheer van technische kwetsbaarheden, secure SDLC en incidentrespons. Daarom kan uitrolautomatisering niet buiten wijzigingsgovernance staan. Het is het mechanisme waarmee productiewijzigingen plaatsvinden.

Buildprovenance: het releaseverhaal dat auditors kunnen volgen

Buildprovenance is het vermogen om met bewijsmateriaal te beantwoorden waar een softwareartefact vandaan kwam en hoe het is geproduceerd. Een sterke provenanceregistratie vertelt het verhaal van een release:

1. Welke broncoderepository en commit zijn gebruikt.
2. Welke branch of tag de build heeft geactiveerd.
3. Welke pull request, beoordelaar en goedkeuring waren gekoppeld.
4. Welke pipelinedefinitie is uitgevoerd.
5. Welke runner de job heeft uitgevoerd.
6. Welke afhankelijkheden en basisimages zijn gebruikt.
7. Welke tests en beveiligingspoorten zijn uitgevoerd.
8. Welk artefact is geproduceerd.
9. Welke handtekening of hash is gegenereerd.
10. Welke uitrol het artefact heeft gebruikt.

Het P05 Wijzigingsbeheerbeleid Wijzigingsbeheerbeleid biedt de governancekoppeling. Het bepaalt:

“Wijzigingen op basis van tools moeten nog steeds aan dit beleid voldoen en herleidbaar zijn tot een overeenkomstig wijzigingsverzoek-ID.”

Dit adresseert het veelgehoorde argument dat geautomatiseerde uitrollen geen wijzigingstickets nodig hebben. Automatisering neemt wijzigingsgovernance niet weg. Zij verandert hoe bewijsmateriaal wordt gegenereerd.

Hetzelfde beleid bepaalt:

“Alle wijzigingsverzoeken, beoordelingen, goedkeuringen en ondersteunend bewijsmateriaal moeten worden vastgelegd in het centrale wijzigingsbeheersysteem.”

In de praktijk moet het wijzigingsbeheersysteem de index zijn, niet de opslagplaats voor alles. Het ticket moet verwijzen naar de broncoderepository, build-run, artefacthandtekening, uitrollogboek en rollbackplan. Gedetailleerd bewijsmateriaal kan in engineeringtools blijven als bewaartermijn, toegangscontrole en exporteerbaarheid zijn gedefinieerd.

Hardening van runners: de vaak vergeten productiebeheersmaatregel

CI/CD-runners worden vaak behandeld als wegwerpinfrastructuur, maar het zijn uitvoeringsomgevingen met een hoog risico. Een runner kan toegang hebben tot broncode, secrets, buildcaches, pakketrepositories, ondertekeningssleutels, artefactregisters en cloudrollen voor uitrol. Als deze persistent, gedeeld, te ruim gemachtigd of slecht gemonitord is, wordt hij een geprivilegieerd draaipunt.

Het veilige governancepunt is eenvoudig: runners die productiecode bouwen of uitrollen, moeten worden gehard als productie-infrastructuur.

Het Beleid voor testgegevens en testomgevingen Beleid voor testgegevens en testomgevingen bepaalt:

“Integratie met CI/CD-pipelines moet de scheiding van omgevingen en authenticatiegegevens afdwingen.”

Een runner die met hetzelfde referentiemodel naar staging en productie kan uitrollen, schendt de scheiding van omgevingen in de praktijk, ook als de infrastructuur logisch gescheiden is. Clarysec adviseert doorgaans afzonderlijke uitrolidentiteiten per omgeving, afzonderlijke goedkeuringspoorten voor productie en expliciete beheersmaatregelen die voorkomen dat jobs uit lagere omgevingen toegang krijgen tot productiesecrets.

De Zenith Blueprint, fase Beheersmaatregelen in actie, stap 21, versterkt dit via scheiding van ontwikkel-, test- en productieomgevingen:

“Als CI/CD wordt gebruikt, bevestig dan dat uitrolpromotie tussen omgevingen wordt beheerst en beoordeling of goedkeuring vereist. Documenteer dit in uw procedure voor omgevingsbeheer en maak schermopnamen of console-exporten ter onderbouwing.”

Voor een echte audit betekent dit dat de auditor niet alleen een diagram moet zien. De auditor moet console-exporten zien met omgevingsspecifieke referenties, beschermde uitrolomgevingen, goedkeuringspoorten en logboeken waaruit blijkt dat promotie beheerst plaatsvond.

Uitrolbewijsmateriaal: het complianceartefact dat in het zicht verborgen ligt

De meest volwassen DevSecOps-teams behandelen bewijsverzameling niet als een kwartaalhaastklus. Zij ontwerpen pipelines zo dat deze automatisch bewijsmateriaal genereren.

Het Logging- en monitoringbeleid voor het mkb Logging- en monitoringbeleid - mkb identificeert relevante loggebeurtenissen als:

“Systeemlogboeken: configuratiewijzigingen, beheerdersacties, software-installaties, patchactiviteiten”

CI/CD-systemen produceren alle vier categorieën. Wijzigingen in pipelineconfiguratie beïnvloeden hoe software wordt gebouwd. Beheerdersacties wijzigen wie kan goedkeuren of uitrollen. Software-installaties vinden plaats in buildimages en uitroldoelen. Patchactiviteiten kunnen via geautomatiseerde releaseprocessen verlopen. Deze gebeurtenissen moeten op basis van risico worden gelogd, bewaard en beoordeeld.

Voor gereedheid voor onderzoek bepaalt het P31S Beleid voor bewijsverzameling en forensisch onderzoek voor het mkb Beleid voor bewijsverzameling en forensisch onderzoek - mkb:

“Schermopnamen, geëxporteerde logboeken en bestandshashes moeten samen met het chain-of-custody-bestand worden opgeslagen.”

Dit is vooral belangrijk na een vermoedelijke compromittering van de pipeline. Alleen schermopnamen zijn zwak bewijsmateriaal. Logboeken zonder hashes kunnen ter discussie worden gesteld. Een chain-of-custody-bestand zonder bronreferenties is onvolledig.

Een verdedigbare registratie van productie-uitrol moet het volgende bevatten.

Dit pakket transformeert CI/CD van een reeks technische stappen naar een verhaal over governance, beheersing en due diligence.

Mapping van CI/CD-governance op NIS2, DORA, GDPR en CRA

NIS2 is van toepassing op veel essentiële en belangrijke entiteiten, waaronder digitale infrastructuur, ICT-servicemanagement en organisaties die digitale diensten aanbieden wanneer aan de criteria wordt voldaan. Article 20 is bijzonder relevant omdat dit artikel cyberbeveiligingstaken op managementniveau vastlegt. Bestuursorganen moeten maatregelen voor cyberbeveiligingsrisicobeheer goedkeuren, toezicht houden op de implementatie en training ontvangen.

Article 21 biedt de basis voor risicobeheer. Het vereist passende en evenredige technische, operationele en organisatorische maatregelen voor risicoanalyse, beleid, incidentenafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, veilige verwerving, ontwikkeling en onderhoud, kwetsbaarhedenbeheer, beoordeling van doeltreffendheid, cyberhygiëne, cryptografie, HR-beveiliging, toegangscontrole, beheer van bedrijfsmiddelen en MFA waar passend.

Article 23 voegt gefaseerde melding van significante incidenten toe, waaronder een vroegtijdige waarschuwing binnen 24 uur na bekendwording, incidentmelding binnen 72 uur en een eindverslag uiterlijk één maand na de incidentmelding. Als een CI/CD-compromittering kan leiden tot ernstige operationele verstoring, financieel verlies of materiële schade voor anderen, moet het proces voor incidentclassificatie gereed zijn vóór het incident.

Voor financiële entiteiten is DORA van toepassing vanaf 17 januari 2025 en omvat het ICT-risicobeheer, incidentmelding, weerbaarheidstesten, informatie-uitwisseling, ICT-risicobeheer van derde partijen en contractuele eisen. Article 5 vereist een intern governance- en beheersingskader voor ICT-risico, met verantwoordelijkheid van het bestuursorgaan. Article 6 vereist een gedocumenteerd ICT-risicobeheerkader dat is geïntegreerd in het algemene risicobeheer.

Articles 8 tot en met 14 mappen rechtstreeks op governance van CI/CD-pipelines. Financiële entiteiten moeten door ICT ondersteunde bedrijfsfuncties, bedrijfsmiddelen, afhankelijkheden, dreigingen en kwetsbaarheden identificeren en classificeren. Zij moeten ICT-systemen beschermen via beleid, toegangscontrole, sterke authenticatie, bescherming van cryptografische sleutels, beheerst ICT-wijzigingsbeheer, patching en segmentatie. Zij moeten anomalieën detecteren, reageren, herstellen en leren van incidenten.

Articles 28 tot en met 30 zijn even belangrijk omdat CI/CD-platforms, aanbieders van versiebeheer, artefactregisters, cloudbuildsystemen en externe ontwikkelaars ICT-afhankelijkheden van derden kunnen zijn. DORA verwacht due diligence, contractuele waarborgen, beoordeling van concentratierisico, audit- en inspectierechten, beëindigingstriggers, exitstrategieën en servicelevelbepalingen.

GDPR voegt het perspectief van verantwoordingsplicht toe. Article 5 vereist dat persoonsgegevens rechtmatig, behoorlijk, transparant, voor welbepaalde doeleinden, geminimaliseerd, juist, niet langer dan nodig bewaard en beschermd tegen ongeoorloofde of onrechtmatige verwerking en tegen accidenteel verlies, vernietiging of beschadiging worden verwerkt. Article 5(2) vereist dat de verwerkingsverantwoordelijke naleving aantoont.

CI/CD-pipelines zijn relevant voor GDPR omdat ontwikkelaars productiegegevens in testomgevingen kunnen gebruiken, pipelinelogboeken persoonsgegevens of tokens kunnen blootleggen, releases verwerkingslogica kunnen wijzigen en gecompromitteerde artefacten kunnen leiden tot datalekken. Waar softwarewijzigingen privacybeheersmaatregelen raken, moet de wijzigingsregistratie de privacy-impact vastleggen. Waar een pipeline-incident leidt tot ongeautoriseerde toegang tot persoonsgegevens, moet de impactbeoordeling van de inbreuk worden gekoppeld aan incidentenafhandeling.

CRA-verwachtingen voegen productbeveiliging en bewijsmateriaal voor veilige updates toe. Voor fabrikanten en softwareaanbieders die producten met digitale elementen op de EU-markt brengen, verwachten klanten in toenemende mate productbeveiligingsdossiers, bewijsmateriaal voor kwetsbaarhedenbeheer, beheersmaatregelen voor veilige updates en release-integriteit. CI/CD-governance levert veel van dat bewijsmateriaal via brontraceerbaarheid, ondertekende artefacten, resultaten van kwetsbaarheidsscans, release notes, beveiligingsoplossingen en registraties van updatedistributie.

NIST CSF 2.0 en COBIT 2019: de auditlens voorbij ISO

NIST CSF 2.0 biedt een integratielaag voor cyberbeveiligingsgovernance. De Core, Organizational Profiles en Tiers helpen organisaties hun huidige en beoogde positie te begrijpen, acties te prioriteren in lijn met wettelijke en regelgevende eisen, en cyberrisico te communiceren.

Voor CI/CD maakt Clarysec vaak een Software Delivery Pipeline Profile. Het Current Profile legt vast hoe versiebeheer, runners, ondertekening van artefacten en uitrolgoedkeuringen vandaag werken. Het Target Profile definieert de vereiste toestand voor gereguleerde activiteiten. Het gapplan wordt de implementatieroadmap.

De NIST GOVERN-functie is bijzonder relevant. GV.OC-03 vereist dat wettelijke, regelgevende en contractuele cyberbeveiligingseisen worden begrepen en beheerd. GV.RM behandelt risicobereidheid en gestandaardiseerde risicoprioritering. GV.RR wijst verantwoordingsplicht van leiderschap, rollen en middelen toe. GV.PO vereist dat beleid voor cyberbeveiligingsrisico wordt vastgesteld, afgedwongen, beoordeeld en bijgewerkt. GV.OV betreft toezicht en prestatie-evaluatie.

Een COBIT 2019- of ISACA-achtige auditor kijkt vaak minder naar de cryptografische details van artefactondertekening en meer naar het governanceontwerp. De auditor zal vragen of eigenaarschap is gedefinieerd, of wijzigingsenablement wordt beheerst, of diensten van derden risicogestuurd worden beheerd, of monitoring assurance oplevert, of uitzonderingen worden goedgekeurd en of het management betekenisvolle rapportage ontvangt.

Veelvoorkomende CI/CD-auditbevindingen en metrieken voor het bestuur

De meeste CI/CD-auditbevindingen zijn voorspelbaar. De eerste is niet-gekoppeld bewijsmateriaal. Het team heeft Git-logboeken, pipelinelogboeken en uitrollogboeken, maar geen enkele wijzigingsregistratie die deze verbindt. De tweede is te ruim gemachtigde automatisering, waarbij één job productiesecrets kan lezen, artefacten kan pushen, uitrollen kan goedkeuren en pipelinedefinities kan wijzigen. De derde is het gebruik van persistente gedeelde runners, waardoor besmettingsrisico tussen projecten ontstaat en forensische afbakening na compromittering moeilijker wordt.

Andere veelvoorkomende tekortkomingen zijn niet-ondertekende of overschreven artefacten, informele scanoverrides, blinde vlekken bij leveranciers en privacylekkage in logboeken. Een goede pipeline staat uitzonderingen toe, maar vereist goedkeuring, vervaldatum, risico-eigenaarschap en beoordeling.

Beveiligingsverantwoordelijken moeten vermijden om alleen aantallen scanners aan het bestuur te rapporteren. Rapporteer in plaats daarvan metrieken voor releasevertrouwen:

• Percentage productie-uitrollen gekoppeld aan goedgekeurde wijzigingsregistraties.
• Percentage productieartefacten dat is ondertekend en herleidbaar is tot broncommits.
• Aantal uitrollen met uitzonderingen of noodgoedkeuringen.
• Percentage geprivilegieerde CI/CD-gebruikers met MFA en recente toegangsbeoordeling.
• Aantal actieve langlevende uitrolreferenties.
• Percentage kritieke diensten dat geharde of efemere runners gebruikt.
• Gemiddelde tijd om pipelinesecrets na een incident in te trekken of te roteren.
• Aantal kritieke leveranciersafhankelijkheden die softwarelevering ondersteunen.
• Volledigheidspercentage van bewijsmateriaal voor releases die in audits zijn bemonsterd.

Deze metrieken ondersteunen leiderschap, planning en operationele beheersing onder ISO/IEC 27001:2022. Ze ondersteunen ook managementtoezicht onder NIS2 Article 20 en de governanceverwachtingen van DORA.

Maak uw pipeline auditeerbaar vóór het incident

Governance voor CI/CD-pipelinebeveiliging in 2026 gaat niet over het vertragen van engineering. Het gaat erom softwarelevering betrouwbaar, weerbaar en aantoonbaar te maken. De beste programma’s gebruiken automatisering om bewijsmateriaal sneller beschikbaar te maken, niet om governance te omzeilen.

Een praktische Clarysec-implementatie begint met drie acties.

1. Gebruik Zenith Blueprint Zenith Blueprint om veilige DevOps, toegang tot broncode, scheiding van omgevingen en wijzigingsbeheer op te nemen in uw implementatieroadmap voor ISO/IEC 27001:2022.
2. Gebruik Zenith Controls Zenith Controls om CI/CD-risico’s te mappen over secure SDLC, ICT-toeleveringsketen, toegangscontrole, wijzigingsbeheer, bewijsverzameling, NIS2, DORA, GDPR, NIST CSF 2.0 en COBIT 2019-auditperspectieven.
3. Implementeer Clarysec-beleidssjablonen, waaronder Beleid voor veilige ontwikkeling, Wijzigingsbeheerbeleid, Beleid voor testgegevens en testomgevingen, Beleid voor veilige ontwikkeling - mkb, Logging- en monitoringbeleid - mkb en Beleid voor bewijsverzameling en forensisch onderzoek - mkb, om vast te leggen wie releases goedkeurt, hoe artefacten worden getraceerd, hoe runners worden beheerst en welk bewijsmateriaal moet worden bewaard.

Als uw volgende auditsample begint met “toon ons het spoor van de productierelease”, moet uw team in minuten kunnen antwoorden, niet in weken. Dat is het verschil tussen DevOps-automatisering en bestuurde softwarelevering.

Download de Clarysec-beleidstoolkit, beoordeel uw CI/CD-pipeline aan de hand van Zenith Blueprint en Zenith Controls, of boek een Clarysec-assessment om uw pipeline te veranderen van een bron van auditzorgen in een hoeksteen van digitale weerbaarheid.