Eksternt code review: 9 situationer hvor det betaler sig

Et eksternt code review betaler sig når en beslutning med mange penge eller stor risiko hviler på kode som ingen uafhængig udvikler har set på. Det gælder typisk når du overtager et system, før du investerer eller udvider, når appen er bygget med AI-værktøjer, og når noget er gået galt. Resultatet skal være en kort rapport du kan træffe beslutninger ud fra, ikke en karakterbog til udvikleren.

Jeg laver selv den slags gennemgange som freelanceudvikler, så læs med det forbehold. Derfor er der også et afsnit om hvornår du kan spare pengene.

Den korte version

Her er de ni situationer, hvad gennemgangen skal svare på, og hvornår den skal ligge.

Min tommelfingerregel: Jo mere der skal bygges eller betales oven på koden, jo tidligere skal den gennemgås. Et code review er et af flere værktøjer i den løbende drift af et system, og resten har jeg samlet i min guide til drift og vedligehold af webapps.

Hvad et eksternt code review er, og hvad det ikke er

Et eksternt code review er en struktureret gennemgang af din kode, din opsætning og dine processer, lavet af en udvikler der ikke har skrevet koden og ikke har en interesse i at forsvare den. Det svarer til at få en mekaniker til at gennemgå en brugt bil før du køber den: Du får at vide hvad der er i orden, hvad der skal ordnes snart, og hvad der kan vente.

En grundig gennemgang ser typisk på:

• Opsætning: Kan projektet startes ud fra det der ligger i repository (kodearkivet), og ligger alle adgange hos dig?
• Versioner og pakker: Får framework, programmeringssprog og pakker stadig sikkerhedsopdateringer?
• Sikkerhed: login, adgangsstyring, håndtering af brugerinput og hemmelige nøgler. Den åbne standard OWASP ASVS er en god tjekliste til netop den del.
• Struktur og datamodel: Kan systemet udvides uden at alt skal laves om?
• Tests og udgivelse: Findes der automatiske tests, og kan en ny version rulles tilbage hvis den fejler?
• Drift: backup, logning og overvågning.

Det er ikke det samme som den daglige kodegennemgang, hvor udviklere på et hold læser hinandens ændringer før de bliver lagt ind. Den ser på én ændring ad gangen, mens et eksternt review ser på helheden. Det er heller ikke en penetrationstest af din webapp, hvor nogen forsøger at bryde ind i det kørende system udefra, typisk uden at læse koden.

Endelig er det mere end at køre et automatisk værktøj. Værktøjer som PHPStan, composer audit og npm audit finder kendte mønstre og pakker med sikkerhedshuller, men de kan ikke vurdere om forretningslogikken er rigtig, eller om strukturen holder til dine planer for systemet.

Når der er mange penge på spil

De tre første situationer har det til fælles at en stor beslutning er på vej. Her koster en gennemgang typisk lidt i forhold til det den kan spare dig for.

1. Du overtager et system fra en anden udvikler

Skifter du udvikler eller bureau, eller er den gamle leverandør forsvundet, ved du sjældent præcist hvad du har fået. Måske mangler der kode i repository, måske kører produktionsserveren en anden version end den der ligger i Git, og måske er en del af det du har betalt for, aldrig blevet færdigt.

Gennemgangen skal laves før den nye udvikler begynder at ændre noget. Så har I et fælles udgangspunkt, og det er tydeligt hvilke problemer der var der i forvejen, og hvilke der opstår efter overtagelsen. Selve skiftet med adgange, kontrakter og overdragelse har jeg beskrevet i guiden til at skifte udvikler midt i et projekt.

2. Du skal investere i, købe eller sælge en virksomhed med software

Når software er en stor del af det der handles, er koden en del af værdien. En investor eller køber vil vide om produktet kan bære vækst, om der gemmer sig en stor regning for teknisk gæld, og om alt hænger på én udvikler. Den tekniske del af en due diligence, altså den grundige undersøgelse før en handel, er i praksis et code review med skarpt fokus på risiko.

Typiske spørgsmål er om virksomheden har adgang til al kode og alle konti, om der er brugt open source-pakker med licenser der ikke passer til et kommercielt produkt, og hvad det koster at få systemet op på et forsvarligt niveau. Ejerskab og licenser skal en advokat også se på. Udvikleren kan finde licenserne i koden, men ikke vurdere kontrakterne.

Er du sælger, er rådet det omvendte: Få lavet gennemgangen før køberen gør det. Så kan du rette de værste fund i ro og mag i stedet for at give nedslag i prisen under tidspres.

3. Du står foran en stor udvidelse

Skal systemet have et nyt modul, en app, flere typer kunder eller langt flere brugere, bygger du oven på det der allerede er der. Er fundamentet skævt, bliver hver ny funktion dyrere, og det opdager du ofte først når en stor del af budgettet er brugt.

