Et team på fem udviklere får ikke en sikkerhedsafdeling, og det behøver heller ikke en. Sikker softwareudvikling betyder her, at de rutiner, I allerede har, får et lille sikkerhedsled: et spørgsmål, når en funktion planlægges, et punkt i kodegennemgangen, en automatisk kontrol, før koden udgives, og en fast måde at modtage meldinger om fejl på. Den opgave, der kræver ledelse, er at beslutte, hvilke vaner der gælder, og at give dem tid i planen. Som stifter eller direktør behøver I ikke at kunne læse koden for at stille kravene.
Start i de rutiner, I allerede har
Mange små teams begynder det forkerte sted, med en lang politik eller et dyrt værktøj. Se i stedet på de fire steder, hvor koden passerer gennem hænderne på nogen: planlægningen, skrivningen, gennemgangen og udgivelsen. Mangler de steder, så begynd der, for sikkerhed kan ikke hænge på en proces, der ikke findes. En udviklingsproces, der passer til fem udviklere beskriver det mindste sæt.
Ved planlægningen stiller I tre spørgsmål til alt, der rører login, rettigheder, betaling eller kundedata. Hvem må bruge funktionen? Hvad sker der, hvis nogen misbruger den? Hvilke data flytter sig? Det kaldes ofte trusselsmodellering, altså at tænke som en angriber, før noget er bygget. I et lille team er det ti minutter ved tavlen. Svarene skrives ned i opgaven.
Ved skrivningen bruger I de sikre standardløsninger, som jeres sprog og rammeværk tilbyder til login, databaseforespørgsler og håndtering af input. Hjemmelavet kryptering og hjemmelavet login er næsten altid et dårligt valg i et lille team.
Ved kodegennemgangen får den, der gennemgår, en kort liste. Er rettigheder tjekket på serveren, også når brugerfladen skjuler knappen? Kan én kunde komme til en andens data? Ligger der nøgler i koden? Skrives der følsomme oplysninger i loggen?
Ved udgivelsen kører automatiske kontroller, der stopper eller markerer kendte problemer. Det dækker sårbare biblioteker, hemmeligheder i koden og simple kodefejl. Hvordan I styrer bibliotekerne, står i tredjepartsbiblioteker, SBOM og byggepipeline, og nøglerne i nøgler og adgangskoder i koden og pipelinen.
Hvad OWASP kan bruges til
OWASP er en international nonprofit-organisation, der udgiver åbent materiale om sikkerhed i webapplikationer. Tre af deres udgivelser er nyttige for et lille team, og de bruges bedst til hvert sit formål.
- OWASP Top 10 er en liste over de mest kritiske risikotyper i webapplikationer. Den egner sig som fælles sprog og som grundlag for den korte liste i kodegennemgangen.
- OWASP ASVS er en standard med krav, der kan testes. Den er nyttig, når en kunde spørger, hvad I måler jer op imod, eller når I vil skrive sikkerhedskrav ind i en opgave.
- OWASP SAMM er en modenhedsmodel. Den hjælper jer med at se, hvor I står, og hvad næste skridt er, når teamet vokser.
Top 10 er en liste til at skabe opmærksomhed og ingen fuld kravspecifikation. En afkrydset liste viser, at I har taget stilling til de almindeligste fejl. Den siger intet om resten af produktet.
Hvad der skal være besluttet af en person
Noget kan et værktøj ikke klare. Der skal være en navngiven person, der ejer sikkerheden i produktet. I et lille team er det ofte lead developeren eller den tekniske stifter, og det skal stå et sted. Det er noget andet end at eje virksomhedens samlede sikkerhedsarbejde, som er en ledelsesopgave, hvor sikkerhed ved anskaffelse og udvikling ser på sagen fra direktionens side.
Tre beslutninger bør træffes af ledelsen og skrives ned:
- Hvor meget tid der er afsat til sikkerhedsrettelser, så de ikke altid taber til nye funktioner.
- Hvad der stopper en udgivelse. En kritisk sårbarhed i et bibliotek, der kan nås fra internettet, bør stoppe den. En advarsel i et testværktøj bør ikke.
- Hvor hurtigt alvorlige fejl skal rettes, og hvem der må give en undtagelse.
Når nogen melder en fejl
Før eller siden skriver en kunde eller en fremmed, at de har fundet et hul. Hav en fast adresse til det, et svar, der kommer hurtigt, og en person, der vurderer meldingen. Det koster næsten ingenting at sætte op og er også starten på det, Cyber Resilience Act kræver af fabrikanter. Er jeres produkt omfattet, gælder der frister, som står i 24 timer til ENISA. Selv hvis det står uden for, vil de store kunder spørge til det.
Tegn på, at vanerne ikke virker
- Sikkerhedsopgaver bliver skubbet fra sprint til sprint uden en beslutning.
- Ingen kan sige, hvornår bibliotekerne sidst blev opdateret.
- Kodegennemgangen er et hurtigt godkendt uden spørgsmål.
- Alle udviklere kan nå produktionsdata fra egen maskine.
- Kunden får et andet svar om sikkerhed, alt efter hvem der svarer.
Det skal I lade være med
- At købe et værktøj, før vanerne er der · et værktøj, ingen læser resultaterne fra, giver en falsk tryghed.
- At gøre sikkerhed til én persons hobby · den ansvarlige skal have tid i planen.
- At vente med sikkerhed til efter lanceringen · login og kundeadskillelse er dyre at lave om, når kunderne er kommet ind.
Det skal I kræve af den eksterne
- ☐ En kort beskrivelse af de sikkerhedsvaner, der gælder i teamet.
- ☐ En navngiven ejer af sikkerheden i produktet.
- ☐ Klare regler for, hvad der stopper en udgivelse.
- ☐ En afsat del af kapaciteten til sikkerhedsrettelser, synlig i køreplanen.
- ☐ En fast vej for meldinger om sårbarheder.
Kilder
- OWASP Top 10: liste over de mest kritiske risikotyper i webapplikationer.
- OWASP Application Security Verification Standard: testbare sikkerhedskrav.
- OWASP SAMM: modenhedsmodel for sikker softwareudvikling.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Eftersyn af AI-genereret kode før lancering · Hver release er en risiko
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
