De fleste sikkerhedsbrister bliver ikke “hacket ind” til sidst—de bliver designet ind tidligt og opdaget alt for sent.
I denne artikel får du en praktisk, trin-for-trin guide til, hvordan du integrerer Secure SDLC (Secure Software Development Life Cycle) gennem hele udviklingsforløbet: fra krav og arkitektur til kodning, test, release og løbende vedligehold. Du får konkrete aktiviteter, roller, værktøjsnære eksempler og typiske faldgruber, så du kan omsætte sikkerhed til en del af jeres normale leveranceflow.
Du får også et realistisk billede af, hvad det koster i tid og penge, og hvorfor det næsten altid er billigere at flytte sikkerhed “til venstre” end at lappe huller i produktion.
Hvad er Secure SDLC, og hvorfor betyder det noget?
Secure SDLC er en udviklingsmodel, hvor sikkerhed indbygges som faste aktiviteter, krav og kontroller i alle faser af softwareudviklingen—ikke som en engangs-gennemgang lige før go-live. Målet er at reducere risikoen for sårbarheder, datalæk og driftshændelser ved at forebygge fejl, før de bliver dyre at rette.
Et praktisk pejlemærke: En fejl, der tager 10 minutter at rette i designfasen, kan nemt koste dage eller uger efter release, fordi den kræver hotfix, regressionstest, change management og kommunikation. Mange teams oplever også “sikkerhedsgæld”: små fravalg i sprint 1–3, der bliver til store problemer i sprint 10–12.
Mini-konklusion: Secure SDLC handler ikke om mere bureaukrati, men om at flytte sikkerhedsarbejde tidligere, så du leverer hurtigere med færre overraskelser.
Grundprincipperne: sådan gør du sikkerhed til en del af flowet
Hvis du vil lykkes, skal Secure SDLC føles som udvikling—ikke som en ekstern audit. De bedste implementeringer bygger på få, gentagelige rutiner, der kan automatiseres og måles.
“Shift left” og “shift right” i praksis
“Shift left” betyder, at du forebygger sårbarheder gennem krav, design, secure coding og tidlig scanning. “Shift right” betyder, at du også overvåger, logger og lærer af produktion—fordi trusselsbilledet ændrer sig, og konfigurationer driver over tid.
Security by design, ikke security by checklist
Checklister er nyttige, men de må ikke erstatte forståelse. I praksis vil to features med samme tech stack have helt forskellige trusler afhængigt af data, brugerroller og integrationer. Et godt Secure SDLC giver dig derfor både standarder og plads til risikobaserede beslutninger.
- Risiko først: Prioritér efter sandsynlighed og konsekvens, ikke efter “hvad scanneren finder mest af”.
- Standarder: Definér minimumskrav til autentifikation, logging, kryptering og secrets.
- Automatisering: CI/CD skal fange kendte fejltyper, før de når review eller release.
- Ejerskab: Udvikling ejer sikkerhedstiltag, sikkerhed faciliterer og rådgiver.
- Målinger: Track fx tid til patch, antal høj-kritiske fund pr. release og coverage af scanning.
Mini-konklusion: Hvis sikkerhed bliver en gentagelig del af pipeline og definition of done, falder friktionen markant.
Kravfasen: sikkerhedskrav, data og acceptkriterier
De mest effektive sikkerhedstiltag starter i kravarbejdet, hvor du kan påvirke scope, datastrømme og forventninger, før noget bygges. Her er det ikke nok at skrive “systemet skal være sikkert”. Krav skal kunne testes og godkendes.
Start med data-klassificering og trusselsflader
Jeg anbefaler at beskrive data i tre simple niveauer: offentlig, intern og følsom (fx persondata, sundhedsdata, betalingsdata). Det hjælper med at afklare, om du skal bruge kryptering i transit og i hvile, strengere adgangskontrol og længere log-retention.
Gør sikkerhed til testbare acceptkriterier
Eksempler på gode, konkrete krav:
- Alle endpoints kræver autentifikation, undtagen dokumenteret “public”-liste.
- Autorisation valideres server-side for hver request (ikke kun i UI).
- Rate limiting aktiveres på login og password reset.
- Audit-logs indeholder bruger-id, handling, ressource-id, timestamp og resultat.
- Secrets må ikke ligge i repo; rotation er dokumenteret og kan gennemføres på under 30 minutter.
Mini-konklusion: Når sikkerhed bliver en del af user stories og acceptkriterier, bliver “done” faktisk done.
Design og arkitektur: threat modeling og sikkerhedsdesign-mønstre
I designfasen kan du fange de dyreste fejl: forkert trust boundary, for brede service-accounts, manglende segmentering eller uklare auth-flows. Her giver threat modeling mest værdi pr. time.
Threat modeling uden at gøre det tungt
Du behøver ikke en stor workshop hver gang. For nye features eller ændringer med høj risiko kan du køre en 45–90 minutters session med en fast skabelon: dataflowdiagram, trust boundaries, trusler og mitigations. Brug gerne STRIDE som huskeliste (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege).
Konkrete designvalg, der ofte betaler sig
- Least privilege: Separate roller og scopes for læsning/skrivning og for admin-funktioner.
- Token-håndtering: Korte token-livetider og rotationsstrategi for refresh tokens.
- Fejlhåndtering: Ingen stack traces til klienten; korrelations-id til support.
- Segregering: Del netværk og services op efter følsomhed; begræns east-west trafik.
- Supply chain: Brug interne registries og signering, hvis muligt.
Midt i designarbejdet giver det mening at samle jeres principper for sikker softwareudvikling i en let tilgængelig standard, så teams ikke opfinder løsninger på ny i hvert projekt.
Mini-konklusion: Threat modeling og standardiserede designmønstre forebygger “arkitektur-ombygninger” efter release.
Implementering: secure coding, reviews og automatiske checks
I kodningsfasen handler Secure SDLC om at gøre den sikre vej til den nemmeste vej. Det kræver både udviklerpraksis og CI-automatisering.
Secure coding-praksis, der virker i hverdagen
Fokusér på de fejl, der oftest giver reelle hændelser: injektion, broken access control, insecure deserialization, SSRF, fejl i fil-upload, og svage auth/flows. Det er typisk tæt på OWASP Top 10, men prioriteret efter jeres kontekst.
- Centralisér autorisation i middleware/policies, så du ikke “glemmer” checks i nye endpoints.
- Brug parameteriserede queries/ORM korrekt; undgå string-konkatenation til SQL.
- Valider input server-side med en tydelig allowlist (fx for filtyper, enum-værdier og længder).
- Log sikkert: ingen adgangskoder, tokens eller fulde kortnumre i logs.
Code review med sikkerhedsfokus (uden at sænke farten)
Indfør en lille review-checkliste, som reviewers faktisk kan gennemføre på 2–3 minutter: ændrer PR’en auth/permissions? håndteres fejl korrekt? er nye afhængigheder vurderet? er secrets røget med? Jeg har set teams reducere “kritiske” findings markant ved kun at gøre dette konsekvent.
Mini-konklusion: Kombinationen af enkle secure coding-regler og målrettede reviews fanger mange sårbarheder før test overhovedet starter.
Test: SAST, DAST, dependency scanning og sikkerhedstestcases
Sikkerhedstest er mere end en scanner-rapport. Det bedste setup kombinerer automatiske værktøjer med få, velvalgte manuelle tests for de mest risikable flows.
Hvilke tests hvor?
- SAST (statisk analyse): kør på pull requests; find mønstre i kode tidligt.
- Dependency scanning (SCA): find kendte CVE’er i biblioteker og base images.
- DAST (dynamisk test): kør mod staging; fang runtime-fejl, headers, auth issues.
- IaC scanning: Terraform/Kubernetes-manifester for åbne security groups, brede roles osv.
Manuelle tests på de rigtige steder
For login, password reset, rollebaseret adgang og fil-upload er manuelle “misbrugstests” ofte guld værd. Eksempel: Kan en bruger ændre resource-id i URL’en og se andres data? Kan du genbruge et password reset-token? Kan du uploade en “.jpg”, der reelt er et script?
Mini-konklusion: Automatiske scanninger giver bred dækning, men de vigtigste risici findes ofte i forretningslogik og adgangskontrol—der skal du teste målrettet.
Release og drift: gates, hardening, logging og incident readiness
Når du releaser, skal du sikre, at det du har bygget, også bliver kørt sikkert. Mange hændelser skyldes konfiguration, manglende overvågning eller for brede driftstilladelser—ikke “dårlig kode”.
Release-gates uden at blokere alt
Brug risikobaserede gates. For eksempel: ingen “critical” findings fra SCA/SAST må gå i produktion, medmindre der findes en godkendt compensating control og en fast deadline. Det er bedre end et generelt “alt skal være grønt”, som ender med at blive ignoreret.
Hardening og observability
- Secure headers (fx CSP, HSTS hvor relevant) og korrekt CORS-konfiguration.
- Secrets management med rotation og adskilte rettigheder mellem miljøer.
- Logging med korrelations-id og alarmer på mistænkelige mønstre (fx brute force, spikes).
- Backups og restore-tests (ikke kun “vi tager backup”).
Mini-konklusion: Et sikkert release er lige så meget drift og konfiguration som kode—og det kan standardiseres.
Vedligehold: patching, sårbarhedshåndtering og læring i loop
Secure SDLC stopper ikke ved release. Afhængigheder får nye CVE’er, cloud-tjenester ændrer defaults, og forretningen ønsker nye integrationer. Vedligehold er derfor en kontinuerlig proces med klare SLA’er og prioritering.
Hvad koster Secure SDLC realistisk?
Omkostningen afhænger af modenhed og reguleringsniveau, men i praksis ser jeg ofte disse poster:
- Opsætning og tuning af scanning i CI/CD (typisk dage til få uger, afhængigt af kompleksitet).
- Løbende triage af findings (fx 1–3 timer pr. sprint pr. team, hvis det holdes skarpt).
- Periodiske threat modeling-sessioner på større ændringer (fx 1–2 timer pr. feature-epic).
- Patch cadence (fx ugentlig eller hver 14. dag for afhængigheder og base images).
Den skjulte besparelse ligger i færre hastefixes og mindre brand-slukning. En incident kan hurtigt koste mange mandedage i tværgående teams plus omdømme og evt. regulatorisk opfølgning.
Typiske faldgruber (og hvordan du undgår dem)
- For mange værktøjer på én gang: start med 2–3 signalstærke checks og udvid gradvist.
- Uprioriteret backlog af findings: lav SLA’er og ownership; ellers bliver det støj.
- Security som “andres ansvar”: giv teams konkrete standarder og tid i sprinten.
- Ignorerede falsk-positive: tune regler; en scanner uden tillid bliver slukket.
- Manglende asset-overblik: uden inventar ved du ikke, hvad der skal patches.
Mini-konklusion: Vedligehold er der, hvor Secure SDLC enten bliver en disciplin—eller forsvinder i støj. SLA’er og tydeligt ejerskab gør forskellen.
Kom i gang: en enkel 30-dages plan for at integrere Secure SDLC
Hvis du vil i gang uden at stoppe leverancerne, så tænk i små, faste skridt. Her er en plan, jeg har set fungere i teams, der allerede kører agile sprints og CI/CD.
- Uge 1: Definér 8–12 sikkerhedskrav som standard (auth, logging, secrets, data) og læg dem i jeres templates for user stories.
- Uge 2: Indfør SCA og SAST på pull requests med en enkel policy (stop kun for “critical/high” i starten).
- Uge 3: Kør en threat modeling-session på en vigtig feature og omsæt mitigations til tickets.
- Uge 4: Tilføj DAST mod staging og etabler 3–5 alarmer i logging/monitorering for misbrugsmønstre.
- Slut uge 4: Aftal patch cadence og en enkel sårbarheds-SLA (fx critical: 48–72 timer, high: 14 dage).
Mini-konklusion: Du behøver ikke “perfekt sikkerhed” for at få effekt—konsekvente rutiner i krav, pipeline og drift giver hurtigt målbar risikoreduktion.
About the Author
