Sikkerhedsstyring af CI/CD-pipelines til revisioner i 2026

Klokken er 08:17 en mandag morgen, og CISO’en i en fintech-virksomhed i vækst modtager den besked, enhver sikkerhedsleder frygter:

“Produktionsbuildet ser rent ud, men artefakthashet matcher ikke commit i kildekode.”

Inden for få minutter bekræfter udviklingsorganisationen, at releasen bestod enhedstests, at udrulningssagen findes, og at den kundevendte tjeneste er stabil. Men pipelinen fortæller en anden historie. En selvhostet CI-runner blev genbrugt på tværs af projekter. En midlertidig cloud-legitimationsoplysning forblev aktiv længere end tilsigtet. Artefaktregisteret viser et signeret container-image, men signeringsnøglen var tilgængelig fra den samme runner, som eksekverede upålidelige buildscripts.

Den releaseansvarlige kan dokumentere, at noget blev udrullet. Det, organisationen ikke kan dokumentere, i hvert fald ikke hurtigt nok, er hvad der blev bygget, hvem der godkendte det, om buildmiljøet var rent, og om bevismaterialet ville kunne holde til en revision eller en hændelsesundersøgelse.

Det er ikke længere kun et DevOps-problem.

I 2026 ligger sikkerhedsstyring af CI/CD-pipelines i krydsfeltet mellem sikkerhed i softwareforsyningskæden, operationel robusthed, ansvarlighed i databeskyttelse, produktsikkerhed og bestyrelsens tilsyn med cyberrisiko. NIS2 presser ledelsesorganer til at godkende og føre tilsyn med foranstaltninger til styring af cybersikkerhedsrisici. DORA kræver, at finansielle enheder styrer IKT-risiko, hændelser, test og tredjepartsafhængigheder. GDPR kræver, at dataansvarlige og databehandlere dokumenterer passende sikkerhed og ansvarlighed for personoplysninger. Cyber Resilience Act hæver markedets forventninger til sikre produkter med digitale elementer, sikre opdateringer og håndtering af sårbarheder. ISO/IEC 27001:2022 kræver et ISMS, der omsætter risikobehandling til kontrolleret drift med dokumenteret bevismateriale.

Pipelinen er blevet revisionssporet for moderne tillid til software.

Det nye compliance-spørgsmål: kan I dokumentere, hvad der nåede produktion?

I årevis har DevSecOps-programmer fokuseret på at tilføje scannere til pipelines. Statisk analyse, afhængighedskontrol, scanning for hemmeligheder, containerscanning og validering af infrastructure-as-code er blevet almindeligt. Disse kontroller er stadig vigtige, men de besvarer ikke det styringsspørgsmål, som revisorer, tilsynsmyndigheder, kunder og bestyrelser nu stiller:

Kan organisationen dokumentere, at hver produktionsudrulning kom fra godkendt kildekode, blev bygget i et kontrolleret miljø, producerede et verificerbart artefakt, bestod de krævede sikkerhedskontrolporte, anvendte godkendte legitimationsoplysninger, fulgte ændringsstyring og genererede bevismateriale, der kan opbevares?

Angribere ved, at buildsystemer, pakkeafhængigheder, udviklertokens, CI-runners, releaseautomatisering, artefaktregistre og roller til cloudundrulning er mål med høj værdi. En kompromitteret pipeline kan omgå traditionelle forsvar, fordi den bruger betroet automatisering til at skubbe ondsindet kode ind i betroede miljøer.

En moden styringsmodel for sikkerhed i CI/CD-pipelines kræver derfor seks søjler for bevismateriale.

Her adskiller Clarysecs tilgang sig fra tjeklistebaseret compliance. Vi behandler CI/CD-platformen som en styret forretningsproces, ikke kun som et teknisk værktøj. Den proces skal afgrænses i ISMS’et, risikovurderes, kontrolleres, overvåges, revideres og forbedres.

