- Forstå hvordan sikkerhed indgår i pull requests, CI/CD og releasebeslutninger.
- Opbyg praktisk erfaring med kode, trusselsmodeller, automatiske scans og manuel review.
- Dokumentér fund, rettelser og rationale, så en arbejdsgiver kan se effekten af arbejdet.
En Secure Code Reviewer er en specialist i softwareudvikling og applikationssikkerhed, der vurderer kode, design og konfiguration for svagheder. Rollen handler om at finde fejl tidligt, før de udvikler sig til produktionsproblemer, sikkerhedshændelser eller dyre rework-forløb.
For danske udviklere, QA-profiler og junior appsec-specialister er vejen ind i rollen sjældent en lige linje. Nogle kommer fra backend- eller frontend-udvikling, andre fra test, DevOps eller penetrationstest. Fællesnævneren er evnen til at læse kode med sikkerhedsbriller, forklare risikoen klart og foreslå rettelser, som udviklingsteamet faktisk kan implementere.
Rollen må ikke forveksles med klassisk penetrationstest. En penetrationstester vurderer ofte et kørende system udefra eller gennem kontrollerede angrebsscenarier, mens en Secure Code Reviewer typisk arbejder tidligere i udviklingsprocessen, ofte direkte i pull requests, pipeline-fejl, arkitekturdialoger og remediation-arbejde. Det gør rollen særlig værdifuld i organisationer, der ønsker at flytte sikkerhed tættere på udviklingen.
Hvad laver en Secure Code Reviewer i praksis?
En sikker kodegennemgang starter sjældent med at læse hele kodebasen fra linje ét. I praksis begynder revieweren med kontekst: Hvad ændrer denne pull request, hvilke data berøres, hvilke brugere kan rammes, og hvilke sikkerhedskrav gælder for funktionen? En ændring i en intern UI-komponent kræver en anden vurdering end ændringer i betalingsflows, adgangskontrol, identitet, logging eller behandling af persondata.
Et typisk workflow kombinerer automatiske kontroller og manuel vurdering. SAST-værktøjer kan finde mønstre i kode, secrets-scanning kan fange nøgler og tokens, dependency-scanning kan markere sårbare biblioteker, og DAST eller IAST kan give signaler fra en kørende applikation. Den manuelle reviewer vurderer derefter, om fundene er reelle, om de kan udnyttes i den konkrete datastream, og hvilken rettelse der er mindst risikabel for både sikkerhed og funktionalitet.
Den mest effektive placering er ofte tæt på pull request-processen. Teams kan bruge PR-skabeloner med spørgsmål om inputvalidering, autorisation, logning, secrets, tredjepartsafhængigheder og relevante OWASP ASVS-kontroller. Kritiske checks bør køre pre-merge, mens mere omfattende analyser kan køre asynkront, så pipeline ikke bliver så tung, at udviklere begynder at ignorere den.
En god reviewer leder ikke kun efter fejl i applikationskoden. Mange sikkerhedsproblemer opstår i konfiguration: Terraform-moduler, Kubernetes manifests, container images, CI/CD-rettigheder, netværksregler og forkert håndtering af miljøvariabler. Mobilapps kræver også særskilt opmærksomhed, hvor OWASP MASVS giver et mere relevant referencepunkt end generiske webkontroller.
De vigtigste færdigheder
Den tekniske kerne er solid softwareforståelse. En Secure Code Reviewer skal kunne følge data gennem en applikation, forstå hvordan input bliver behandlet, hvor autorisation håndhæves, hvordan sessioner eller tokens bruges, og hvor fejl kan lække information. Det kræver ikke nødvendigvis ekspertise i alle sprog, men revieweren skal kunne læse kode i de sprog, organisationen bruger, og hurtigt genkende almindelige mønstre i frameworks og biblioteker.
Web- og API-sikkerhed er centralt. SQL-injektion, cross-site scripting, server-side request forgery, usikker deserialisering, broken access control og fejl i authentication flows er stadig relevante kategorier. OWASP Top 10 er et nyttigt startpunkt, men professionelle reviews bør ofte kobles til mere detaljerede rammer som OWASP ASVS for webapplikationer, OWASP MASVS for mobil og NIST Secure Software Development Framework, når organisationen arbejder struktureret med sikker softwareudvikling.
Revieweren skal også kunne kommunikere uden at gøre sikkerhed til en stopklods. En kommentar i en pull request bør forklare, hvad risikoen er, hvornår den kan udnyttes, og hvordan rettelsen kan se ud. Kommentarer som “usikker kode” eller “fix auth” skaber friktion. Kommentarer med præcis kontekst, et kort eksempel og et konkret remediation-forslag hjælper udviklere med at rette hurtigere og gentage fejlen sjældnere.
Fra et ansættelsesperspektiv i Danmark vægtes praktisk dømmekraft ofte højt. Kandidater, der kan demonstrere små, sikre kodeændringer, samarbejde på dansk og engelsk og dokumentere rationale bag en sikkerhedsbeslutning, står stærkere end kandidater, der kun kan opliste sårbarhedskategorier. Certifikater kan hjælpe, men de erstatter ikke evnen til at forbedre kode i et rigtigt team.
Et konkret eksempel på review og rettelse
Et simpelt fund kan handle om adgangskontrol. Koden nedenfor viser et API-endpoint, hvor brugeren kan hente en ordre ved at angive et ordre-id. Problemet er ikke selve databasekaldet, men at endpointet ikke kontrollerer, om ordren tilhører den bruger, der er logget ind.
Example — adgangskontrol i et API-endpoint
// Før: ordren hentes alene ud fra id
app.get('/orders/:id', async (req, res) => {
const order = await db.orders.findById(req.params.id);
if (!order) return res.sendStatus(404);
res.json(order);
});
// Efter: ordren knyttes til den autentificerede bruger
app.get('/orders/:id', async (req, res) => {
const order = await db.orders.findOne({
id: req.params.id,
userId: req.user.id
});
if (!order) return res.sendStatus(404);
res.json(order);
});
Review-noten bør beskrive risikoen som broken access control: en bruger kan muligvis ændre id'et og læse en anden brugers ordre. Den foreslåede rettelse binder forespørgslen til den autentificerede brugers identitet. Efter rettelsen bør teamet tilføje en negativ test, der bekræfter, at bruger A ikke kan hente bruger B's ordre, selv når ordre-id'et er kendt.
Værktøjer, støj og triagering
Værktøjer er nødvendige, men de er ikke nok. SAST kan hjælpe med at finde farlige mønstre, men nogle værktøjer giver mange fund uden reel udnyttelighed. DAST ser applikationen udefra, men kan overse kodeveje, der ikke aktiveres under testen. Dependency-scanning finder kendte sårbarheder i biblioteker, men kræver vurdering af, om den sårbare funktion faktisk bruges. Secrets-scanning er ofte lavthængende frugt, men kræver klare processer for rotation, ikke bare sletning af værdien fra Git-historikken.
En moden triageringsstrategi grupperer fund efter datastream, autorisationskritikalitet og exploitability. Hvis flere findings ligger i samme inputflow, bør de vurderes samlet. Hvis et fund berører adgang til persondata eller administrative funktioner, bør det prioriteres højere end et tilsvarende mønster i et lavrisiko-flow. Hvis udnyttelse kræver urealistiske forudsætninger, bør remediation-noten stadig være tydelig, men prioriteten kan justeres.
Værktøjsvalg bør afspejle sprog, arkitektur og modenhed. Letvægts pattern matching kan være hurtig og nyttig i pull requests, mens dybere dataflowanalyse er bedre til komplekse flows på tværs af filer og services. Sprog-specifikke linters kan fange usikker framework-brug tidligt. I praksis fungerer kombinationen bedst, når reglerne løbende justeres ud fra faktiske fejl, falske positiver og de risici, organisationen prioriterer.
Certificeringer og læringsvalg
Certificeringer kan give struktur til læringen og signalere et vist fagligt niveau, men de bør vælges efter den rolle, læseren ønsker. CSSLP er relevant, når målet er sikkerhed gennem hele softwareudviklingslivscyklussen, herunder krav, design, implementering og reviews. CASE retter sig mere direkte mod applikationssikkerhed og sikker kodning. CEH er mere offensivt orienteret og kan være nyttig, hvis karrierevejen hælder mod etisk hacking eller penetrationstest, men den er ikke primært en code review-certificering.
En læser, der vil dykke ned i SDLC-fokusset, kan undersøge CSSLP-certificeringen. Hvis interessen i stedet er offensive teknikker og angrebsforståelse, giver CEH Certified Ethical Hacker en anden vinkel. I begge tilfælde bør certificeringen kobles til praktiske projekter, fordi en arbejdsgiver typisk vil spørge efter konkrete eksempler på fund, prioritering og rettelser.
Et godt læringsforløb bør derfor kombinere teori med kode. Det kan være en sårbar demoapplikation, et open source-projekt, en intern kodebase eller et bevidst lille testprojekt, hvor revieweren dokumenterer fund, rettelsesforslag og efterfølgende tests. Målet er at kunne forklare sikkerhedsbeslutninger, ikke blot genkende begreber.
Portefølje og jobsøgning i Danmark
En portefølje for en Secure Code Reviewer behøver ikke indeholde hemmelige eller følsomme kodeeksempler. Den kan bestå af public pull requests til open source-projekter, små demo-repositories med før- og efter-eksempler, korte writeups af sårbarhedskategorier eller anonymiserede beskrivelser af interne forbedringer. Det vigtigste er, at materialet viser metode: hvordan fundet blev opdaget, hvorfor det var relevant, og hvordan rettelsen reducerede risiko.
I Danmark kan jobsøgning med fordel kombinere almindelige jobportaler med faglige netværk. OWASP Denmark, sikkerhedsmeetups, udviklerfællesskaber og konferencer kan give indblik i, hvilke virksomheder der arbejder seriøst med application security. Kandidater bør dog undgå at præsentere uautoriserede tests eller fund fra tredjeparter som porteføljemateriale. Professionel etik og klare tilladelser betyder meget i sikkerhedsroller.
CV'et bør fremhæve impact frem for antal værktøjer. I stedet for blot at skrive “erfaring med SAST og OWASP Top 10” er det stærkere at beskrive, at reviewarbejde reducerede gentagne fejl i en bestemt kategori, forbedrede PR-skabeloner eller forkortede tiden fra kritisk fund til rettelse. Når tal ikke kan deles, kan kandidaten stadig beskrive processen og beslutningsgrundlaget.
Interviewforberedelse
Interviews til Secure Code Reviewer-roller tester ofte praktisk tænkning. Kandidaten kan blive bedt om at gennemgå et lille kodestykke, prioritere en liste med findings, forklare forskellen på en falsk positiv og en lavrisiko-fejl eller skrive en pull request-kommentar, som en udvikler kan handle på. Intervieweren leder sjældent kun efter det rigtige sårbarhedsnavn; de leder efter forståelse af udnyttelighed, konsekvens og realistisk remediation.
En god forberedelse er at øve korte reviews under tidspres. Kandidaten bør kunne forklare, hvilke dele af koden der blev undersøgt først, hvilke antagelser der blev gjort, og hvilke tests der bør tilføjes efter rettelsen. Det er også nyttigt at kunne diskutere trade-offs: hvornår en pipeline skal blokere et merge, hvornår et fund kan accepteres midlertidigt, og hvordan en risiko dokumenteres uden at forsvinde.
Kommunikation er en del af øvelsen. En stærk kandidat kan omskrive en hård sikkerhedskommentar til en samarbejdende reviewnote, der stadig er præcis. Det viser modenhed, fordi secure code review i hverdagen handler om at påvirke udviklingsbeslutninger uden at overtage udviklernes arbejde.
Udfordringer og belønninger i rollen
Den største udfordring er ofte prioritering. Moderne kodebaser er store, releases sker hurtigt, og automatiske værktøjer kan producere mere støj, end et team kan nå at behandle. Revieweren skal derfor kunne skelne mellem fund, der bør blokere en release, fund der bør planlægges, og mønstre der bør løses gennem fælles komponenter eller udviklertræning.
En anden udfordring er at holde reviewet tæt på forretningen. Sikkerhedsfund bør forklares i relation til data, brugere og systemets formål. En teknisk sårbarhed i et administrativt flow kan have større konsekvens end en mere kendt sårbarhed i et isoleret testværktøj. Det er derfor bedre at måle effekt gennem faktorer som tid til rettelse for kritiske fund, gentagelsesrate pr. kategori og defekter stoppet før produktion end gennem rå antal findings.
Belønningen er, at rollen kan ændre udviklingskulturen. Når revieweren hjælper teams med at indbygge sikre defaults, bedre testcases og tydeligere krav, bliver sikkerhed mindre afhængig af heroisk manuel indsats sent i projektet. Den værdi mærkes både i færre gentagne fejl og i mere trygge releasebeslutninger.
Ofte stillede spørgsmål
Skal man være udvikler for at blive Secure Code Reviewer?
Man behøver ikke have haft titlen softwareudvikler, men man skal kunne læse og forstå kode. QA-profiler, DevOps-specialister og sikkerhedsfolk kan godt skifte ind i rollen, hvis de opbygger stærke færdigheder i programmering, web/API-sikkerhed og remediation.
Hvor meget automatisering kan erstatte manuel kodegennemgang?
Automatisering kan finde kendte mønstre, afhængighedsproblemer og secrets hurtigere end mennesker. Manuel review er stadig nødvendig for forretningslogik, adgangskontrol, datakontekst og vurdering af, om et fund faktisk kan udnyttes i applikationen.
Hvilken certificering passer bedst til secure code review?
CSSLP passer godt til personer, der vil arbejde med sikkerhed gennem hele SDLC. CASE er relevant for applikationssikkerhed og sikker kodning, mens CEH primært giver en offensiv sikkerhedsvinkel. Valget bør afhænge af, om målet er secure development, application security engineering eller penetrationstest.
Hvordan viser man erfaring uden at dele fortrolig kode?
Det kan gøres med demo-repositories, public pull requests, anonymiserede writeups og beskrivelser af processer. Fokus bør være på metode, risikovurdering, remediation og læring, ikke på at vise følsomme detaljer fra en arbejdsgiver.
Vejen videre som Secure Code Reviewer
Den mest realistiske vej ind i rollen er at kombinere udviklingsforståelse, sikkerhedsprincipper og synlige eksempler på praktisk reviewarbejde. Start med små kodeændringer, lær at skrive handlingsbare reviewnoter, og byg gradvist erfaring med pipelines, trusselsmodeller, afhængigheder og konfiguration. Over tid bliver værdien mindre knyttet til at finde flest mulige fejl og mere knyttet til at hjælpe teams med at undgå de samme fejl igen.
Readynez kan indgå som en del af et bredere læringsforløb, hvis der er behov for struktureret certificeringstræning ved siden af praktisk porteføljearbejde. En rolig næste handling er at vælge én relevant certificeringsretning, gennemgå en lille kodebase systematisk og dokumentere både fund og rettelser, så progressionen bliver tydelig.
Hvis der er behov for bred adgang til sikkerhedstræning på tværs af emner, kan Readynez Unlimited være en mulighed at undersøge. Det bør ses som støtte til læring, mens den afgørende kompetence fortsat opbygges gennem praktisk review, samarbejde med udviklere og dokumenteret impact.
