Forside · Gennemgået oktober 2026 · Af John Nielsen
En kildekodegennemgang er en systematisk undersøgelse af kode for at besvare bestemte spørgsmål: om kvalitet, sikkerhed, fuldstændighed, overensstemmelse med krav eller ophav. I en tvist eller ved en vurdering forud for en investering skal gennemgangen kunne efterprøves af en anden fagperson. Det kræver, at spørgsmålet, versionen, omfanget, værktøjerne og udvælgelsen er beskrevet, så resultatet ikke afhænger af, hvem der kiggede.
Artiklen beskriver metoden. Sammenligning af to kodebaser for at vurdere kopiering er en særlig disciplin, beskrevet i kodelighed: sammenligning af to kodebaser.
Spørgsmålet styrer gennemgangen
Kode kan gennemgås ud fra mange vinkler, og de kræver forskellige metoder:
- Er koden vedligeholdbar? · Struktur, kompleksitet, dubletter, test, dokumentation
- Er der sikkerhedssvagheder? · Statisk analyse, gennemgang af kritiske flows, afhængigheder
- Er kravene implementeret? · Sporing fra krav til kode og test
- Er koden komplet og kan bygges? · Byg fra kilde, sammenligning med leveret version
- Hvor stammer koden fra? · Historik, licenser, lighed med anden kode
Et opdrag som “gennemgå koden” er for bredt til at give et brugbart svar. Spørgsmålene bør præciseres, før arbejdet begynder, og et svar bør kun gives på de spørgsmål, der er stillet. I en retssag formuleres spørgsmålene typisk i et skønstema, se syn og skøn i IT-sager.
Den præcise version
Gennemgangen skal knyttes til én identificeret version: et commit-id, et tag eller et arkiv med kendt hashværdi. Koden bør modtages som et repository med historik eller som et sikret arkiv, ikke som løse filer sendt over tid. Er spørgsmålet, hvad der blev leveret på et bestemt tidspunkt, skal det dokumenteres, at den gennemgåede version er den leverede, se leverancens tilstand på overdragelsestidspunktet.
Kan koden bygges?
Et første og ofte overset trin er at bygge koden fra kilde. Det viser, om leverancen er komplet, om afhængigheder kan hentes, og om byggeinstruktionerne er tilstrækkelige. Kan koden ikke bygges, er det et selvstændigt fund. Kan den, bør det byggede resultat sammenlignes med det, der kører eller blev leveret, fx via hashværdier eller en SBOM. Om det sidste, se SBOM og byggeartefakter.
Automatiseret analyse
Værktøjer giver overblik over store kodemængder og finder mønstre, en person let overser. Typiske kategorier:
- Statisk analyse for sikkerhed (SAST): mønstre for kendte svaghedstyper, ofte klassificeret efter CWE.
- Kvalitetsanalyse: kompleksitet, dubletter, overtrædelser af kodestandarder og testdækning.
- Analyse af afhængigheder: tredjepartskomponenter med kendte sårbarheder og deres licenser.
- Søgning efter hemmeligheder: adgangskoder, nøgler og tokens i kode og historik.
Værktøjernes resultater er indikationer, ikke konklusioner. Statisk analyse giver både falske positiver og falske negativer, og resultatet afhænger af værktøjets version og de regelsæt, der er slået til. Et højt antal fund siger ikke i sig selv noget om alvor. Fundene skal sorteres, og de væsentlige skal efterprøves manuelt.
Manuel gennemgang
Den manuelle gennemgang er der, hvor sammenhængen vurderes: arkitektur, forretningslogik, fejlhåndtering, adgangskontrol og datahåndtering. OWASP’s Code Review Guide giver en struktureret tilgang til sikkerhedsgennemgang, og ISO/IEC 25010 kan bruges som referenceramme for kvalitetsbegreber som vedligeholdbarhed.
Fordi en fuld manuel gennemgang af en stor kodebase sjældent er realistisk, skal udvælgelsen være begrundet. Gængse principper:
- Risikobaseret: de dele, der håndterer betaling, persondata, adgang eller kernefunktioner.
- Spørgsmålsbaseret: de moduler, der er knyttet til de påståede fejl eller krav.
- Stikprøve: et tilfældigt udvalg til at vurdere den generelle kvalitet, med beskrevet udvælgelse.
Rapporten må kun udtale sig generelt om kodebasen, hvis udvælgelsen gør det forsvarligt, og skal ellers begrænse konklusionen til det gennemgåede.
Historikken som supplement
Selve koden viser tilstanden i én version. Versionshistorikken kan vise, hvordan den kom dertil: om en svaghed blev indført tidligt eller sent, om tests er fjernet, om store dele er kopieret ind på én gang, og hvem der har arbejdet på de kritiske moduler. Den kan også afsløre hemmeligheder, der er fjernet fra den nuværende version, men stadig ligger i ældre commits. Hvor spørgsmålet handler om bidrag og tidspunkter, se Git-historik i projekttvister.
Når begge parter har en sagkyndig
Har hver part fået sin egen gennemgang udført, bliver forskellene i metode ofte vigtigere end forskellene i fund. To gennemgange med forskellige værktøjer, regelsæt og stikprøver kan nå forskellige resultater, uden at nogen af dem er forkert. En sammenligning bør derfor starte med metoderne: samme version, samme spørgsmål, samme kriterier. Først derefter giver det mening at sammenligne fundene ét for ét.
Fortrolighed
Kildekode er ofte en virksomheds mest værdifulde forretningshemmelighed, og i en tvist kan modparten være konkurrent. Gennemgangen bør derfor ske under aftalte vilkår: hvem der har adgang, hvor koden opbevares, om den må forlade et bestemt miljø, og hvad der sker med kopier efter sagen. Det kan være relevant, at gennemgangen sker i et isoleret miljø, og at rapporten kun gengiver de kodeuddrag, der er nødvendige for at begrunde fundene. Hvordan beviskopier håndteres under en opgave, er beskrevet i datasikkerhed under opgaven.
Dokumentation
En gennemgang, der skal kunne efterprøves, dokumenterer:
- spørgsmålene, som de blev stillet, og eventuelle præciseringer
- versionen med commit-id eller hashværdi, og hvordan den blev modtaget
- byggeforsøget og resultatet
- værktøjer med version og regelsæt, og rå resultatfiler med hashværdi
- udvælgelsen til manuel gennemgang og begrundelsen
- hvert væsentligt fund med fil, linje, commit, beskrivelse, alvor og begrundelse
- begrænsninger: hvad der ikke er gennemgået, og hvorfor
Fund bør formuleres neutralt og med henvisning til en kilde eller et kriterium, fx en CWE-kategori, et krav i aftalen eller en anerkendt praksis, ikke som personlig smag.
Typiske faldgruber
- Antal værktøjsfund præsenteres som et mål for kvalitet.
- Gennemgangen sker på en anden version end den leverede.
- Tredjepartskode og genereret kode vurderes som om den var skrevet i projektet.
- Konklusioner om hele kodebasen bygger på en lille, ubeskrevet stikprøve.
- Kodestandarder, der ikke var aftalt, bruges som målestok uden at det fremgår.
- Fund gengives uden fil, linje og version, så de ikke kan genfindes.
Hvad en gennemgang kan og ikke kan vise
En velbeskrevet gennemgang kan vise, hvilke konkrete forhold der findes i en bestemt version af koden, og vurdere dem mod et angivet kriterium. Den kan ikke garantere, at der ikke findes andre fejl eller svagheder, og den siger ikke i sig selv, hvordan softwaren opfører sig i drift. Hvor koden indgår i en vurdering af en påstået mangel, se teknisk mangelsvurdering af software. En uvildig IT-sagkyndig kan vurdere de tekniske spørgsmål i en sag, se uvildig IT-sagkyndig med forensic-baggrund og IT-skøn i tvister om IT-projekter og software.
Kilder og versioner
- OWASP: Code Review Guide
- MITRE: Common Weakness Enumeration (CWE)
- ISO/IEC 25010:2023, Product quality model
Senest gennemgået: oktober 2026.
Næste skridt
- SLA-målinger: hvordan tallene beregnes, og hvor de kan være forkerte
- GitHub, GitLab og Azure DevOps: auditlogs for kloning, forks og tokens
- Massesletning efter en tvist er opstået: tekniske tegn
Læs også: Performance og kapacitet: måling, når SLA’en bestrides · Kodesammenligning ved ophavsretskrænkelse: værktøjer og faldgruber
→ Uvildig IT-sagkyndig med forensic-baggrund · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