Placer CI/CD inden for ISO/IEC 27001:2022 ISMS’et

ISO/IEC 27001:2022 starter med kontekst, interessenter og omfang. Klausul 4.1 til 4.4 kræver, at organisationer forstår interne og eksterne forhold, fastlægger interessentkrav, identificerer retlige, regulatoriske og kontraktlige krav og definerer ISMS-omfanget under hensyntagen til afhængigheder med andre organisationer.

For en SaaS-udbyder, fintech-virksomhed, managed service provider, softwareleverandør eller cloud-baseret virksomhed er CI/CD næsten altid inden for dette omfang, fordi det direkte påvirker levering af tjenesten, kundedata, produktionsinfrastruktur og kontraktlige forpligtelser.

Klausul 5.1 til 5.3 gør ledelsen ansvarlig for ISMS’et. Det er vigtigt, fordi moderne releaseautomatisering ligger mellem udvikling, sikkerhed, clouddrift, indkøb, compliance og produktledelse. Hvis ingen i direktionen ejer risikovilligheden for automatisering af produktionsudrulninger, ender organisationen typisk med fragmenterede værktøjer og inkonsistent bevismateriale.

Klausul 6.1.1 til 6.1.3 udgør planlægningsgrundlaget. Organisationen skal vurdere risici for fortrolighed, integritet og tilgængelighed, identificere risikoejere, sammenholde risici med kriterier, vælge behandlinger, sammenholde valgte kontroller med Annex A, udarbejde en anvendelighedserklæring og opnå godkendelse af risikobehandlingsplanen og restrisikoen.

En CI/CD-risikovurdering bør ikke blot angive “risiko i softwareforsyningskæden”. Den bør navngive realistiske scenarier:

• Et ondsindet buildscript eksfiltrerer signeringsnøgler fra en delt runner.
• En udvikler omgår branchbeskyttelse og udruller ugennemgået kode.
• En kompromitteret tredjepartshandling ændrer et artefakt under build.
• En staging-legitimationsoplysning giver adgang til produktionsmiljøet.
• En udrulning sker uden en tilknyttet ændringsanmodning.
• Pipeline-logfiler, der er nødvendige for rekonstruktion af en hændelse, overskrives efter syv dage.
• En hændelse med afhængighedsforgiftning når præproduktionsmiljøet eller produktionsmiljøet.

Klausul 8.1 kræver derefter planlagt og kontrolleret drift af ISMS-processer, dokumenteret bevismateriale, styring af planlagte ændringer, gennemgang af utilsigtede ændringer og styring af eksternt leverede processer, produkter eller tjenester, der er relevante for ISMS’et. Hvis pipelinen ændrer produktion, skal den producere bevismateriale for kontrolleret drift.

Clarysecs kontrolmodel for sikker softwarelevering

Clarysec forbinder politik, kontroller og revisionsbevismateriale. Zenith Blueprint: En revisors 30-trins køreplan Zenith Blueprint placerer sikker DevOps og sikker udvikling i fasen risikostyring, trin 14. Den angiver, at organisationer skal sikre CI/CD-værktøjer, sikre at kun autoriseret personale kan udløse udrulninger, bruge MFA til pipelineadgang, beskytte buildartefakters integritet samt logge og overvåge CI/CD-handlinger.

“DevOps Pipeline Controls: CI/CD-værktøjer skal sikres – kun autoriseret personale må udløse udrulninger; brug MFA til pipelineadgang; beskyt buildartefakters integritet. Log og overvåg CI/CD-handlinger.”

Denne vejledning bliver operationel, når den omsættes til politikklausuler og krav til bevismateriale.

P24 Politik for sikker udvikling Politik for sikker udvikling angiver:

“Buildartefakter skal signeres og kunne spores til commits i kildekode.”

