GitHub, GitLab og Azure DevOps: auditlogs for kloning, forks og tokens

Forside · Gennemgået oktober 2026 · Af John Nielsen

Spørgsmålet “har udvikleren taget en kopi af koden?” kan sjældent besvares ud fra Git selv, fordi en kloning ikke ændrer repositoriet og derfor ikke efterlader spor i historikken. Svaret skal findes i kodeplatformens logs: auditlogs over organisationens hændelser, logs over Git-operationer, forks, personlige adgangstokens, SSH-nøgler og integrationer. Hvor meget der registreres, afhænger i høj grad af platform, abonnement og om platformen er selvhostet, og loggene har ofte kort opbevaring.

Haster det? På GitHub Enterprise Cloud gemmes Git-hændelser som kloninger kun i syv dage, og på selvhostede installationer roteres logfilerne løbende. Se akut forensisk sikring; hastesager koster ekstra.

Artiklen supplerer kildekode og Git som bevis, som handler om selve historikken. Virksomhedens praktiske skridt, når en udvikler stopper, er beskrevet på bevissikring-digitalt.dk.

To typer logs

Kodeplatformene skelner typisk mellem to slags hændelser:

Administrative hændelser · Brugere tilføjet eller fjernet, rettigheder ændret, repositories oprettet, slettet, gjort offentlige, forks, tokens og nøgler oprettet, integrationer installeret
Git-operationer · Clone, fetch og push mod et repository, med konto, tidspunkt og ofte IP-adresse og protokol

Administrative hændelser er normalt med i auditloggen på organisationsniveau. Git-operationer, herunder kloning, er langt fra altid registreret, og hvor de er, kan opbevaringen være kort eller kræve, at loggen streames til et eksternt system.

De tre platforme i grove træk

Beskrivelsen gælder på tidspunktet for gennemgangen (oktober 2026). Funktioner og opbevaring ændres løbende, så kontrollér den konkrete platform.

GitHub. Organisationer har en auditlog over administrative hændelser, der dækker de seneste 180 dage. Med GitHub Enterprise Cloud kan Git-hændelser som clone, fetch og push også fremgå af virksomhedens auditlog, men de gemmes kun i syv dage, og loggen kan streames til et eksternt lager. Brugerkonti har desuden en egen sikkerhedslog.

GitLab. Auditbegivenheder findes på gruppe-, projekt- og instansniveau, men omfanget afhænger af abonnement. Git-operationer som clone, fetch og push kan kun modtages som streamede auditbegivenheder på det højeste abonnement og vises ikke i brugerfladen. På en selvhostet installation registrerer gitlab-shell.log Git-operationer over SSH, og production_json.log registrerer clone og fetch over HTTP. De kan være den bedste kilde til kloninger. Rotationen styres af logrotate og kan være indstillet lokalt.

Azure DevOps. Auditloggen er som standard slået fra og skal aktiveres af organisationen. Hændelser gemmes i 90 dage og kan streames til et eksternt system. Listen over Git-hændelser omfatter fx oprettelse, sletning og forks af repositories, men ikke kloning eller fetch. Loggen bør derfor suppleres med Entra ID-logins og eventuelle netværkslogs.

Fælles for alle tre er, at standardvisningen i brugerfladen kan være begrænset til en kortere periode end det, der kan hentes via API eller eksport.

Tokens og nøgler

En udvikler, der vil hente kode uden om de almindelige arbejdsgange, bruger typisk et personligt adgangstoken, en SSH-nøgle eller en integration. Platformene registrerer normalt oprettelse og sletning af tokens og nøgler, og ofte hvornår et token sidst blev brugt.

Relevante spørgsmål:

Hvilke tokens og nøgler havde kontoen, og hvornår blev de oprettet?
Hvilke rettigheder havde de, og til hvilke repositories?
Hvornår blev de sidst brugt, og fra hvilken IP-adresse, hvis det registreres?
Er der oprettet tokens kort før fratrædelsen eller brugt tokens efter?
Er der installeret apps eller integrationer, der har læseadgang til koden?

Et token, der fortsat virker efter, at kontoen er spærret i virksomhedens identitetsudbyder, er et kendt problem. Hvordan sessioner og tokens kan leve videre, er beskrevet i sessioner og tokens i loginlogs. Mistanke om, at et token er lækket eller misbrugt, er behandlet i lækkede API-nøgler og tokens.

Forks og private kopier

Forks af et privat repository til en privat konto er en af de mest direkte måder at tage koden med på. Organisationens indstillinger afgør, om forks af private repositories er tilladt. Oprettelse af en fork registreres normalt som en administrativ hændelse. Bliver forken senere slettet, kan hændelsen stadig ligge i loggen.