En gennemgang før udvidelsen svarer på tre ting: om datamodellen og strukturen kan bære planen, hvad der skal rettes først, og om estimatet for udvidelsen holder. Nogle dages gennemgang er som regel en lille udgift sammenlignet med et projekt på flere måneder, og det er netop her den betaler sig bedst.

Når risikoen ikke kan ses udefra

De næste tre situationer handler om systemer der virker fint på overfladen. Problemet er at du ikke kan se hvad der ligger under.

4. Din app er bygget med AI-værktøjer

Lovable, Bolt, v0 og Cursor kan bygge noget der ser færdigt ud på få dage. Det svære er det du ikke kan se: om én bruger kan læse en anden brugers data, om hemmelige nøgler ligger synligt i browseren, og om der overhovedet findes backup. Veracodes rapport om sikkerhed i AI-genereret kode fra 2025 fandt at 45 % af kodeeksemplerne fra over 100 sprogmodeller indeholdt sårbarheder fra OWASP Top 10, den mest brugte liste over typiske sikkerhedshuller i webapps.

Det betyder ikke at en AI-bygget app er ubrugelig. Det betyder at den skal gennemgås før du åbner for rigtige brugere, tager imod betaling eller gemmer persondata. Gennemgangen afgør også det store spørgsmål: Kan appen ryddes op, eller er det billigere at bygge den om på et fundament der kan vedligeholdes?

5. Du kan ikke selv vurdere det du betaler for

Mange ejere og direktører betaler hver måned for udvikling uden selv at kunne læse koden. Det går fint så længe alt virker. Men når estimaterne vokser, de samme fejl kommer igen, eller du ikke har adgang til dit eget repository, har du ingen måde at se om problemet er koden, processen eller leverandøren.

En uafhængig gennemgang giver dig et udgangspunkt, og det handler ikke om mistillid. En dygtig udvikler har intet imod at nogen kigger med. Bliver der derimod sagt nej til at lade en anden se koden, er det i sig selv et signal.

Gennemgangen er også relevant når hele systemet hviler på én person. Den viser hvor svært det vil være for en anden at tage over, og hvad der skal dokumenteres for at mindske afhængigheden.

6. En kunde eller en lov stiller krav til sikkerheden

Sælger du software til større virksomheder, kommer der før eller siden et sikkerhedsspørgeskema. Mange af dem er omfattet af EU's NIS2-direktiv, som blandt andet kræver at de styrer sikkerheden i forholdet til deres leverandører, og det krav sender de videre til dig.

Behandler systemet persondata, nævner GDPR's artikel 32 desuden en procedure for regelmæssigt at afprøve, vurdere og evaluere om sikkerhedsforanstaltningerne virker. Det er en af de foranstaltninger du skal have, alt efter hvad der er relevant for din behandling af data. En gennemgang med en skriftlig rapport og en plan for rettelserne er en konkret måde at vise at du gør det. Det er ikke juridisk rådgivning, så tal med en rådgiver om hvad netop din virksomhed er forpligtet til.

Når noget er gået galt eller gået i stå

De sidste tre situationer opstår typisk efter en periode hvor systemet har kørt uden opsyn, eller når en krise tvinger dig til at tage stilling.

7. Efter et nedbrud, et sikkerhedsbrud eller en alvorlig fejl

Når appen er nede, eller data er lækket, handler de første timer om at få situationen under kontrol. Har du brug for en plan til den del, så start med hvad du gør når din hjemmeside eller app er nede. Når det akutte er løst, er der et spørgsmål tilbage: Var det en enkeltstående fejl eller et symptom?

En gennemgang efter en hændelse leder efter årsagen og efter de samme svagheder andre steder i koden. Har en manglende adgangskontrol ét sted givet adgang til andres data, er det sjældent det eneste sted. Er persondata involveret, kan du også have pligt til at anmelde bruddet til Datatilsynet, og her hjælper en teknisk gennemgang dig med at beskrive hvad der skete, og hvad du har gjort ved det.

8. Systemet har stået stille i årevis

Mange systemer kører i flere år uden at nogen rører dem. Så længe intet skal ændres, opdager ingen at framework, PHP-version og pakker for længst er holdt op med at få sikkerhedsopdateringer. Ifølge PHP's oversigt over understøttede versioner får PHP 8.2 og alt ældre ingen sikkerhedsrettelser efter 31. december 2026.

Skal udviklingen i gang igen, eller skal en ny udvikler overtage, er en gennemgang det første skridt. Den kortlægger hvor langt bagud systemet er, og hvilke opdateringer der skal tages først. Hvorfor regningen vokser jo længere du venter, har jeg forklaret i indlægget om at opdatere framework og pakker.

9. Nogen foreslår at starte forfra

Det er almindeligt at en ny udvikler eller et bureau kigger på et eksisterende system og anbefaler at bygge det hele om. Nogle gange er det rigtigt. Men det er også nemmere at bygge sin egen løsning end at sætte sig ind i en andens, og en omskrivning er en stor ordre til den der foreslår den. Det gælder også hvis det er mig.