Dette er en af de stærkeste kontroller i et CI/CD-styringsprogram. Den fortæller udviklingsorganisationen, at et produktionsartefakt skal have en verificerbar afstamning tilbage til kildekodestyring. Den fortæller også revisorer, hvad de skal teste: udvælg en produktionsrelease, inspicér artefaktsignaturen, validér commitreferencen, gennemgå pull request-godkendelsen og bekræft pipeline-buildregistreringen.

Den samme politik angiver:

“Alle udviklingsaktiviteter skal spores gennem godkendte versionsstyringssystemer med håndhævede adgangskontroller, revisionsspor og branchbeskyttelse.”

Dette flytter styringen opstrøms. Hvis kildekoderepositorier ikke er beskyttet, er build-proveniens svag. Hvis branchbeskyttelse kan omgås, kan pipelinen trofast bygge ikke-godkendt kode. Hvis revisionsspor er deaktiveret, afhænger rekonstruktion af hændelser af hukommelse og skærmbilleder frem for bevismateriale.

For mindre organisationer indeholder Politik for sikker udvikling for SMV’er Politik for sikker udvikling for SMV’er et pragmatisk minimumskrav:

“Sporing af kodeversion, udrulningsdato og godkender”

Denne enkle udrulningsfortegnelse er et stærkt udgangspunkt. Mange SMV’er har ikke brug for tung releasestyring fra dag ét, men de skal vide, hvilken version der blev sat i drift, hvornår og hvem der godkendte den.

SMV-politikken angiver også:

“Adgang til værktøjer eller systemer til produktionsudrulning skal kontrolleres, logges og gennemgås periodisk af direktøren eller IT-leverandøren.”

Det er det styringstrin, mange mindre teams overser. En CI/CD-platform med cloud-legitimationsoplysninger til produktion er en privilegeret adgangsvej til produktionsmiljøet.

Tre ISO/IEC 27002:2022-kontrolområder bag sikker CI/CD

Zenith Controls: The Cross-Compliance Guide Zenith Controls er Clarysecs kompas for tværgående compliance til at mappe officielle standarder og frameworks til praktiske kontrolrelationer. For sikkerhedsstyring af CI/CD-pipelines er tre ISO/IEC 27002:2022-kontrolområder centrale.

Zenith Controls beskriver 5.21 som en forebyggende kontrol, der understøtter fortrolighed, integritet og tilgængelighed, med sikkerhed i leverandørrelationer som en central operationel kapacitet. Det passer til CI/CD, fordi moderne pipelines afhænger af eksterne tjenester: platforme til kildekodestyring, hostede runners, containerregistre, open source-pakkerepositories, tredjeparts GitHub Actions, scanningsværktøjer, API’er til cloudundrulning og outsourcede udviklere.

I mappingen af 5.21 kobler Zenith Controls sikkerhed i IKT-forsyningskæden til 5.19 Informationssikkerhed i leverandørrelationer, 5.20 Håndtering af informationssikkerhed i leverandøraftaler, 8.27 Sikker systemarkitektur og tekniske principper, 8.28 Sikker kodning, 8.29 Sikkerhedstestning i udvikling og accept, 5.15 Adgangsstyring, 5.28 Indsamling af bevismateriale, 8.25 Sikker udviklingslivscyklus og 8.30 Outsourcet udvikling.

For 8.25 identificerer Zenith Controls sikker udviklingslivscyklus som en forebyggende kontrol, der beskytter fortrolighed, integritet og tilgængelighed. Den forbinder sikkerhedskrav, arkitektur, kodning, test, outsourcet udvikling og 8.31 Adskillelse af udviklings-, test- og produktionsmiljøer.

For 8.32 beskriver Zenith Controls ændringsstyring som broen mellem udvikling og drift. Den relaterer sig til 8.9 Konfigurationsstyring, 8.8 Styring af tekniske sårbarheder, sikker SDLC og hændelseshåndtering. Derfor kan udrulningsautomatisering ikke ligge uden for ændringsstyring. Den er mekanismen, hvorigennem produktionsændringer sker.

Build-proveniens: releasehistorien, som revisorer kan følge

