NIST SSDF (SP 800-218)

De fire praksisgrupper

SSDF organiserer sine praksisser i fire grupper. Hver praksis angiver et resultat, og NIST gør det klart, at det ikke er en tjekliste: Det er et grundlag for planlægning baseret på risiko.

Gruppe	Mål	Eksempler
Prepare the Organization (PO)	Mennesker, processer og værktøjer er klar	Definér sikkerhedskrav, tildel roller, sikr udviklingsmiljøet
Protect the Software (PS)	Kode og releases er sikret mod manipulation	Beskyt alle former for kode, verificér releasens integritet, arkivér hver release
Produce Well-Secured Software (PW)	Få sårbarheder i det, du udgiver	Design for sikkerhed, genbrug velsikret software, gennemgå og test kode
Respond to Vulnerabilities (RV)	Find tilbageværende fejl, og håndtér dem	Identificér sårbarheder løbende, prioritér og ret dem, analysér grundårsager

De praksisser, der berører din forsyningskæde

• PO.3, understøttende toolchains, og PO.5, sikre miljøer. Dit CI-system er en del af det, du skal beskytte. Se tjeklisten for CI/CD-pipelinesikkerhed.
• PS.3, arkivér og beskyt hver release. Det omfatter indsamling af provenance-data for komponenterne i hver release, og SSDF nævner SBOM'en som en måde at gøre det på.
• PW.4, genbrug velsikret software. Tredjepartskomponenter bør vurderes og holdes opdaterede, og det er her, software composition analysis passer ind.
• RV.1, identificér sårbarheder løbende. Det er en løbende pligt, ikke en kontrol ved release, så det kræver overvågning af det, du allerede har leveret.
• RV.2, vurdér, prioritér og udbedr. Se sådan prioriterer du sårbarheder.

Er SSDF obligatorisk?

Ikke i sig selv. Det er en NIST-publikation, ikke en lov. I nogle år havde det direkte betydning for amerikanske føderale leverandører, fordi OMB-memoerne M-22-18 og M-23-16 krævede en attestering af, at de fulgte praksisser hentet fra det. Det ændrede sig den 23. januar 2026: OMB-memoet M-26-05 ophævede begge og gik over til en risikobaseret tilgang. Myndigheder kan stadig bruge den fælles attesteringsformular og NIST's standarder, men de er ikke længere forpligtet til det, så leverandører bør regne med, at kravene varierer fra myndighed til myndighed.

Uden for føderale indkøb er SSDF stadig nyttigt som et fælles sprog. Kunder låner fra det i sikkerhedsspørgeskemaer, og det kan kobles til andre standarder.

SSDF-versioner

• Version 1.1, SP 800-218, udgivet i februar 2022, er den aktuelle endelige version.
• Version 1.2, SP 800-218 Revision 1, blev offentliggjort som udkast i december 2025.
• SP 800-218A er en community-profil, der udvider SSDF til generativ AI og dual-use foundation models.

Sådan tager du SSDF i brug

1. Kortlæg, hvad du gør i dag. Gå praksisserne igennem, og registrér, hvor du allerede opfylder dem, og med hvilken dokumentation.
2. Rangér hullerne efter risiko. SSDF forventer, at du anvender det ud fra din egen risiko, så ikke alle praksisser fortjener samme dybde.
3. Automatisér dokumentationen. Dokumentation, der kommer ud af pipelinen, forbliver aktuel uden ekstra arbejde. Dokumentation skrevet manuelt bliver forældet.
4. Tildel ejere. Hver praksis skal have en ansvarlig. De fleste vil ligge hos engineering snarere end sikkerhed.
5. Gennemgå med faste intervaller. Opdatér kortlægningen, efterhånden som dine værktøjer ændrer sig, og efterhånden som version 1.2 skrider frem.

SSDF, SLSA og CRA

SSDF siger, hvad et sikkert udviklingsprogram bør opnå. SLSA går i dybden med én del af det, build-integritet. EU's Cyber Resilience Act er en lov med sine egne forpligtelser. Arbejde udført for det ene kan overføres til de andre, for de forventer alle, at du ved, hvad der er i din software, og håndterer sårbarheder i den.

Hvor CRACI passer ind

SSDF er et bredt program, og intet værktøj dækker det. CRACI leverer dokumentation for de praksisser, der afhænger af buildet og af det leverede: SBOM'er fra hvert GitHub Actions-job, isolerede jobs og egress-kontrol i build-miljøet, løbende overvågning af leveret software og triage af det, den finder. CRACI gør dig ikke konform, og kortlægningen og attesteringen bliver hos dig. Se forsyningskædesikkerhed for software med CRACI.

NIST SSDF: ofte stillede spørgsmål

Hvad er NIST SSDF?

Secure Software Development Framework, udgivet som NIST SP 800-218. Det er et sæt af praksisser for at bygge sikker software, organiseret i fire grupper: forbered organisationen, beskyt softwaren, producér velsikret software og reagér på sårbarheder.

Hvad står SSDF for?

Secure Software Development Framework.

Er SSDF obligatorisk?

Nej. Det er vejledning, ikke lov. Amerikanske føderale leverandører skulle tidligere attestere, at de fulgte praksisser fra det, men OMB-memoet M-26-05 ophævede det krav i januar 2026. Myndigheder kan stadig bede om attesteringer.

Hvad er den seneste version af SSDF?

Version 1.1 (SP 800-218, februar 2022) er den aktuelle endelige version. Version 1.2 blev offentliggjort som udkast i december 2025, så tjek NIST's websted for dens status.

Hvad er forskellen på SSDF og SLSA?

SSDF dækker sikker udvikling som helhed, på tværs af mennesker, processer og teknologi. SLSA går i dybden med build-integritet og provenance. De fungerer godt sammen.

Kræver SSDF en SBOM?

Det beder dig om at indsamle og dele provenance-data for komponenterne i hver release og nævner en SBOM som en måde at gøre det på. Det beskriver resultater frem for at påbyde et bestemt værktøj.