Hvilke kontroller bør ind i en moden Secure SDLC?

De fleste sikkerhedsbrud starter ikke med “hackere i hættetrøjer” – de starter med en lille, overset beslutning i udviklingsforløbet: en forkert standardkonfiguration, en manglende adgangskontrol eller en dependency, ingen fik opdateret.

I denne artikel får du et praktisk overblik over, hvilke sikkerhedskontroller og arbejdsgange der typisk indgår i en moden Secure SDLC (Secure Software Development Lifecycle) i praksis. Du får konkrete eksempler på, hvor kontrollerne passer ind, hvad de fanger, og hvordan du undgår de klassiske faldgruber, så security bliver en del af flowet – ikke en stopklods til sidst.

Undervejs besvarer jeg også de spørgsmål, der næsten altid dukker op: hvad det er, hvorfor det betaler sig, hvordan man implementerer det trinvist, hvad det typisk koster i tid og værktøjer, og hvilke fejl der oftest gør Secure SDLC til en papirøvelse.

Hvad er Secure SDLC – og hvorfor betyder det noget?

En Secure SDLC er en udviklingsproces, hvor sikkerhedskontroller og risikostyring er indbygget i alle faser: fra idé og design til kode, test, release og drift. Pointen er enkel: jo tidligere du finder en sårbarhed, jo billigere er den at rette. I praksis kan en fejl, der koster minutter at rette i en Pull Request, koste dage eller uger, hvis den først opdages efter release, når kunder, drift og compliance også er involveret.

Det handler ikke om at gøre alt “maksimalt sikkert” hele tiden. Det handler om at vælge de rigtige kontroller til jeres risiko og modenhed, så teamet kan levere hurtigt uden at akkumulere skjult sikkerhedsgæld.

Mini-konklusion: Secure SDLC er ikke et enkelt værktøj eller en audit; det er en måde at bygge software på, hvor sikkerhed er en løbende kvalitetsegenskab.

Grundprincipperne i en moden proces (før du vælger værktøjer)

Før man taler SAST, DAST og scanners, bør man være enige om nogle få principper, der gør kontrollerne effektive i hverdagen:

• Shift left: fang fejl tidligt i design og code review, hvor de er billigst at rette.
• Automatisér det gentagelige: alt der kan køre i CI/CD uden friktion, bør køre i CI/CD.
• Risikobaseret: alle findings er ikke lige vigtige; prioriter efter impact og exploitability.
• Klart ejerskab: hvem triager, hvem retter, og hvem accepterer risikoen?
• Målbarhed: mål fx patch-latency, andel af builds med kritiske findings, og tid til triage.

En typisk fejl er at starte med “en stor scanner” uden at have besluttet, hvad der sker, når den finder 500 issues. Resultatet bliver alert-træthed og bypass-kultur.

Mini-konklusion: En moden Secure SDLC er mindre “flere værktøjer” og mere “klar proces + automatisering + prioritering”.

Planlægning og krav: få styr på data, risici og sikkerhedsmål

Det her er fasen, mange undervurderer, fordi den ikke føles teknisk. Men den sparer ofte flest penge, fordi den forebygger designfejl, som ellers bliver dyre at ændre senere.

Data-klassificering og trusselsbillede

Start med at svare på: Hvilke data håndterer systemet (persondata, betalingsdata, forretningskritiske data)? Hvor ligger de (DB, logs, cache, tredjeparts-SaaS)? Og hvem har adgang? En simpel dataflow-skitse kan afsløre klassiske problemer som tokens i logs eller PII i analytics events.

Som tommelfingerregel: hvis I ikke kan forklare dataflowet på 10 minutter, kan I heller ikke sikre det konsekvent.

Threat modeling som praktisk workshop

Threat modeling behøver ikke være tungt. En effektiv form er en 60–90 minutters workshop pr. større feature med fokus på de største risici: auth, authorization, input, og integrationer. Brug gerne STRIDE som tjekliste, men hold output handlingsorienteret: konkrete mitigations og testcases.

Mini-konklusion: God sikkerhed starter med at forstå data og angrebsflader – ikke med at scanne kode.

Design og arkitektur: kontroller der forebygger hele klasser af fejl

En moden proces har faste design-krav, der går igen på tværs af teams, så man ikke opfinder sikkerhed fra bunden i hvert projekt.

Sikkerhedsarkitektur i praksis: standarder og “guardrails”

Eksempler på designkontroller, der typisk giver høj effekt:

• Standard for autentifikation (OIDC/OAuth2) og krav til session/token-håndtering.
• Autorisation som politik: fx central policy engine eller fælles authorization middleware.
• Kryptering: TLS overalt og klare krav til encryption at rest for følsomme data.
• Logging: hvad må logges, og hvordan undgår I secrets/PII i logs?
• Rate limiting og abuse-beskyttelse på API’er.