Build-proveniens er evnen til med bevismateriale at besvare, hvor et softwareartefakt kom fra, og hvordan det blev produceret. En stærk proveniensregistrering fortæller historien om en release:

1. Hvilket kildekoderepository og hvilken commit der blev brugt.
2. Hvilken branch eller tag der udløste buildet.
3. Hvilket pull request, hvilken kodegennemgår og hvilken godkendelse der var knyttet til det.
4. Hvilken pipeline-definition der blev eksekveret.
5. Hvilken runner der eksekverede jobbet.
6. Hvilke afhængigheder og base-images der blev brugt.
7. Hvilke tests og sikkerhedskontrolporte der kørte.
8. Hvilket artefakt der blev produceret.
9. Hvilken signatur eller hash der blev genereret.
10. Hvilken udrulning der anvendte artefaktet.

P05 Politik for ændringsstyring Politik for ændringsstyring giver styringskoblingen. Den angiver:

“Værktøjsbaserede ændringer skal fortsat overholde denne politik og kunne spores til et tilsvarende ændringsanmodnings-ID.”

Det adresserer det almindelige argument om, at automatiserede udrulninger ikke behøver ændringssager. Automatisering fjerner ikke ændringsstyring. Den ændrer, hvordan bevismateriale genereres.

Den samme politik angiver:

“Alle ændringsanmodninger, gennemgange, godkendelser og understøttende bevismateriale skal registreres i det centraliserede ændringsstyringssystem.”

I praksis bør ændringsstyringssystemet være indekset, ikke lossepladsen. Sagen bør pege på kildekoderepository, buildkørsel, artefaktsignatur, udrulningslog og tilbagerulningsplan. Detaljeret bevismateriale kan forblive i udviklingsværktøjer, hvis opbevaring, adgangsstyring og eksportmulighed er defineret.

Hærdning af runners: den oversete produktionskontrol

CI/CD-runners behandles ofte som engangsinfrastruktur, men de er eksekveringsmiljøer med høj risiko. En runner kan få adgang til kildekode, hemmeligheder, buildcaches, pakkerepositories, signeringsnøgler, artefaktregistre og roller til cloudundrulning. Hvis den er persistent, delt, overprivilegeret eller dårligt overvåget, bliver den et privilegeret pivotpunkt.

Den sikre styringsposition er enkel: runners, der bygger eller udruller produktionskode, skal hærdes som produktionsinfrastruktur.

Politik for testdata og testmiljøer Politik for testdata og testmiljøer angiver:

“Integration med CI/CD-pipelines skal håndhæve adskillelse af miljøer og autentifikationsoplysninger.”

En runner, der kan udrulle til staging og produktion med den samme legitimationsmodel, bryder i praksis med miljøadskillelsen, selv om infrastrukturen er logisk adskilt. Clarysec anbefaler typisk separate udrulningsidentiteter pr. miljø, separate godkendelsesporte for produktion og eksplicitte kontroller, der forhindrer jobs i lavere miljøer i at få adgang til produktionshemmeligheder.

Zenith Blueprint, fasen Controls in Action, trin 21, forstærker dette gennem adskillelse af udviklings-, test- og produktionsmiljøer:

“Hvis CI/CD anvendes, skal det bekræftes, at udrulningspromovering mellem miljøer er kontrolleret og kræver gennemgang eller godkendelse. Dokumentér dette i jeres procedure for miljøstyring, og tag skærmbilleder eller konsoleksporter som underbygning.”

I en reel revision betyder det, at revisor ikke kun bør se et diagram. Revisor bør se konsoleksporter, der viser miljøspecifikke legitimationsoplysninger, beskyttede udrulningsmiljøer, godkendelsesporte og logfiler, der dokumenterer, at promoveringen var kontrolleret.

Bevismateriale for udrulning: complianceartefaktet, der ligger lige for

De mest modne DevSecOps-teams behandler ikke indsamling af bevismateriale som en kvartalsvis brandslukning. De designer pipelines til automatisk at generere bevismateriale.

Lognings- og overvågningspolitik for SMV’er Lognings- og overvågningspolitik for SMV’er identificerer relevante loghændelser som:

“Systemlogfiler: Konfigurationsændringer, administrative handlinger, softwareinstallationer, patchningsaktivitet”

CI/CD-systemer producerer alle fire kategorier. Ændringer i pipelinekonfiguration påvirker, hvordan software bygges. Administrative handlinger ændrer, hvem der kan godkende eller udrulle. Softwareinstallationer sker i build-images og udrulningsmål. Patchningsaktivitet kan flyde gennem automatiserede releaseprocesser. Disse hændelser bør logges, opbevares og gennemgås efter risiko.

For undersøgelsesberedskab angiver P31S Politik for indsamling af bevismateriale og digital efterforskning for SMV’er Politik for indsamling af bevismateriale og digital efterforskning for SMV’er:

“Skærmbilleder, eksporterede logfiler og filhashes skal opbevares sammen med chain of custody-filen.”

Det er særligt vigtigt efter mistanke om kompromittering af en pipeline. Skærmbilleder alene er svagt bevismateriale. Logfiler uden hashes kan anfægtes. En chain of custody-fil uden kildereferencer er ufuldstændig.

En juridisk forsvarlig registrering af produktionsudrulning bør omfatte følgende.

Denne pakke transformerer CI/CD fra en række tekniske trin til en fortælling om styring, kontrol og rettidig omhu.

Mapping af CI/CD-styring til NIS2, DORA, GDPR og CRA

NIS2 gælder for mange væsentlige og vigtige enheder, herunder digital infrastruktur, IKT-tjenestestyring og digitale udbyderorganisationer, hvor kriterierne er opfyldt. Article 20 er særligt relevant, fordi den etablerer cybersikkerhedsforpligtelser på ledelsesniveau. Ledelsesorganer skal godkende foranstaltninger til styring af cybersikkerhedsrisici, føre tilsyn med implementeringen og modtage træning.

Article 21 angiver baseline for risikostyring. Den kræver passende og forholdsmæssige tekniske, operationelle og organisatoriske foranstaltninger, der dækker risikoanalyse, politikker, håndtering af hændelser, forretningskontinuitet, sikkerhed i forsyningskæden, sikker anskaffelse, udvikling og vedligeholdelse, håndtering af sårbarheder, effektivitetsvurdering, cyberhygiejne, kryptografi, HR-sikkerhed, adgangsstyring, politik for styring af aktiver og MFA, hvor det er relevant.

Article 23 tilføjer trinvis rapportering af væsentlige hændelser, herunder tidlig varsling inden for 24 timer efter kendskab, hændelsesunderretning inden for 72 timer og en endelig rapport senest én måned efter hændelsesunderretningen. Hvis en CI/CD-kompromittering kan forårsage alvorlig driftsforstyrrelse, økonomisk tab eller væsentlig skade på andre, skal processen for klassificering af hændelser være klar før hændelsen.

For finansielle enheder gælder DORA fra 17. januar 2025 og dækker styring af IKT-risiko, hændelsesrapportering, robusthedstest, informationsdeling, styring af IKT-tredjepartsrisiko og kontraktlige krav. Article 5 kræver en intern governance- og kontrolramme for IKT-risiko med ledelsesorganets ansvar. Article 6 kræver et dokumenteret IKT-risikostyringsrammeværk integreret i den overordnede risikostyring.

Article 8 til 14 kan direkte kobles til styring af CI/CD-pipelines. Finansielle enheder skal identificere og klassificere IKT-understøttede forretningsfunktioner, aktiver, afhængigheder, trusler og sårbarheder. De skal beskytte IKT-systemer gennem politikker, adgangsstyring, stærk autentifikation, beskyttelse af kryptografiske nøgler, kontrolleret IKT-ændringsstyring, patchning og segmentering. De skal detektere anomalier, respondere, genoprette og lære af hændelser.

