Videregående IT-sikkerhed for udviklere: kompetencer, roadmap og næste skridt

Hvad betyder videregående IT-sikkerhed for dig som udvikler?

Videregående IT-sikkerhed for udviklere handler ikke om at blive fuldtids-sikkerhedsekspert, men om at kunne bygge software, der er sikkert som udgangspunkt. Det betyder sikker kodning, stærk autentificering og autorisation, beskyttelse af data, gennemført logging og at du får sikkerhed ind i CI/CD-pipeline og drift, ikke kun som et sidste tjek.

Man kan se det som skiftet fra “jeg ved, at sikkerhed er vigtigt” til “jeg kan faktisk implementere det rigtigt i kode, API-design og deployment”. Det er også her, du begynder at tage højde for trusselsbilleder, compliance (som NIS2 og GDPR) og samarbejder med sikkerheds- og driftsteams på et mere kvalificeret niveau.

En simpel kompetencemodel for udviklere

For at få overblik er det nyttigt at dele kompetencerne op efter niveau. Det her er en praktisk model, ikke en officiel standard, men den rammer ret godt, hvad der forventes i mange teams i dag.

Minimum, professionelt niveau og videregående

For at gøre det mere konkret kan du tænke i tre lag:

Hvis du er udvikler i dag, er målet typisk at komme solidt op på “professionelt niveau” og have udvalgte områder på “videregående” afhængig af din rolle.

Hvordan kommer du i gang med videregående IT-sikkerhed?

Den bedste måde at komme i gang på er at starte smalt og praktisk: lær grundlæggende web- og adgangssikkerhed, øv dig i sikre coding-øvelser og labs, og vælg derefter en læringsvej som selvstudie, kursus eller uddannelsesfag afhængigt af din tid og dit mål. Tænk 30 dage ad gangen i stedet for at ville lære “alt sikkerhed” på én gang.

Forudsætninger: hvad skal du kunne først?

Videregående IT-sikkerhed bygger oven på et basisniveau. Du får langt mere ud af et fag eller kursus, hvis du allerede:

• kan programmere fornuftigt i mindst ét sprog (fx Java, C#, JavaScript, Python)
• har bygget simple webapps eller API’er før
• kender helt basal IT-sikkerhed (begreber som firewall, kryptering, phishing, adgangskoder)
• forstår HTTP, cookies, sessions og simple database-queries

Hvis de ting halter, er det ofte bedre at styrke dem først og så tage fat i videregående sikkerhed bagefter.

En realistisk 30-dages startplan

Her er en simpel plan, du kan bruge som skabelon. Tænk 30 dage med 3-5 timers fokus om ugen.

1. Uge 1: Få overblik og fokus
   Lav en liste over de vigtigste systemer og data, du arbejder med. Hvilke er mest kritiske, hvis de lækker eller bliver utilgængelige? Læs en kort introduktion til OWASP Top 10, så du får et sprog for de typiske web-sårbarheder.
2. Uge 2: Autentificering, autorisation og sessions
   Sæt dig ind i forskellen på autentificering (hvem er du) og autorisation (hvad må du). Læs om gode auth-valg, fx via de vigtigste valg i din auth-løsning. Kig kritisk på, hvordan du gemmer tokens i dag og undgå mønstre som JWT i localStorage uden omtanke.
3. Uge 3: Spil med i labs
   Brug gratis sikkerhedslabs som OWASP Juice Shop eller WebGoat. Følg et par konkrete “challenges”, hvor du både udnytter og retter sårbarheder. Det føles lidt kaotisk første gang, men det gør dig skarp på, hvordan fejl i koden bliver til reelle angreb.
4. Uge 4: Lidt secure coding og pipeline
   Tag et lille projekt, fx et simpelt API, og arbejd bevidst med inputvalidering, logging og rate limiting. Hvis du bygger i Node, kan du fx starte med at tilpasse et projekt som et lille Express API, så det håndterer fejl og input mere robust. Kig også på din CI: kan du tilføje bare én simpel sikkerhedsscan, så du får et første DevSecOps-skridt?

Efter de første 30 dage har du et bedre grundlag for at vurdere, om du vil investere i et kursus eller et videregående fag, og hvad du vil have ud af det.

Hvilke sikkerhedsområder skal udviklere kunne først?

De vigtigste sikkerhedsområder for udviklere er adgangskontrol (auth/autorisation), input- og output-sikkerhed, korrekt brug af kryptografi, logging og monitorering, API-sikkerhed, sikker CI/CD og grundlæggende incident readiness. Du bliver sjældent ekspert i alle, men du bør forstå dem godt nok til at træffe sikre valg i din egen kode og arkitektur.

1. Adgangskontrol: autentificering og autorisation

Adgangskontrol er kernen i applikationssikkerhed. Hvis den er svag, hjælper resten ikke meget.

• Autentificering: Hvordan brugere, systemer eller integrationer beviser, hvem de er (brugernavn/password, OAuth2, OpenID Connect, API-nøgler, m.m.).
• Autorisation: Hvad de må gøre bagefter (roller, rettigheder, scopes, policies).
• Least privilege: Giv kun den adgang, der er nødvendig, og ikke mere.
• Session- og token-sikkerhed: Hvordan du gemmer og fornyer tokens uden at åbne for nem tyveri.

Det er værd at fordybe sig i auth-design, fx via artikler om konsekvenserne af dine loginvalg over tid og konkrete anti-mønstre som tokens der ender tilfældige steder i webappen.

2. Inputvalidering og output encoding

Rigtig meget misbrug sker via input, du ikke havde tænkt for alvor over. Praktisk betyder det, at du:

• validerer alt input ved kanten af din applikation (både fra forms, API-kald og webhooks)
• bruger whitelisting, hvor det giver mening (hvad må feltet indeholde?)
• anvender parameteriserede queries mod databasen, ikke string-concat SQL
• encoder output korrekt til den kontekst, det ender i (HTML, JavaScript, SQL, logs osv.)

Hvis du arbejder med SQL, kan du med fordel se på, hvordan performance og sikkerhed hænger sammen, fx i artikler som din SQL er ikke langsom, den er bare ærlig og hvordan struktur kan beskytte mod brute-force-scanning i SQL-indeks vs brute force.

3. Kryptografi på udviklerniveau

Du behøver sjældent opfinde egne algoritmer, men du bør forstå de grundlæggende byggesten nok til at bruge dem rigtigt:

• forskellen på hashing (fx til passwords) og kryptering (til data, der skal kunne dekrypteres)
• symmetrisk vs asymmetrisk kryptering og typiske use cases
• betydningen af nøgler, initialization vectors, salt og nøgle-rotation
• hvor du ikke skal bruge kryptografi, fx “rulle din egen” encoding som falsk sikkerhed

En stor del af kryptografi i praksis handler om at håndtere secrets sikkert: API-nøgler, tokens, certifikatnøgler osv. Her er det værd at kigge på, hvorfor secrets skal være kedelige og velplacerede i miljøvariabler og vaults, fx i secrets skal være kedelige, ikke spændende og artikler om sikker opbevaring af API-nøgler.

4. Logging, monitorering og incident readiness

God logging er både et udviklerværktøj og en sikkerhedskontakt. Du bør kunne:

• logge nok til at forstå, hvad der sker (uden at logge følsomme data unødigt)
• skelne mellem tekniske fejl og mulige angreb (bruteforce, usædvanlige mønstre, m.m.)
• designe logs, så de kan bruges i efterforskning og incident response

Hvis du er vant til mavefornemmelse, er det værd at se på, hvordan struktureret logging og observability næsten altid vinder, fx i logs vs mavefornemmelse.

5. API-sikkerhed, webhooks og CORS

De fleste moderne systemer taler sammen via API’er og webhooks. Her er fokusområderne:

• stærk autentificering og autorisation for både brugere og systemer
• rate limiting og abuse-beskyttelse, fx via mønstrene i rate limiting i praksis
• sikker håndtering af webhooks, inkl. signaturvalidering, som vist i robuste webhook-endpoints og forståelse af webhook-signaturer
• korrekt CORS-konfiguration og fejlfejlsøgning, se fx CORS-fejl uden panik

6. CI/CD, secrets og DevSecOps

Når du først har styr på kode, auth og API’er, er næste skridt at få sikkerhed ind i din pipeline:

• integrer SAST (statisk kodeanalyse) og SCA (dependency scanning) i CI, så kendte sårbarheder fanges tidligt
• brug secret scanning, så API-nøgler og tokens ikke ryger i git-repoer (og lad være med at gemme dig bag “kedelige GitHub-links”, jf. eksponerede repo-links)
• håndter miljøvariabler og konfiguration ordentligt, fx undgå typiske faldgruber som i ødelagte miljøvariabler allerede i dev og brug tag-siden miljøvariabler som hub for videre læsning
• tænk små, sikre CI-skridt, fx med inspiration fra lille CI, stor forskel

På lidt større systemer giver det også mening med WAF (web application firewall), request limiters og eventuelt CDN med sikkerhedsfunktioner, men det er ofte noget, du planlægger sammen med drift.

Hvordan hænger NIS2, GDPR og udviklerens arbejde sammen?

NIS2 og GDPR er ikke “udviklerlove”, men de påvirker, hvordan du designer, udvikler, tester og dokumenterer software i organisationer, der er omfattet. I praksis betyder det, at flere sikkerhedskrav flytter helt ind i koden, testene og din daglige pipeline, ikke kun i en sikkerhedspolitik på intranettet.

Hvad betyder NIS2 for din kode?

NIS2 retter sig mod samfundskritiske og vigtige sektorer, men mange af de tekniske krav ligner god praksis for alle:

• sikker udvikling som en del af SDLC (software development life cycle)
• logning og detektion, så hændelser kan opdages og håndteres
• patching og opdateringer af komponenter, frameworks og afhængigheder
• adgangsstyring og principper som least privilege i både kode og infrastruktur

Som udvikler betyder det typisk, at du bliver bedt om at arbejde mere systematisk med secure coding, dependency scanning, dokumentation af sikkerhedskrav og test. For en bredere forståelse af governance og praksis kan du se guiden om IT- og cybersikkerhed i praksis for udviklere og teams.

GDPR og privacy by design i praksis

GDPR handler ikke kun om cookie-bannere. For udviklere viser den sig især som:

• data-minimering: du indsamler og gemmer kun de persondata, du faktisk har brug for
• privacy by design: krav til anonymisering, pseudonymisering og datadeling indarbejdes i designet
• sikre testdata: du bruger ikke produktionspersondata i testmiljøer uden stærke kontroller
• rettigheder: systemerne skal understøtte sletning, indsigt og rettelse af data uden manuelle nødoperationer

Du behøver ikke være jurist, men du skal kunne oversætte sikkerheds- og databeskyttelseskrav til konkrete løsninger i databasedesign, logging og API’er.

Typiske udvikler-artefakter i en compliant praksis

I mere modne organisationer bliver du ofte bedt om at levere eller bidrage til ting som:

• sikkerhedskrav til nye features (fx særlige auth-krav, loggingkrav, dataflow)
• beskrivelser af arkitektur og dataflow, inkl. hvor data opbevares
• testcases og testspor for sikkerhedsrelaterede tests
• log-strategi (hvad logges, hvor længe, og hvordan det beskyttes)
• risikovurderinger på nye integrationer eller større ændringer

Når du har styr på de tekniske grundprincipper, bliver den del langt mindre skræmmende, fordi du kan se sammenhængen mellem kravene og det, du alligevel ville gøre for at få et robust system.

Hvilke værktøjer og teknologier bør du kende?

Du behøver ikke kende alle sikkerhedsværktøjer på markedet, men du bør kende de vigtigste kategorier: værktøjer der scanner kode og afhængigheder, værktøjer der tester apps udefra, og værktøjer der hjælper dig med logging, secrets og container-sikkerhed. Målet er, at du ved, hvad der findes, og hvornår det giver mening at tage dem i brug.

Værktøjer til kode og afhængigheder

• SAST (Static Application Security Testing): analyserer din kildekode for kendte mønstre af sårbarheder. Eksempler kan være værktøjer som Semgrep.
• SCA (Software Composition Analysis): scanner dine libraries og dependencies for kendte CVE’er, fx Dependabot eller tilsvarende.
• Secret scanning: finder API-nøgler, tokens og passwords i kodebasen eller historikken.

Den typiske praksis er at lade disse værktøjer køre som en del af din CI, gerne med et fornuftigt støjniveau, så det ikke drukner jer i falske positive.

Værktøjer til runtime-tests

• DAST (Dynamic Application Security Testing): tester en kørende applikation udefra, fx med OWASP ZAP som et gratis værktøj.
• Proxy-værktøjer som Burp Suite: lader dig inspicere og manipulere trafik mellem klient og server, nyttigt både til læring og test.

Disse værktøjer er gode at bruge i kontrollerede testmiljøer, hvor du har lov til at angribe din egen applikation. De er også oplagte til at øve på sikkerhedslabs.

Værktøjer til drift og container-sikkerhed

• Container scanning (fx Trivy): tjekker images for kendte sårbarheder og dårlige konfigurationer.
• Logs og observability: centraliserede logløsninger, metrics og alerts gør det muligt at se mønstre i både fejl og angreb.
• WAF/CDN: ligger typisk foran din applikation og filtrerer ondsindet trafik, ofte sat op sammen med drift.

Hvis du er ny i det her, er et godt mål det næste år at få bare én SAST- eller SCA-scan i jeres CI, én runtime-test i et testmiljø og én forbedring af logging på et kritisk endpoint.

Hvilken læringsvej inden for IT-sikkerhed skal du vælge?

Der er fire hovedveje ind i videregående IT-sikkerhed for udviklere: selvstudie, korte kurser, længere forløb/uddannelsesfag og bøger/ressourceværker. Hvad der er bedst, afhænger af din tid, dit budget og hvad du vil bruge kompetencerne til. Ofte ender den bedste løsning som en kombination.

Selvstudie, kurser, uddannelse og bøger i grove træk

Typiske prisniveauer for kurser ligger fra omkring 3.000-6.500 kr. ekskl. moms for en kort introduktion, over 6.800-16.900 kr. for 1-3 dages secure-coding-forløb, til 20.000-40.000 kr. for længere specialistforløb. De tal er vejledende og afhænger af udbyder, niveau, format og om der er eksamen.

Hvad lærer du realistisk på 1 dag, 3 dage og længere forløb?

En pragmatisk kombi-strategi

En strategi, der fungerer godt for mange udviklere, ser nogenlunde sådan ud:

• brug 1-3 måneder på målrettet selvstudie og labs omkring OWASP Top 10, auth og API-sikkerhed
• tag derefter et kort kursus eller et videregående fag, når du ved, hvilke spørgsmål du har, og hvad du vil have ud af det
• brug en eller to bøger/ressourceguides som rygrad, mens du fortsætter med at omsætte tingene i din egen kodebase

Hvis du vil have et mere bredt overblik over indhold om it-sikkerhed til udviklere, kan du bruge kategorien IT-sikkerhed for udviklere som hub og gå videre ind i fx CSP, webhook-sikkerhed eller konkrete auth-valg.

Hvad er et fornuftigt næste skridt herfra?

Hvis jeg selv skulle starte i dag med det niveau, jeg havde efter et par års udvikling, ville jeg:

1. lave en lille liste over de mest kritiske systemer og data, jeg arbejder med
2. læse en overskuelig guide om OWASP Top 10 og auth-valg, fx auth-valg der bider dig senere
3. bygge eller tage et eksisterende lille API og gøre det mere robust med bedre inputvalidering, logging og simpel rate limiting
4. tilføje én sikkerhedsscan i min CI, fx dependency scanning
5. efter 1-2 måneder beslutte, om jeg vil sætte penge og tid af til et kursus eller et videregående fag, og hvad formålet er

Det behøver ikke være dramatisk eller perfekt fra dag ét. Det vigtige er, at du begynder at se sikkerhed som en del af den måde, du skriver og deployer kode på, ikke som et separat punkt til sidst.