Kodeaudit: hvad den dækker, og hvornår I har brug for den

En kodeaudit er en uafhængig gennemgang af jeres software: koden, men også hvordan den bliver bygget, sat i drift og kørt. Den giver jer et ærligt billede af, hvad I står med, før I bygger videre, skifter leverandør eller investerer i nye funktioner. Her er, hvad en kodeaudit dækker, hvornår den giver mening, hvad I får ud af den, og hvordan I undgår de mest almindelige fejl.

Det skal I vide

• En kodeaudit ser på hele løsningen: kode, afhængigheder, arkitektur, test, drift og hosting.
• Den giver mest værdi, når I overtager kode, skal skalere, har haft et sikkerhedsbrud eller står over for et salg.
• Resultatet er en prioriteret rapport med konkrete rettelser og estimater, ikke en lang liste uden retning.
• Adgangen kan være skrivebeskyttet. Auditøren behøver ikke ændre noget i jeres systemer.
• Ret ikke alt på én gang. Start med de kritiske fund og læg resten ind i den løbende plan.

Hvad er en kodeaudit?

En kodeaudit er en gennemgang udført af nogen, der ikke selv har skrevet koden. Formålet er at finde risici og svagheder, før de bliver til nedetid, datalæk eller dyre omskrivninger. Det er ikke det samme som et almindeligt kodereview, hvor en kollega kigger på en enkelt ændring. En audit ser på systemet som helhed og på de beslutninger, der ligger bag det.

En god audit vurderer også, hvordan systemet bliver bygget og kørt. Mange problemer ligger ikke i selve koden, men i konfigurationen af serveren, i en gammel database eller i et deploy-script, som kun én person forstår.

Hvad en kodeaudit dækker

Indholdet afhænger af systemet, men en grundig gennemgang omfatter som regel:

• Sikkerhed. Kendte sårbarheder i afhængigheder, forældede biblioteker, adgangskoder og nøgler gemt i koden, og hvordan input og login bliver håndteret.
• Arkitektur og struktur. Hvordan systemet er delt op, og om det kan bære de ændringer, I har planlagt.
• Kodekvalitet og vedligeholdelse. Gentagelser, døde dele og kode, der er svær at ændre uden at noget andet går i stykker.
• Ydeevne. Langsomme forespørgsler, unødige kald og flaskehalse under belastning.
• Test. Hvor meget der er dækket af automatiske test, og om testene faktisk bliver kørt.
• Build, deploy og hosting. Hvordan koden kommer i produktion, servernes opsætning, backup og logning.
• Dokumentation og licenser. Om en ny udvikler kan komme i gang, og om licenserne på tredjepartskode passer til jeres brug.

Hvornår har I brug for en kodeaudit?

Der er nogle situationer, hvor en kodeaudit næsten altid betaler sig:

• I overtager kode fra en tidligere leverandør eller en freelancer og ved ikke præcis, hvad I har fået.
• Før en stor ny funktion eller vækst, hvor flere brugere eller nye integrationer vil presse systemet.
• Efter et sikkerhedsbrud eller mistanke om, at nogen har haft adgang, de ikke burde have.
• Før et opkøb eller en investering, hvor køberen vil have en teknisk due diligence.
• Et ældre system, som ingen i huset længere forstår fuldt ud.
• De samme fejl kommer igen, selvom de bliver rettet hver gang.

Efter et angreb er der én ting, der er værd at huske: En oprydning, der kun fjerner symptomerne, uden at finde ud af hvordan angriberen kom ind, bliver ofte gentaget. Find indgangen og luk den. Mange brud starter med software, der ikke er opdateret, som vi beskrev i artiklen om PHP-sikkerhedsopdateringen i oktober 2026.

Hvad I får ud af en kodeaudit

Resultatet er en skriftlig rapport, hvor hvert fund har en alvorlighed: kritisk, høj, middel eller lav. For hvert fund beskriver vi, hvad problemet er, hvor det sidder, hvad det betyder for jer, og hvordan det kan rettes. Hvert forslag har et estimat, så I kan planlægge og prioritere.

Rapporten skal kunne læses af både ledelse og udviklere. Ledelsen skal kunne se, hvor risikoen er størst. Udviklerne skal kunne gå direkte i gang med rettelserne.

Sådan laver vi en kodeaudit

Vores kodeaudittjenester følger et fast forløb:

1. Omfang. Vi aftaler, hvilke systemer, repositories og miljøer der er med, og hvad I især er bekymrede for.
2. Adgang. Vi får skrivebeskyttet adgang til kode, konfiguration og gerne logfiler fra produktion.
3. Automatisk scanning. Værktøjer finder kendte sårbarheder, forældede afhængigheder, hemmeligheder i koden og typiske kvalitetsproblemer.
4. Manuel gennemgang. Udviklere læser de vigtigste dele af koden og opsætningen. Det er her, fejl i logik og arkitektur bliver fundet.
5. Gennemgang af fund. Vi præsenterer rapporten for jer og svarer på spørgsmål.
6. Plan for rettelser. Hvis I ønsker det, laver vi en plan for, hvad der skal rettes først.

Teamet bag en audit kan bestå af udviklere fra flere af vores kontorer, så de rette kompetencer er med til jeres teknologi.

Typiske fejl ved en kodeaudit

• Kun koden bliver gennemgået. Hosting, serveropsætning og konfiguration bliver sprunget over, selvom mange problemer ligger netop der.
• Ingen adgang til produktionens konfiguration. Uden den ser auditøren et testmiljø, der måske ikke ligner virkeligheden.
• Alt skal rettes på én gang. Det standser al anden udvikling og giver nye fejl. Ret de kritiske fund først og læg resten ind i den løbende plan.
• Rapporten ender i en skuffe. Uden en ansvarlig og en tidsplan bliver fundene ikke rettet.

Efter auditten: hvem retter fundene?

Nogle gange kan jeres egne udviklere rette det hele. Andre gange giver det mening at få hjælp. Små og løbende rettelser passer godt ind i en aftale om softwarevedligeholdelse. Er der tale om et større arbejde, kan et dedikeret udviklingsteam tage sig af det uden at forsinke jeres egen plan. Skal dele af systemet bygges om, hjælper vores softwareudviklingstjenester med det.

Ofte stillede spørgsmål

Hvor I skal starte

Skriv ned, hvorfor I overvejer en kodeaudit: overtagelse af kode, vækst, et sikkerhedsbrud eller et salg. Saml adgang til repositories, konfiguration og hosting. Aftal derefter et klart omfang, så rapporten svarer på det, I faktisk har brug for at vide.