Article 28 til 30 er lige så vigtige, fordi CI/CD-platforme, udbydere af kildekodestyring, artefaktregistre, cloud-buildsystemer og outsourcede udviklere kan være IKT-tredjepartsafhængigheder. DORA forventer due diligence, kontraktlige sikkerhedsforanstaltninger, vurdering af koncentrationsrisiko, revisions- og inspektionsrettigheder, udløsere for ophør, exitstrategier og serviceniveauklausuler.

GDPR tilføjer ansvarlighedsperspektivet. Article 5 kræver, at personoplysninger behandles lovligt, rimeligt, gennemsigtigt, til specificerede formål, dataminimeret, nøjagtigt, kun opbevaret så længe det er nødvendigt, og beskyttet mod uautoriseret eller ulovlig behandling samt hændeligt tab, destruktion eller skade. Article 5(2) kræver, at den dataansvarlige kan dokumentere overholdelse.

CI/CD-pipelines er relevante for GDPR, fordi udviklere kan bruge produktionsdata i testmiljøer, pipeline-logfiler kan eksponere personoplysninger eller tokens, releases kan ændre behandlingslogik, og kompromitterede artefakter kan forårsage brud på persondatasikkerheden. Hvor softwareændringer påvirker privatlivskontroller, bør ændringsregistreringen indeholde en vurdering af databeskyttelsespåvirkningen. Hvor en pipelinehændelse forårsager uautoriseret adgang til personoplysninger, skal vurderingen af brud knyttes til hændelseshåndtering.

CRA-forventninger tilføjer produktsikkerhed og bevismateriale for sikre opdateringer. For producenter og softwareudbydere, der bringer produkter med digitale elementer på EU-markedet, forventer kunder i stigende grad produktsikkerhedsfiler, bevismateriale for håndtering af sårbarheder, kontroller for sikre opdateringer og releaseintegritet. CI/CD-styring leverer meget af dette bevismateriale gennem kildesporbarhed, signerede artefakter, resultater af sårbarhedsscanninger, release notes, sikkerhedsrettelser og registreringer for distribution af opdateringer.

NIST CSF 2.0 og COBIT 2019: revisionsperspektivet ud over ISO

NIST CSF 2.0 giver et integrationslag for cybersikkerhedsstyring. Dets Core, Organizational Profiles og Tiers hjælper organisationer med at forstå nuværende og ønsket sikkerhedstilstand, prioritere handlinger i overensstemmelse med retlige og regulatoriske krav og kommunikere cyberrisiko.

For CI/CD opretter Clarysec ofte en Software Delivery Pipeline Profile. Current Profile registrerer, hvordan kildekodestyring, runners, artefaktsignering og udrulningsgodkendelser fungerer i dag. Target Profile definerer den krævede tilstand for regulerede driftsaktiviteter. Gap-planen bliver implementeringskøreplanen.

NIST GOVERN-funktionen er særligt relevant. GV.OC-03 kræver, at retlige, regulatoriske og kontraktlige cybersikkerhedskrav forstås og styres. GV.RM dækker risikovillighed og standardiseret risikoprioritering. GV.RR tildeler ledelsesansvar, roller og ressourcer. GV.PO kræver, at politikker for cybersikkerhedsrisici etableres, håndhæves, gennemgås og opdateres. GV.OV dækker tilsyn og evaluering af performance.

En COBIT 2019- eller ISACA-lignende revisor vil ofte se mindre på de kryptografiske detaljer i artefaktsignering og mere på styringsdesignet. De vil spørge, om ejerskab er defineret, om change enablement er kontrolleret, om tredjepartstjenester er risikostyret, om overvågning giver sikkerhed, om undtagelser er godkendt, og om ledelsen modtager meningsfuld rapportering.

Almindelige CI/CD-revisionsfejl og målinger til bestyrelsen

