Secure SDLC i en agil DevOps-kontekst handler om at bygge sikkerhed ind i måden, I planlægger, koder, tester og releaser på, uden at tempoet dør. I denne artikel får du en praktisk reference-implementation, der kan bruges som skabelon: hvad I gør i Sprint 0, hvad der kører i hvert sprint, og hvad der skal være på plads ved release.
Du får også klare rollebeskrivelser, konkrete CI/CD “gates” der kan automatiseres, typiske faldgruber, og til sidst en minimum viable Secure SDLC i 10 punkter, der passer til compliance-arbejde under CRA. Målet er ikke mere proces for processens skyld, men færre overraskelser og hurtigere, mere robust levering.
Hvad er Secure SDLC, og hvorfor betyder det noget i DevOps?
Secure SDLC (Secure Software Development Lifecycle) er en struktureret tilgang til at indbygge sikkerhedskrav, kontroller og evidens i hele udviklingslivscyklussen, fra idé til drift. Pointen er at fange fejl tidligt: en sårbarhed rettet i design eller pull request koster typisk langt mindre end en rettelse efter release, hvor der også er kunder, drift og omdømme i spil.
I agile teams bliver sikkerhed ofte misforstået som et sent “security review”. En DevOps-tilpasset Secure SDLC flytter i stedet sikkerhed ind i backlog, definitioner, automatiske tests og release-artefakter. Det gør sikkerhed målbar, gentagelig og kompatibel med høj leverancefrekvens.
Hvad får virksomheden ud af det?
Du reducerer risikoen for kendte sårbarheder i dependencies, lækkede secrets og fejlkonfigureret cloud/IaC, og du får bedre sporbarhed: hvorfor en ændring blev godkendt, hvilke kontroller der kørte, og hvad status var på kendte issues ved release. Det er præcis den type evidens, som både kunder, audit og interne risikofunktioner efterspørger.
Hvad koster det i praksis?
Omkostningen ligger primært i opsætning og løbende vedligehold af pipelines, regler og triage. Mange teams kan starte med eksisterende værktøjer og open source, men der er en reel tidsinvestering: typisk 1–3 uger for en første baseline i én applikation, og derefter løbende 5–15% af en udviklers tid på tværs af teamet til håndtering af findings, afhængigt af modenhed og kompleksitet.
Mini-konklusion: Secure SDLC er billigst, når det er standardiseret og automatiseret, ikke når det er et manuelt stop-signal til sidst.
Sprint 0: Politikker, DoR/DoD og cadence for threat modeling
Sprint 0 er stedet, hvor I gør sikkerhed konkret og anvendelig. Det er ikke et “forprojekt”, men en kort etablering af fælles spilleregler: hvad betyder “secure enough” for jeres produkt, og hvordan passer det ind i agile leverancer?
Politikker, der kan omsættes til praksis
Start med få, klare politikker, der kan håndhæves i tooling. Eksempler: krav om code review, krav til dependency-opdateringer, krav om secrets-håndtering, og krav til signering af builds. Hold dem korte, og bind dem til konkrete kontroller i pipeline og repo-indstillinger.
Definition of Ready og Definition of Done med sikkerhed
Udvid DoR/DoD, så sikkerhed ikke bliver en “ekstra opgave”. DoR kan kræve, at stories med ny dataflow eller nye integrationspunkter har en kort risikovurdering. DoD kan kræve, at relevante sikkerhedstests er kørt, og at findings er triageret efter aftalte SLA’er.
- DoR: acceptkriterier inkluderer sikkerhedskrav for autentifikation, autorisation og logging
- DoR: ændringer i netværk, IAM eller API-kontrakter kræver opdateret trusselsmodel
- DoD: SAST og dependency scanning er grønne eller har godkendt undtagelse
- DoD: secrets scanning viser ingen nye læk
- DoD: IaC scanning er grøn for “high/critical” regler
- DoD: sikkerhedschampion har lavet letvægts-review af risikable ændringer
Planlæg også en fast cadence for threat modeling: fx ved større epics, nye eksterne integrationer, eller hvert N’te sprint for kritiske systemer. Cadence slår ambitioner; hellere 45 minutter hver anden uge end en stor workshop, der aldrig sker.
Mini-konklusion: Sprint 0 lykkes, når politikker kan måles i pipeline, og DoR/DoD gør sikkerhed til en del af “normal done”.
Roller og ansvar: Hvem gør hvad i et Secure SDLC-setup?
Secure SDLC falder ofte sammen, fordi “security” bliver alles og ingens ansvar. En reference-implementation bør derfor beskrive tydelige roller, der matcher agile teams og DevOps.
Product owner prioriterer sikkerhedsarbejde i backloggen, når det reducerer risiko eller er nødvendigt for compliance og kundekrav. PO sikrer også, at ikke-funktionelle krav som logging, rate limiting og patching bliver formuleret som leverbare resultater, ikke som løse ønsker.
Dev lead ejer teknisk kvalitet i teamet: kodestandarder, review-praksis, arkitekturvalg og håndtering af tech debt. Dev lead er også typisk den, der afgør, om et pipeline-fail er en reel blokering eller en falsk positiv, og sørger for at forbedre reglerne.
Security champion er teamets nærmeste sikkerhedskompetence. Champions driver threat modeling, hjælper med triage, og oversætter sikkerhedskrav til konkrete tasks. Rollen er ikke en “mini-CISO”, men en praktisk bro mellem udvikling og sikkerhedsfunktion.
Platform/DevOps bygger og vedligeholder standardpipelinen: skabeloner, runner-hardening, secrets management, artifact signing og central rapportering. De skal gøre det let at gøre det rigtige, og svært at gøre det forkerte.
Mini-konklusion: Når ansvaret er tydeligt, kan I automatisere mere og diskutere mindre ved hvert fund.
Sprint-loopet: Secure coding checks, PR-gates og dependency scanning
I sprint-loopet handler Secure SDLC om korte feedback-sløjfer. Målet er, at udvikleren opdager problemer, mens konteksten stadig er frisk, og at teamet får konsistent håndhævelse via pull requests og CI.
Secure coding checks i hverdagen
Start med “shift-left” på en realistisk måde: linting for sikkerhedsmønstre, skabeloner til input-validering, centrale auth-komponenter, og standardbiblioteker til kryptering i stedet for hjemmelavede løsninger. Træn teamet i de mest sandsynlige fejltyper: injection, broken access control, SSRF og fejl i sessionhåndtering.
PR-gates: Hvad må blokere en merge?
En god tommelfingerregel er at blokere for det, der enten er høj risiko, eller næsten altid er korrekt at håndhæve automatisk. Det giver færre undtagelser og mindre “alarmtræthed”. Undervejs i jeres compliance-arbejde vil I ofte koble dette til dokumentation og krav om sporbarhed; her kan Secure SDLC fungere som et fælles sprog mellem udvikling, sikkerhed og produktansvarlige.
- PR skal have mindst én godkendelse fra en anden udvikler (2 ved kritiske komponenter)
- Secrets scanning: ingen nye secrets i diff eller historik
- SAST: ingen nye critical/high issues, og ingen nye “policy violations”
- Dependency scanning: ingen nye kendte critical/high CVE uden plan
- IaC scanning ved ændringer i Terraform/CloudFormation/Kubernetes manifests
- Unit tests + security-relevante tests (fx authz) skal være grønne
Dependency scanning bør køre både på PR og på en tidsplan, fordi nye CVE’er kan ramme gamle builds. Et godt mønster er: PR gate for nye introduktioner, og en nightly job der åbner issues/PRs for opdateringer.
Mini-konklusion: PR-gates virker kun, når de er stabile, hurtige og knyttet til klare undtagelsesregler.
Automatiserbare gates i CI/CD: SAST, DAST, IaC og secrets
Det, der kan automatiseres, bør automatiseres. Men automatisering uden governance giver støj. Definér derfor tærskler, ejerskab og hvad der sker, når en gate fejler: hvem triagerer, hvor hurtigt, og hvordan dokumenteres en accept.
SAST (static analysis) er bedst som PR-gate, fordi den finder mønstre i koden tidligt. Hold regelskemaet stramt: start med få regler med høj præcision, og udvid gradvist. Kombinér gerne med codeQL-lignende queries for jeres mest kritiske frameworks.
DAST (dynamic analysis) giver værdi ved release-kandidater og i staging, hvor appen kører. DAST som PR-gate kan blive for langsomt, men en hurtig baseline-scan på hver merge til main kan fungere, hvis den er tidsbegrænset og målrettet.
IaC scanning bør være obligatorisk, fordi cloud-fejlkonfigurationer ofte er både almindelige og alvorlige: åbne storage buckets, for brede IAM-roller, offentlige security groups eller manglende kryptering. Kobl det til en “policy as code”-model, så platformteamet kan opdatere regler centralt.
Secrets scanning er en af de mest værdifulde gates: den forhindrer, at tokens og nøgler ender i git. Kombinér pre-commit hooks med server-side scanning, og brug en klar proces for rotation, hvis noget slipper igennem.
Til sidst dependency scanning: både for applikationsdependencies og container images. Det er ofte her, teams får mest “bang for the buck”, men også flest alerts. Indfør derfor et patching-SLA og en standard for, hvornår et fund må accepteres midlertidigt.
Mini-konklusion: De bedste gates er dem, der både kan blokere sikkert og kan forklares enkelt til udviklere.
Release: SBOM, changelog, vuln-status og sign-off
Release-fasen er jeres chance for at pakke sikkerhed og sporbarhed sammen med leverancen. Her skal I kunne svare på klassiske spørgsmål: Hvad ændrede sig? Hvilke komponenter er med? Hvad er kendt sårbart lige nu? Og hvem har accepteret risikoen?
SBOM og vuln-status som standard-artefakter
En SBOM (Software Bill of Materials) bør genereres automatisk ved build og gemmes sammen med artifacts. Det gør det muligt at reagere hurtigt på nye CVE’er og at dokumentere, hvilke versioner der reelt er leveret. Kombinér SBOM med en sårbarhedsrapport, der viser status ved release-tidspunktet: antal åbne findings, severity, og hvilke der er accepteret.
Changelog og formel sign-off uden at blive tungt
En god changelog behøver ikke være lang, men den skal være ærlig: sikkerhedsrettelser, ændringer i tilladelser, breaking changes og migrationer. Sign-off kan gøres letvægts: en automatisk “release checklist” i jeres pipeline, hvor PO eller dev lead godkender, at kriterier er opfyldt, og at eventuelle undtagelser er dokumenteret.
- SBOM genereret og arkiveret med build-id
- Vuln-status ved release: åbne critical/high = 0, eller dokumenteret accept
- Changelog inkluderer security-relevante ændringer og opgraderinger
- Artifact signing og verificerbar provenance er aktiv
- Release-notes peger på kendte begrænsninger og plan for patches
En vigtig best practice er at gøre sign-off til et data-drevet øjeblik, ikke et møde: pipeline-output, rapporter og links til issues skal være nok til at træffe beslutningen.
Mini-konklusion: Release bliver tryggere, når SBOM, vuln-status og godkendelser er automatiske artefakter, ikke manuelle dokumenter.
Typiske fejl og faldgruber i Secure SDLC, og sådan undgår du dem
Den mest almindelige fejl er at starte med for mange værktøjer og for stramme regler. Resultatet bliver et rødt dashboard, som ingen tror på. Start small, vælg få gates, og brug de første uger på at øge præcision og reducere støj.
En anden faldgrube er uklare undtagelser. Hvis udviklere ikke ved, hvordan de får en midlertidig accept, ender de med at omgå kontroller eller “slå scanning fra”. Lav i stedet en enkel proces: tidsbegrænset undtagelse, risikobegrundelse, ejer og plan for udbedring.
Teams fejler også, når threat modeling bliver et engangsdokument. Gør det til en rytme, og bind det til arkitekturændringer. Endelig: glem ikke driftsperspektivet. Logs, alarmer, rate limiting, backup og incident-håndtering er en del af sikkerhed, selv om det ikke altid står i en SAST-rapport.
Mini-konklusion: Modenhed kommer af iteration: færre falske positiver, bedre standarder, og bedre beslutningsspor, sprint for sprint.
Minimum viable Secure SDLC: 10 punkter til CRA-compliance
Hvis du skal i gang hurtigt og samtidig skabe et solidt fundament til CRA-compliance, så brug denne minimum viable Secure SDLC som baseline. Den er designet til at kunne implementeres på tværs af teams uden at kræve en total reorganisering.
- Definér sikkerhedspolitikker på én side: code review, secrets, dependencies, logging og signering
- Udvid DoR/DoD med konkrete sikkerhedskriterier og klare undtagelsesregler
- Indfør security champion-rollen i hvert team og giv tid i sprintet til opgaven
- Kør letvægts threat modeling ved nye epics, integrationer og større dataflows
- Automatisér secrets scanning i pre-commit og som server-side gate i PR
- Automatisér SAST i PR med blokering af nye high/critical og kendte policy-brud
- Automatisér dependency scanning for kode og images, med patching-SLA og owner
- Automatisér IaC scanning for cloud- og Kubernetes-ændringer med policy as code
- Generér SBOM ved hver build, arkivér den, og knyt den til release-id og changelog
- Release sign-off kræver dokumenteret vuln-status og accept af evt. midlertidig risiko
Det vigtigste er at gøre disse punkter til en standardiseret måde at arbejde på: skabeloner i repos, fælles pipeline-trin og ens rapportering. Når baselinen kører, kan du udvide med mere avanceret DAST, fuzzing, runtime-beskyttelse og dybere revisionsspor.
Mini-konklusion: En “minimum viable” Secure SDLC er nok til at skabe kontrol, evidens og bedre sikkerhed, hvis den er automatiseret, ejet af teamet og understøttet af platformen.