Her er det vigtigt at tænke i “platform features”: hvis platformteamet tilbyder sikre defaults (templates, libraries, CI jobs), bliver den sikre løsning også den nemme.

Design review og sikkerhedsgates uden flaskehalse

I stedet for at alle ændringer skal forbi et centralt security-team, kan man lave letvægts “gates” baseret på risikoniveau. Fx: ændringer i auth, betaling eller dataeksport kræver et kort sikkerhedsdesign-review, mens mindre UI-ændringer ikke gør.

Mini-konklusion: Arkitekturkontroller er ofte den billigste måde at reducere risiko, fordi de fjerner hele kategorier af sårbarheder.

Implementering: sikre kodestandarder, code review og “secure-by-default” værktøjer

Her bliver Secure SDLC konkret for udviklere. Målet er at gøre det svært at lave de farlige fejl og let at gøre det rigtige.

Et godt minimum er:

1. Sikre kodestandarder pr. sprog/stack (fx håndtering af input, SQL, SSRF, filupload).
2. Pull Request-skabeloner med security-tjek: “Har vi ændret autorisation?”, “Er der nye secrets?”
3. Peer review med fokus på de klassiske top-risici (OWASP Top 10 som fælles sprog).
4. Træning “i kontekst”: korte sessions med eksempler fra jeres egen kodebase.

En moden praksis er at have et lille sæt “golden paths”: frameworks, libs og eksempler, der allerede håndterer fx CSRF, secure headers og korrekt token-validering. Det reducerer både fejl og debat i reviews.

Mini-konklusion: Det stærkeste secure coding-tiltag er ikke en PDF, men gentagelige patterns og review-vaner, der passer til jeres stack.

CI/CD og automatiske scanninger: SAST, dependency, secrets og IaC

Midt i en moden Secure SDLC ligger typisk en stærk CI/CD-rygrad, hvor scanninger er automatiserede, versionerede og håndterbare. Det er her, mange teams får den største “sikkerhed pr. investeret time” – hvis triage og støj håndteres rigtigt.

SAST: statisk kodeanalyse der faktisk bliver brugt

SAST kan fange fejl som usikre deserialiseringer, fejl i access control patterns, og injection-lignende issues – men kun hvis reglerne er kalibreret. En praktisk tilgang er:

• Start med et lille regelsæt og få lav falsk-positiv-rate.
• Kør på Pull Requests og kommentér direkte i diff’en.
• Fail kun build på “kritiske” kategorier i starten, og udvid gradvist.

En typisk faldgrube er at slå alt til fra dag 1 og derefter ignorere resultaterne. Hellere 10 findings, der bliver rettet, end 1000, der bliver arkiveret.

Dependency scanning, SBOM og patch-arbejdsgange

De fleste moderne angreb udnytter kendte sårbarheder i tredjepartsbiblioteker. Derfor er dependency scanning og en patch-proces afgørende. Overvej:

• Automatiske PR’s til opdateringer (fx Renovate/Dependabot) med tydelige risiko-tags.
• SLA for patching: fx 7 dage for kritiske, 30 dage for high (tilpas til jeres risiko).
• SBOM (Software Bill of Materials) for at kunne svare hurtigt: “Er vi ramt af CVE-X?”

Her er et konkret mål, jeg ofte har set virke: at måle “median tid fra CVE publiceret til patch i produktion”. Det skaber fokus på flow, ikke bare scanning.

Secrets scanning og IaC scanning

Secrets scanning bør køre både lokalt (pre-commit) og i CI, så API keys og tokens ikke ender i Git-historik. For infrastructure-as-code (Terraform, Kubernetes manifests) giver scanning mening, fordi fejl her ofte skaber store angrebsflader: åbne security groups, offentlige buckets eller overprivilegerede service accounts.

Mini-konklusion: Automatiske scanninger skaber værdi, når de er integreret i PR-flowet, kalibreret og koblet til en klar patch- og triageproces.

Test og verifikation: DAST, API-tests, pentest og negativ test

Hvor SAST ser på koden, ser dynamiske tests på det kørende system. Det er især nyttigt til konfigurationsfejl, auth/authorization-bugs og fejl i runtime-adfærd.

DAST og API-sikkerhedstest uden at spænde ben for release

DAST kan være tungt, men kan gøres pragmatisk: kør hurtige baseline-scans på staging for hver release, og dybere scans natligt eller ugentligt. For API’er kan man kombinere:

• Schema-baserede tests (OpenAPI) for at opdage uventede endpoints og input.
• Autorisationstests: “kan bruger A tilgå bruger B’s data?”
• Rate limit-tests og basic abuse-scenarier.

Et effektivt supplement er negative tests i automatiserede testpakker: bevidst “forkerte” tokens, manipulerede claims, eller manglende scopes, der skal give 401/403.

Pentest: hvornår giver det mening?

Pentest giver mest værdi ved større releases, nye angrebsflader (fx public API, ny auth-løsning) eller før compliance-milepæle. Det bør ikke være den eneste kontrol, men en validering af, at jeres løbende kontroller virker.

Typisk spørgsmål: “Hvad koster det?” Det afhænger af scope, men i praksis ser man ofte alt fra 50.000–250.000 DKK for en ekstern test af en mellemstor applikation. En intern “light pentest” eller red team-øvelse kan være billigere, men kræver kompetencer og tid. Den store skjulte omkostning er næsten altid remediation og retest, så planlæg kapacitet.

Mini-konklusion: DAST og pentest er stærke, når de er planlagte, scoped og koblet til en remediation-proces – ikke når de kommer som en overraskelse dagen før release.

Release og drift: hardening, overvågning og sårbarhedshåndtering

En moden Secure SDLC stopper ikke ved “deploy”. Mange reelle sikkerhedshændelser handler om drift: misconfigurations, manglende overvågning, eller sårbarheder der aldrig blev patched.

Her er arbejdsgange, der typisk bør være på plads:

1. Release gates: fx “ingen kritiske kendte sårbarheder” og “security config checks passer”.
2. Hardening-baselines for containere/OS (minimale images, read-only filsystem hvor muligt).
3. Runtime-overvågning: alarmer på usædvanlige login-mønstre, fejlrate, og spikes i 403/401.
4. Sårbarhedshåndtering for runtime (container/image scanning) og cloud resources.
5. Incident response light: hvem gør hvad ved læk eller mistanke?

En udbredt faldgrube er at have fine scanninger, men ingen driftssignalering. Hvis ingen opdager et credential-stuffing angreb eller en pludselig datatrafik til et ukendt endpoint, er “sikker kode” ikke nok.

Mini-konklusion: Driftssikkerhed er den praktiske test af jeres Secure SDLC: kan I opdage, reagere og komme tilbage i sikker tilstand hurtigt?

Governance og mennesker: roller, metrics og undgåelse af de klassiske faldgruber

Secure SDLC handler lige så meget om organisation som teknik. Uden klare roller og mål bliver det enten “security siger nej” eller “ingen ejer det”.

RACI, security champions og klare beslutninger

Et mønster der ofte virker: et decentraliseret setup med security champions i teams og et centralt security-team, der sætter standarder og hjælper med svære sager. Det kræver en tydelig beslutningsmodel: Hvem må acceptere en risiko, og hvornår skal den eskaleres?

Metrics der driver adfærd (ikke bare rapporter)

Gode metrics er dem, der ændrer daglig adfærd. Eksempler:

• Tid til triage af nye kritiske findings (mål: timer/dage, ikke uger).
• Andel af repos med aktiveret secrets scanning og dependency updates.
• Patch-latency for kritiske CVE’er i produktion.
• Antal gentagne findings pr. team (tegn på behov for patterns/træning).

Undgå vanity metrics som “antal scanninger kørt”. Det siger intet om risikoen er reduceret.

De mest almindelige fejl – og hvordan du undgår dem

Her er de faldgruber, jeg ser igen og igen i praksis:

• For mange alerts: start småt, kalibrér, og udvid gradvist.
• Ingen ejerskab: definer hvem der triager og hvem der retter (og hvornår).
• Security som særteam: byg “guardrails” og self-service i stedet for tickets.
• Engangs-pentest: brug pentest som validering, ikke som eneste kontrol.
• Manglende patch-flow: scanning uden patching er støj, ikke sikkerhed.

Mini-konklusion: Modenhed kommer af gentagelige rutiner: ejerskab, måling, og små forbedringer hver sprint.

Sådan kommer du i gang: en realistisk 90-dages plan

Typisk spørgsmål er “hvordan gør vi uden at stoppe udviklingen?” En pragmatisk plan er at implementere kontroller i bølger, så I får effekt hurtigt og lærer undervejs.

1. Uge 1–3: secrets scanning, dependency scanning, og en enkel patch-SLA. Få PR-flow og triage på plads.
2. Uge 4–6: basale secure coding-guidelines + PR-tjekliste + kalibreret SAST på 1–2 kritiske repos.
3. Uge 7–10: threat modeling workshop for de mest risikofyldte flows (auth, betaling, dataeksport) + design guardrails.
4. Uge 11–13: DAST baseline