Før du siger ja til et projekt der næsten altid tager længere tid end planlagt, så få en vurdering fra en udvikler der ikke skal lave omskrivningen. Spørgsmålet er ikke om koden er pæn, men om det er billigere at rydde op og udskifte systemet bid for bid. Den vej har jeg beskrevet i indlægget om modernisering af legacy PHP-systemer.

Hvornår du kan spare pengene

En gennemgang koster penge, og ikke alle systemer har brug for en. Du kan typisk spare pengene når:

• Din hjemmeside kører på et standard-CMS som WordPress med meget lidt specialkode. Så er opdateringer, backup og et godt hostingvalg vigtigere end en gennemgang af koden.
• Appen er en prototype der kun skal teste en idé og ikke rummer rigtige brugere, betaling eller persondata.
• Du ikke har tænkt dig at handle på resultatet. En rapport der ender i en skuffe, er spildte penge. Brug dem hellere på det problem du allerede kender.
• Du har et erfarent udviklerhold der læser hinandens kode, har automatiske tests og holder systemet opdateret. Så er en målrettet sikkerhedstest ofte mere relevant end en bred gennemgang.

Og så det ærlige forbehold: Jeg gennemgår systemer bygget med Laravel og PHP samt JavaScript med fx React og Next.js. Er dit system skrevet i .NET, Java eller Python, skal du finde en udvikler med erfaring i netop den teknologi.

Sådan får du en gennemgang du kan bruge

En gennemgang er kun så god som det spørgsmål den skal svare på. Sådan griber du det an:

1. Formulér beslutningen. "Skal vi bygge videre eller starte forfra?" giver et mere brugbart svar end "Er koden god?"
2. Afgræns omfanget. Skal hele systemet gennemgås, eller kun de kritiske dele som login, betaling og adgang til kundedata?
3. Giv de rigtige adgange. Udvikleren skal have adgang til repository og helst til et testmiljø. Undgå at udlevere rigtige persondata, og sørg for en databehandleraftale hvis det ikke kan undgås.
4. Spørg ind til interessekonflikter. En udvikler der gerne vil have opgaven bagefter, har en interesse. Det er ikke et problem i sig selv, men rapporten skal kunne bruges af enhver udvikler.
5. Aftal et møde om rapporten, så du kan spørge ind til det du ikke forstår.

Næste skridt

Find den situation på listen der passer bedst på dig, og skriv den beslutning ned som gennemgangen skal hjælpe dig med. Saml derefter adgang til koden, en kort beskrivelse af systemet og de tre ting der bekymrer dig mest. Med det på plads kan en udvikler give dig et realistisk bud på omfang og pris.

Jeg aftaler omfang og pris før jeg går i gang, og min tilgang er at rapporten skal kunne bruges af enhver udvikler, også hvis det ikke bliver mig der laver rettelserne. Du har direkte kontakt med den udvikler der læser koden. Se hvordan jeg ellers arbejder med eksisterende systemer på siden om vedligehold og videreudvikling.

Ofte stillede spørgsmål

Hvad koster et eksternt code review?+

Prisen afhænger især af hvor stort systemet er, hvor mange integrationer det har, og om gennemgangen skal dække det hele eller kun sikkerheden. Som et groft skøn tager en mindre app et par dages arbejde, mens en stor platform kan tage et par uger. Bed om en fast pris for et afgrænset omfang, så du kender udgiften før du får svar på det store spørgsmål.

Skal min nuværende udvikler vide at koden bliver gennemgået?+

Ja, som udgangspunkt. Gennemgangen bliver bedre når udvikleren kan forklare de valg der er truffet, og fundene er nemmere at rette når den der kender koden, er med fra start. Gør det klart at det er koden og ikke personen der bliver vurderet. Er samarbejdet allerede brudt sammen, kan det være rimeligt at få vurderingen først og tage samtalen bagefter.

Kan et AI-værktøj ikke bare lave et code review?+

Delvist. AI-værktøjer og automatiske scannere er gode til at finde kendte mønstre, sårbare pakker og åbenlyse fejl, og de hører med i en grundig gennemgang. De kan til gengæld ikke vurdere om forretningslogikken er rigtig, om strukturen passer til dine planer, eller hvilke fund der betyder noget for netop din virksomhed. Brug dem som supplement, ikke som erstatning for en erfaren udvikler.

Hvor ofte bør man få lavet et code review?+

For de fleste systemer er det nok ved de situationer der er nævnt her, ikke efter en fast kalender. Behandler systemet følsomme persondata, eller har du kunder med skrappe sikkerhedskrav, er en fast gennemgang en gang om året eller ved større ændringer en god vane. Mellem gennemgangene klarer løbende opdateringer, automatiske tests og overvågning det meste.