De fleste CI/CD-revisionskonstateringer er forudsigelige. Den første er ikke-sammenkædet bevismateriale. Teamet har Git-logfiler, pipeline-logfiler og udrulningslogfiler, men ingen enkelt ændringsregistrering forbinder dem. Den anden er overprivilegeret automatisering, hvor ét job kan læse produktionshemmeligheder, pushe artefakter, godkende udrulninger og ændre pipeline-definitioner. Den tredje er persistente delte runners, som skaber kontamineringsrisiko mellem projekter og gør forensisk afgrænsning vanskeligere efter kompromittering.

Andre almindelige fejl omfatter usignerede eller overskrevne artefakter, uformelle tilsidesættelser af scanninger, blindhed over for leverandører og datalækage i logfiler. En god pipeline tillader undtagelser, men kræver godkendelse, udløb, risikoejerskab og gennemgang.

Sikkerhedsledere bør undgå kun at rapportere antal scannere til bestyrelsen. Rapportér i stedet målinger for releasetillid:

• Procentdel af produktionsudrulninger knyttet til godkendte ændringsregistreringer.
• Procentdel af produktionsartefakter, der er signerede og kan spores til commits i kildekode.
• Antal udrulninger, der bruger undtagelser eller nødgodkendelser.
• Procentdel af privilegerede CI/CD-brugere med MFA og nylig gennemgang af adgangsrettigheder.
• Antal aktive langlivede udrulningslegitimationsoplysninger.
• Procentdel af kritiske tjenester, der bruger hærdede eller ephemeral runners.
• Mean time to revoke or rotate pipeline secrets efter en hændelse.
• Antal kritiske leverandørafhængigheder, der understøtter softwarelevering.
• Fuldstændighedsgrad for bevismateriale for releases udvalgt ved revisionsstikprøve.

Disse målinger understøtter ISO/IEC 27001:2022-ledelse, planlægning og operationel kontrol. De understøtter også NIS2 Article 20-ledelsestilsyn og DORA-governanceforventninger.

Gør jeres pipeline revisionsbar før hændelsen

Sikkerhedsstyring af CI/CD-pipelines i 2026 handler ikke om at bremse udviklingsorganisationen. Det handler om at gøre softwarelevering tillidsværdig, robust og dokumenterbar. De bedste programmer bruger automatisering til at accelerere bevismateriale, ikke til at omgå styring.

En praktisk Clarysec-implementering starter med tre handlinger.

1. Brug Zenith Blueprint Zenith Blueprint til at placere sikker DevOps, adgang til kildekode, miljøadskillelse og ændringsstyring i jeres ISO/IEC 27001:2022-implementeringskøreplan.
2. Brug Zenith Controls Zenith Controls til at mappe CI/CD-risici på tværs af sikker SDLC, IKT-forsyningskæde, adgangsstyring, ændringsstyring, indsamling af bevismateriale, NIS2, DORA, GDPR, NIST CSF 2.0 og COBIT 2019-revisionsperspektiver.
3. Implementér Clarysec-politikskabeloner, herunder Politik for sikker udvikling, Politik for ændringsstyring, Politik for testdata og testmiljøer, Politik for sikker udvikling for SMV’er, Lognings- og overvågningspolitik for SMV’er og Politik for indsamling af bevismateriale og digital efterforskning for SMV’er, for at definere, hvem der godkender releases, hvordan artefakter spores, hvordan runners kontrolleres, og hvilket bevismateriale der skal opbevares.

Hvis jeres næste revisionsstikprøve starter med “vis os revisionssporet for produktionsreleasen”, bør jeres team kunne svare på få minutter, ikke uger. Det er forskellen mellem DevOps-automatisering og styret softwarelevering.

Download Clarysec-politikværktøjssættet, gennemgå jeres CI/CD-pipeline mod Zenith Blueprint og Zenith Controls, eller book en Clarysec-vurdering for at gøre jeres pipeline fra en kilde til revisionsbekymring til en hjørnesten i digital robusthed.