Sikker udviklingslivscyklus (SDL)

Begrebet stammer fra Microsofts Security Development Lifecycle, der voksede ud af Bill Gates' Trustworthy Computing-memo fra januar 2002 og de sikkerhedsindsatser, der fulgte; fra 2004 var den obligatorisk for Microsoft-produkter med en væsentlig risiko. Kerneaktiviteterne kan genkendes i alle senere modeller: sikkerheds- og privatlivskrav med bug bars, trusselsmodellering af designet, godkendte værktøjer og hærdende compilerflag, forbud mod usikre funktioner, statisk analyse, dynamisk test og fuzzing, en afsluttende sikkerhedsgennemgang før frigivelse og en dokumenteret plan for hændelseshåndtering for udgivne produkter.

I dag er referencepunkterne rammeværker frem for én leverandørs proces. NIST SP 800-218, Secure Software Development Framework (SSDF), er resultatbaseret og foreskriver bevidst ikke en bestemt livscyklusmodel; praksisserne er ordnet i fire grupper: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) og Respond to Vulnerabilities (RV). PW.1.1 kræver fx risikomodellering som trusselsmodellering, angrebsmodellering eller kortlægning af angrebsfladen. OWASP SAMM og BSIMM er modenhedsmodeller, der bruges til at måle og planlægge et SDL-program, og IEC 62443-4-1 fastlægger krav til sikker produktudvikling for leverandører til industriel automation. I ISO/IEC 27001:2022 dækker kontrollerne 8.25 Sikker udviklingslivscyklus, 8.28 Sikker kodning og 8.29 Sikkerhedstest i udvikling og accept i bilag A det samme område set fra ledelsessystemets side.

I en moderne CI/CD-pipeline bliver aktiviteterne til automatiske gates: secret scanning og SAST ved hvert commit, software composition analysis og SBOM-generering for tredjepartskomponenter, scanning af containere og infrastructure as code, DAST mod et staging-miljø, signeret build-proveniens (fx SLSA-niveauer) og branch protection, der kræver kodegennemgang af en kollega. De manuelle aktiviteter, som automatisering ikke kan erstatte, er trusselsmodellering, gennemgang af sikkerhedsarkitekturen, penetrationstest af højrisikofunktioner og triage af fund op mod en fastlagt bug bar. En hyppig faldgrube er en pipeline fuld af scannere, hvis fund aldrig bliver triageret, hvilket giver bevis for aktivitet frem for færre sårbarheder.

Regulering gør SDL til en pligt for producenter frem for god praksis. EU's Cyber Resilience Act (forordning (EU) 2024/2847) kræver, at produkter med digitale elementer opfylder de væsentlige krav i bilag I, herunder processer for sårbarhedshåndtering og sikkerhedsopdateringer i supportperioden; indberetningspligten for aktivt udnyttede sårbarheder har gældet siden 11. september 2026, og hovedparten af forpligtelserne gælder fra 11. december 2027. SDL adskiller sig fra security by design ved, at security by design er princippet, mens SDL er den gentagelige proces og det dokumentationsspor, der omsætter det til praksis.