Sikkerhed behøver ikke være den mur, der vælter jeres sprintplan.
Hvis du sidder i et agilt team, kender du dilemmaet: I vil levere hurtigt, men I ved også, at én overset sårbarhed kan koste dyrt i drift, brand og tid. Denne artikel viser, hvordan I integrerer sikkerhed i agile arbejdsgange uden at gøre udviklingsprocessen tung og langsom.
Du får en praktisk model, konkrete teknikker (fra backlog til CI/CD), eksempler på “hvad gør vi i sprinten?”, samt typiske faldgruber og hvad det typisk koster i tid og ressourcer. Målet er, at sikkerhed bliver en del af flowet—ikke en stopklods.
Hvad betyder “security i agile teams” egentlig, og hvorfor er det vigtigt?
Når vi taler om sikkerhed i agile teams, mener vi i praksis: at sikkerhedskrav, trusselsforståelse, test og kontrolpunkter er indbygget i teamets normale rytme (backlog, sprint, CI/CD og release), så risiko opdages tidligt og håndteres løbende.
Definition: DevSecOps (og “shift left security”) er en tilgang, hvor sikkerhed integreres i hele softwareudviklingslivscyklussen, så sårbarheder forebygges og findes tidligt, mens omkostningen ved at rette dem stadig er lav.
Det betyder noget, fordi fejl er billigere at rette, jo tidligere de opdages. I min erfaring fra teams med hyppige releases er forskellen tydelig: en sårbarhed fanget i pull request kan koste 10–30 minutter at rette; samme sårbarhed opdaget efter release kan koste dage, fordi du får incident-håndtering, hotfix, kommunikation og ofte “hvorfor opdagede vi det ikke?”-arbejde oveni.
Mini-konklusion: Sikkerhed i agile teams handler ikke om mere proces—det handler om bedre timing og bedre standarder.
Hvorfor sikkerhed ofte føles som friktion i agile processer
Når sikkerhed føles tung, skyldes det sjældent sikkerhed i sig selv. Det skyldes, at den kommer ind for sent, er for ukonkret, eller bliver “lagt ovenpå” som en kontrolfunktion.
De typiske årsager til modstand
- Uklare krav: “Gør det sikkert” er ikke et acceptkriterie.
- Sent feedback-loop: Penetrationstest til sidst i projektet skaber stop-and-fix.
- Ejerskab uden mandat: Ingen i teamet føler ansvar, men alle er afhængige af “security-teamet”.
- For mange værktøjer: Støj fra scanninger uden prioritering skaber alarmtræthed.
- Manglende standarder: Hver gang I diskuterer fra nul, bliver det langsomt.
En mere realistisk målsætning end “100% sikker”
Ingen leverer perfekt sikkerhed. Et bedre mål er at reducere risiko kontinuerligt: færre kritiske findings, kortere tid fra fund til fix, og mindre variation i kvaliteten mellem teams. Når målet bliver målbart, bliver det lettere at gøre det agilt.
Mini-konklusion: Friktion opstår, når sikkerhed er en begivenhed. Agile teams har brug for sikkerhed som en vane.
Design princip: Gør sikkerhed til en del af flowet, ikke en gate
Den mest effektive ændring, jeg har set i agile miljøer, er at flytte fra “sikkerhedsgodkendelser” til “sikkerhedsstandarder”. Standarder kan automatiseres og gentages, og de kan integreres i Definition of Done.
Praktisk betyder det, at I arbejder med små, hyppige sikkerhedstjek:
- Enkle krav i backloggen (konkrete og testbare).
- Trusselsgennemgang i mini-format, når I starter på nye flows.
- Automatiserede scanninger ved hver commit/PR.
- Fast triage-rutine for findings (hvad blokerer, hvad planlægges).
- Små hardening-tiltag som standard (headers, rate limiting, secrets-håndtering).
- Regelmæssige læringsloops (retros + få faste metrics).
Det er her, mange teams oplever, at “sikkerhed” ikke længere er et separat spor. Det bliver et kvalitetsniveau, der følger jeres leverancetakt.
Mini-konklusion: Hvis jeres sikkerhed kun lever i et review-møde, bliver den altid en flaskehals.
Backlog og sprint: Sådan omsætter I sikkerhed til konkrete user stories
Sikkerhed er nemt at overse, når det ikke er synligt i backloggen. Et simpelt greb er at arbejde med sikkerhed som acceptkriterier på funktionelle stories—og som egne tasks, når der er reelt arbejde.
Eksempler på gode acceptkriterier
Her er formuleringer, jeg har haft succes med i agile teams, fordi de kan testes og diskuteres konkret:
- Adgangskontrol: “Kun rolle X kan tilgå endpoint Y; forsøg uden rettighed giver 403 og logges.”
- Inputvalidering: “Alle felter valideres server-side; fejl returnerer generiske beskeder uden interne detaljer.”
- Rate limiting: “Maks 10 loginforsøg pr. minut pr. IP; efter 5 fejl trigges cooldown.”
- Secrets: “Ingen secrets i repo; nøgler lever i vault/secret manager og roteres hver 90. dag.”
- Logging: “Sikkerhedshændelser logges med correlation-id; ingen personfølsomme data i logs.”
“Security tasks” uden at sprænge sprinten
En praktisk tommelfingerregel: Hvis et sikkerhedsarbejde tager under 1–2 timer, læg det som en subtask på story’en. Hvis det er større (fx refaktorering af auth eller introduktion af CSP), så lav en selvstændig story og prioriter den synligt. Det reducerer risikoen for, at sikkerhed bliver “det vi gør, når der er tid”.
I mange organisationer fungerer det godt at reservere en lille kapacitet pr. sprint (fx 5–15%) til sikkerhedsgæld og hardening. Det er ikke en regel for alle, men det er et realistisk kompromis, når I har legacy og drift i ryggen.
Mini-konklusion: Sikkerhed bliver agil, når den er estimerbar, testbar og prioriteret på samme måde som funktionalitet.
Automatisér det kedelige: CI/CD-sikkerhed der ikke bremser jer
Automatisering er nøglen til at holde tempo. Det handler ikke om at køre “alle scanninger altid”, men om at vælge de rigtige checks og sætte passende tærskler, så I får signal frem for støj.
Et pragmatisk baseline-setup
- SAST på pull requests for de mest kritiske patterns (fx injection, deserialization).
- Dependency scanning (SCA) med policy: blokér kun kendte kritiske CVE’er med exploit i jeres kontekst.
- Secrets scanning (pre-commit og i pipeline) for at stoppe nøglelæk tidligt.
- IaC scanning hvis I bruger Terraform/Kubernetes, så misconfigurations fanges før deploy.
- Container scanning af base images, især hvis I deployer ofte.
En vigtig detalje: Sæt en “fast lane” for udviklere. Hvis en scanning tager 20 minutter, bliver den ignoreret. Mange teams rammer et godt niveau ved at holde PR-checks under 5–8 minutter og flytte dybere scanninger til nightly builds.
Hvis du vil have et samlet overblik over, hvordan man strukturerer praksissen på tværs af backlog, pipeline og releases, kan du tage udgangspunkt i Secure SDLC i agile teams og tilpasse det til jeres modenhed og risikoprofil.
Mini-konklusion: Automatisér det gentagelige, og gør det hurtigt nok til at udviklere faktisk bruger det.
Threat modeling i mini-format: 30 minutter der sparer dage
Trusselsmodellering lyder tungt, men det behøver det ikke være. I agile teams fungerer “lightweight threat modeling” bedst: kort, fokuseret og gentaget, når I introducerer nye flows eller ændrer risiko.
Sådan gør I det i et sprint-planning-møde
- Hvad er aktivet? (fx betalingsflow, persondata, admin-funktion)
- Hvem er angriberen? (script kiddie, kunde, insider, botnet)
- Hvad er de 3 mest sandsynlige angreb? (credential stuffing, IDOR, injection)
- Hvad er konsekvensen? (tab af data, driftstop, misbrug)
- Hvilke kontroller vælger vi nu? (auth, rate limit, logging, validation)
Det er ikke en akademisk øvelse. Det er en beslutningsmotor, der hjælper jer med at bruge tid på de rigtige kontroller. Jeg har set teams spare mange timer ved at fange “vi mangler rate limiting” eller “den her endpoint kræver objekt-niveau autorisation” før implementeringen er færdig.
Mini-konklusion: Mini threat modeling giver jer retning—og forhindrer dyre ombygninger efter release.
Definition of Done og “security champions”: Gør det til teamets standard
Hvis sikkerhed kun bor hos én person, bliver det sårbart. Hvis sikkerhed bor i teamets standarder, bliver det skalerbart. Her er to greb, der virker i praksis: en sikkerheds-Definition of Done og en “security champion”-rolle.
Eksempel på sikkerheds-DoD (hold den kort)
- AuthN/AuthZ er implementeret og testet (inkl. negative tests).
- Ingen secrets i kode eller CI-logs.
- Dependencies er opdateret inden for policy; kritiske CVE’er håndteres.
- Security-relevante events logges uden følsomme data.
- Automatiske checks i pipeline er grønne eller har godkendt undtagelse.
Hvad laver en security champion (uden at blive en flaskehals)?
En security champion er ikke en gatekeeper. Rollen fungerer bedst som facilitator: hjælper teamet med triage, oversætter sikkerhedskrav til udviklingsopgaver, og holder styr på standarder. Typisk 1–3 timer om ugen pr. team kan gøre en mærkbar forskel, hvis det kombineres med gode værktøjer og en enkel DoD.
Mini-konklusion: Når sikkerhed bliver en del af DoD, bliver det “sådan vi arbejder”—ikke ekstra arbejde.
Hvad koster det at gøre sikkerhed agilt? (tid, penge og tradeoffs)
Spørgsmålet kommer altid: Hvad koster det? Det mest ærlige svar er: mindre end at lade være, men mere end nul. I agile teams bør du tænke i løbende investering frem for store projekter.
Som rettesnor ser jeg ofte disse niveauer:
- Let niveau: 0,5–1 dag for at få basic secrets scanning og dependency scanning i gang, plus lidt justering af pipeline.
- Mellem niveau: 2–5 dage for at få SAST/SCA/IaC, triage-flow og en sikkerheds-DoD på plads, afhængigt af stack og CI/CD.
- Modent niveau: Løbende 5–15% kapacitet i en periode, hvis der er legacy, auth-gæld eller større hardening (fx CSP, zero trust, segmentering).
Det vigtige er tradeoff’et: I bytter lidt udviklingstid nu for færre afbrydelser senere. Sikkerhed, der er integreret, reducerer også “kontekstskift-omkostning”—det vil sige den tid, teamet mister, når de må stoppe alt for at håndtere en akut sårbarhed.
Mini-konklusion: Agile sikkerhed koster typisk mest i starten—og betaler sig ved færre stop-the-line-episoder.
De mest almindelige faldgruber (og hvordan I undgår dem)
Selv gode intentioner kan give dårlig effekt, hvis implementeringen bliver forkert. Her er faldgruber, jeg ser igen og igen, plus konkrete modtræk.
- “Vi scanner alt” og drukner i findings: Start med høj signalværdi og blokér kun det, der reelt er kritisk.
- Security som separat backlog der aldrig prioriteres: Bind sikkerhed til features via acceptkriterier og DoD.
- For mange undtagelser uden udløbsdato: Indfør “exception expiry” og gør det synligt i backloggen.
- Ingen ejer triage: Giv champion/tech lead ansvar for ugentlig gennemgang og prioritering.
- Falsk tryghed fordi “pipeline er grøn”: Kombinér automatisering med enkel trusselsgennemgang og manuelle checks ved højrisiko-ændringer.
- For sent fokus på drift: Tænk logging, monitoring og incident-respons ind tidligt, ellers bliver fejl dyre at finde.
Hvis I retter bare to af disse, vil I typisk opleve mindre friktion og mere forudsigelig kvalitet allerede inden for 2–3 sprints.
Mini-konklusion: Det er sjældent værktøjerne, der fejler—det er prioritering, ejerskab og signal-støj-forholdet.
Best practices: En 30-dages plan til at komme i gang uden at sænke tempoet
Hvis du skal omsætte det her til handling, så gør det iterativt. Her er en enkel plan, der typisk passer ind i agile teams uden store omvæltninger.
Uge 1: Synliggør og standardisér
- Lav en kort sikkerheds-DoD (maks 5 punkter).
- Tilføj 2–3 sikkerheds-acceptkriterier på relevante stories.
- Udpeg en security champion (midlertidigt, roter evt. hver 2–3 måneder).
Uge 2: Automatisér det lavthængende
- Slå secrets scanning til (pre-commit + pipeline).
- Slå dependency scanning til med fornuftig policy.
- Definér triage: Hvem kigger på findings, hvornår, og hvad blokerer?
Uge 3–4: Skærp feedback-loop og håndtér risiko
- Indfør mini threat modeling for nye flows (30 min).
- Tilføj SAST på PRs og flyt dybere scanninger til nightly.
- Vælg 1 konkret hardening-forbedring (fx rate limiting eller bedre logging) og lever den.
Pointen er, at I løfter sikkerhed i små inkrementer og lærer, hvad der virker i jeres kontekst. Det er præcis den agile måde at gøre det på.
Mini-konklusion: En måned med små, målrettede skridt kan flytte jer fra ad hoc-sikkerhed til en stabil, agil praksis.
