{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"security/secure-development-lifecycle","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/security/secure-development-lifecycle/","da":"https://cmaintz.github.io/tech-atlas/da/terms/security/secure-development-lifecycle/"},"term":{"en":"Secure development lifecycle (SDL)","da":"Sikker udviklingslivscyklus (SDL)"},"aka":{"en":["secure software development lifecycle","SSDLC","security development lifecycle"],"da":["sikker softwareudvikling"]},"domain":["security"],"cluster":"application-security","layer":"application","status":"current","era":2004,"summary":{"en":"A fixed set of security steps built into every stage of making software, from planning and design through testing to release.","da":"Et fast sæt sikkerhedstrin bygget ind i alle faser af softwareudvikling, fra planlægning og design over test til frigivelse."},"body":{"formal":{"en":"A development process that adds set security activities to each phase - security requirements at planning, threat modelling at design, secure coding rules and code review while building, security testing before release, and a plan for handling flaws found afterwards.","da":"En udviklingsproces, der tilføjer faste sikkerhedsaktiviteter til hver fase - sikkerhedskrav ved planlægning, trusselsmodellering ved design, regler for sikker kode og kodegennemgang under udviklingen, sikkerhedstest før frigivelse og en plan for at håndtere fejl, der findes bagefter."},"plain":{"en":"Like the checks a new building must pass at each stage - drawings approved, foundation inspected, wiring tested - instead of one inspection when it is already finished.","da":"Som de tjek, en ny bygning skal igennem undervejs - tegninger godkendt, fundament inspiceret, de elektriske ledninger testet - i stedet for én inspektion, når huset står færdigt."},"inPractice":{"en":"A software house building a case system for a ministry will not hand over a new version until the design has a threat model, the code has passed review and automatic scans, and a tester has signed off; flaws found later follow a set fix-and-notify routine.","da":"Et softwarehus, der udvikler et sagssystem til et ministerium, afleverer ikke en ny version, før designet har en trusselsmodel, koden har bestået gennemgang og automatiske scanninger, og en tester har godkendt; fejl, der findes senere, følger en fast rutine for rettelse og besked til kunden."},"whyItMatters":{"en":"Security that depends on each developer remembering it is uneven; fixed steps in the process mean fewer flaws reach customers, and give buyers something concrete to check against.","da":"Sikkerhed, der afhænger af, at hver enkelt udvikler husker den, bliver ujævn; faste trin i processen betyder, at færre fejl når kunderne, og giver indkøbere noget konkret at tjekke op imod."}},"deepDive":{"en":"The term comes from Microsoft's Security Development Lifecycle, which grew out of Bill Gates's Trustworthy Computing memo of January 2002 and the security pushes that followed; from 2004 it was mandatory for Microsoft products exposed to meaningful risk. Its core activities are still recognisable in every later model: security and privacy requirements with bug bars, threat modelling of the design, approved tools and compiler hardening flags, banning unsafe functions, static analysis, dynamic testing and fuzzing, a final security review before release and a documented incident response plan for shipped products.\n\nToday the reference points are frameworks rather than a single vendor process. NIST SP 800-218, the Secure Software Development Framework (SSDF), is outcome-based and deliberately does not prescribe a lifecycle model; it organises practices into four groups: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) and Respond to Vulnerabilities (RV). PW.1.1, for example, asks for risk modelling such as threat modelling, attack modelling or attack surface mapping. OWASP SAMM and BSIMM are maturity models used to measure and plan an SDL programme, and IEC 62443-4-1 specifies secure product development requirements for industrial automation suppliers. In ISO/IEC 27001:2022, Annex A controls 8.25 Secure development life cycle, 8.28 Secure coding and 8.29 Security testing in development and acceptance cover the same ground from the management-system side.\n\nIn a modern CI/CD pipeline the activities become automated gates: secret scanning and SAST on each commit, software composition analysis and SBOM generation for third-party components, container and infrastructure-as-code scanning, DAST against a staging environment, signed build provenance (for example SLSA levels) and branch protection requiring peer review. The manual activities that automation cannot replace are threat modelling, security architecture review, penetration testing of high-risk features and triage of findings against a defined bug bar. A frequent failure mode is a pipeline full of scanners whose findings are never triaged, which produces evidence of activity rather than fewer vulnerabilities.\n\nRegulation is turning the SDL from good practice into an obligation for product manufacturers. The EU Cyber Resilience Act (Regulation (EU) 2024/2847) requires products with digital elements to meet the essential requirements in Annex I, including vulnerability handling processes and security updates for the support period; its reporting obligations for actively exploited vulnerabilities have applied since 11 September 2026, and the bulk of the obligations apply from 11 December 2027. The SDL differs from security by design in that security by design is the principle, while the SDL is the repeatable process and evidence trail that implements it.","da":"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.\n\nI 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.\n\nI 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.\n\nRegulering 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."},"edges":[{"type":"implements","to":"security/security-by-design","confidence":"high","strength":"normal"},{"type":"mitigates","to":"security/vulnerability","why":{"en":"Checks at every stage catch flaws before release, when they are cheapest to fix.","da":"Tjek i hver fase fanger fejl før frigivelse, hvor de er billigst at rette."},"confidence":"high","strength":"primary"},{"type":"used-with","to":"security/vulnerability-scanning","why":{"en":"Automatic scans of the code and the parts it is built from run at the build and test stages of the lifecycle.","da":"Automatiske scanninger af koden og de dele, den er bygget af, kører i livscyklussens udviklings- og testfaser."},"confidence":"medium","strength":"normal"}],"depth":0,"sources":[{"title":"Microsoft Security Development Lifecycle (SDL)","url":"https://www.microsoft.com/en-us/securityengineering/sdl","tier":"official-doc","publisher":"Microsoft"},{"title":"NIST SP 800-218 - Secure Software Development Framework (SSDF)","url":"https://csrc.nist.gov/pubs/sp/800/218/final","tier":"standard","publisher":"NIST"}],"draft":true}