Overførsel af et repository til en anden konto, ændring af synlighed fra privat til offentlig og tilføjelse af eksterne samarbejdspartnere er andre hændelser, der bør gennemgås.

Supplerende kilder

Når platformens egne logs ikke dækker, kan andre kilder udfylde billedet:

Identitetsudbyderen: logins til platformen via single sign-on, med tidspunkt, enhed og IP. Se identitetsudbydere og SSO.
Netværk og proxy: datamængder til platformens adresser fra en bestemt enhed.
Udviklerens computer: lokale kloner, Git-konfiguration, credential-lagre og tidsstempler i .git-mapperne.
EDR og DLP: proceskørsler af Git-klienter og kopiering af mapper til eksterne medier eller private cloudtjenester.

En kloning fra platformen til virksomhedens egen computer er normalt en del af arbejdet. Det afgørende er ofte, hvad der derefter skete med kopien, og det ligger på endpointet, ikke på platformen.

Sikring

Kontrollér opbevaringen straks, og start eventuelt streaming eller eksport, før ældre hændelser udløber.
Eksportér auditloggen for organisation, relevante grupper og projekter via API eller eksportfunktion i rå form, typisk JSON eller CSV.
Hent kontooplysninger: tokens, nøgler, apps, medlemskaber og rettigheder for de relevante konti, inden kontoen slettes.
Dokumentér organisationens indstillinger, fx om forks af private repositories er tilladt.
Sikr selvhostede serverlogs som filer med hashværdier, før de roterer.
Registrér hvem der eksporterede, med hvilken konto og hvilket værktøj, og hash hver fil.

Fremgangsmåden ved eksport via API og dokumentation af forespørgslerne er beskrevet i cloud-forensic via API og eksport.

Slet ikke kontoen, før data er sikret. Når en konto fjernes fra organisationen, kan tokens, nøgler og visse kontooplysninger forsvinde fra den visning, organisationen har adgang til.

Analysen: kontoens normale mønster først

En enkelt hændelse siger sjældent meget. Analysen bør derfor begynde med kontoens normale brug over en længere periode: hvilke repositories kontoen plejer at arbejde i, på hvilke tidspunkter, fra hvilke adresser og med hvilke klienter. Først derefter giver det mening at se på perioden omkring fratrædelsen eller den hændelse, sagen drejer sig om.

Typiske afvigelser, der er værd at undersøge:

kloning af repositories, kontoen ikke tidligere har arbejdet i,
mange kloninger eller downloads af arkiver på kort tid,
aktivitet uden for kontoens normale tidsrum eller fra nye adresser,
nye tokens, nøgler eller integrationer kort før eller efter en opsigelse,
ændring af synlighed, overførsel af repositories eller tilføjelse af eksterne brugere.

Platformene giver ofte mulighed for at downloade et repository som en zip- eller tar-fil gennem brugerfladen. Det er en anden hændelsestype end en Git-kloning. GitHub har en særskilt auditbegivenhed for download af et arkiv som zip-fil, og GitLab registrerer download af private og interne repositories som en auditbegivenhed. I Azure DevOps’ liste over auditbegivenheder findes ingen tilsvarende hændelse.

Fejlkilder i fortolkningen

Fetch er ikke clone. En udviklers daglige synkronisering giver mange fetch-hændelser. Et clone af mange repositories på kort tid er mere sigende end enkelte hændelser.
Automatik. CI/CD, backup og integrationer kloner også, ofte med servicekonti eller tokens udstedt til en person.
IP-adresser. Virksomhedens VPN, NAT og cloududviklingsmiljøer gør, at mange brugere deler adresser.
Tidszoner. Platformene gemmer typisk UTC, mens brugerfladen viser lokal tid.
Manglende logning. Fravær af en clone-hændelse kan betyde, at platformen eller abonnementet ikke registrerer den type hændelse.

Hvad loggene kan og ikke kan bevise

Auditloggen kan vise, at en bestemt konto eller et bestemt token udførte en handling på et bestemt tidspunkt, set fra platformen. Den kan ikke vise, hvem der sad ved tastaturet, og den kan ikke vise, hvad der skete med koden efter kloningen. Konklusionen styrkes, når platformens hændelser kan kobles til en bestemt enhed og til spor på den enhed, og når mønstret afviger klart fra kontoens normale brug.

Rapporten bør angive platform, abonnement, hvilke hændelsestyper der overhovedet blev registreret i perioden, og opbevaringstiden. Uden den beskrivelse kan læseren ikke vurdere, om fravær af en hændelse betyder noget.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Læs også: Timeregistrering mod commits og tickets: krydsvalidering · Kodelighed: sammenligning af to kodebaser, metode og fejlkilder

→ Uvildig IT-sagkyndig med forensic-baggrund · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik