NIST SSDF (SP 800-218)

De fyra grupperna av arbetssätt

SSDF delar in sina arbetssätt i fyra grupper. Varje arbetssätt anger ett resultat, och NIST är tydligt med att det inte är en checklista: det är en grund för planering utifrån risk.

Grupp	Mål	Exempel
Förbered organisationen (PO)	Människor, processer och verktyg är redo	Definiera säkerhetskrav, tilldela roller, säkra utvecklingsmiljön
Skydda programvaran (PS)	Kod och releaser är skyddade mot manipulation	Skydda kod i alla former, verifiera releasers integritet, arkivera varje release
Producera väl skyddad programvara (PW)	Så få sårbarheter som möjligt i det du släpper	Designa för säkerhet, återanvänd väl skyddad programvara, granska och testa kod
Reagera på sårbarheter (RV)	Hitta kvarvarande brister och hantera dem	Identifiera sårbarheter löpande, prioritera och åtgärda dem, analysera grundorsaker

Arbetssätten som berör din leveranskedja

• PO.3, stödjande verktygskedjor, och PO.5, säkra miljöer. Ditt CI-system är en del av det du måste skydda. Se checklistan för säkerhet i CI/CD-pipelinen.
• PS.3, arkivera och skydda varje release. Det innefattar att samla in proveniensdata för komponenterna i varje release, och SSDF nämner SBOM som ett sätt att göra det.
• PW.4, återanvänd väl skyddad programvara. Tredjepartskomponenter ska granskas och hållas uppdaterade, och det är där software composition analysis passar in.
• RV.1, identifiera sårbarheter löpande. Det här är en löpande skyldighet, inte en kontrollpunkt vid release, så det kräver bevakning av det du redan levererat.
• RV.2, bedöm, prioritera och åtgärda. Se så prioriterar du sårbarheter.

Är SSDF obligatoriskt?

Inte i sig. Det är en publikation från NIST, inte en lag. Under några år var det direkt viktigt för federala leverantörer i USA, eftersom OMB-memona M-22-18 och M-23-16 krävde intyg om att de följde arbetssätt hämtade från ramverket. Det ändrades den 23 januari 2026: OMB-memot M-26-05 upphävde båda och övergick till ett riskbaserat synsätt. Myndigheter får fortfarande använda det gemensamma attesteringsformuläret och NIST:s standarder, men de är inte längre skyldiga att göra det, så leverantörer bör räkna med att kraven varierar mellan myndigheter.

Utanför federal upphandling är SSDF fortfarande användbart som ett gemensamt språk. Kunder lånar från det i säkerhetsenkäter, och det går att mappa mot andra standarder.

SSDF-versioner

• Version 1.1, SP 800-218, publicerad i februari 2022, är den aktuella slutliga versionen.
• Version 1.2, SP 800-218 Revision 1, publicerades som utkast i december 2025.
• SP 800-218A är en community-profil som utvidgar SSDF till generativ AI och grundmodeller med dubbla användningsområden.

Så inför du SSDF

1. Kartlägg vad du gör i dag. Gå igenom arbetssätten och notera var du redan uppfyller dem, och med vilket underlag.
2. Rangordna luckorna efter risk. SSDF förväntar sig att du tillämpar det efter din egen risk, så inte varje arbetssätt förtjänar samma djup.
3. Automatisera underlaget. Underlag som kommer ur pipelinen håller sig aktuellt utan extra arbete. Underlag som skrivs för hand blir inaktuellt.
4. Utse ägare. Varje arbetssätt behöver någon som ansvarar. De flesta kommer att ligga hos utvecklingen snarare än hos säkerhet.
5. Gå igenom med fasta intervall. Uppdatera kartläggningen när dina verktyg ändras och när version 1.2 utvecklas.

SSDF, SLSA och CRA

SSDF säger vad ett program för säker utveckling bör uppnå. SLSA går på djupet med en del av det, byggintegritet. EU:s Cyber Resilience Act är en lag med egna skyldigheter. Arbete som görs för ett av dem går att föra över till de andra, eftersom alla förväntar sig att du vet vad som finns i din programvara och hanterar sårbarheter i den.

Var CRACI passar in

SSDF är ett brett program, och inget verktyg täcker det. CRACI ger underlag för de arbetssätt som är beroende av bygget och av det som levererats: SBOM:er från varje GitHub Actions-jobb, isolerade jobb och egress-kontroll i byggmiljön, löpande bevakning av levererad programvara och triagering av det som hittas. CRACI gör dig inte konform, och kartläggningen och attesteringen ligger kvar hos dig. Se säkerhet i mjukvarans leveranskedja med CRACI.

NIST SSDF: vanliga frågor

Vad är NIST SSDF?

Secure Software Development Framework, publicerat som NIST SP 800-218. Det är en samling arbetssätt för att bygga säker programvara, ordnade i fyra grupper: förbered organisationen, skydda programvaran, producera väl skyddad programvara och reagera på sårbarheter.

Vad står SSDF för?

Secure Software Development Framework.

Är SSDF obligatoriskt?

Nej. Det är vägledning, inte lag. Federala leverantörer i USA var tidigare tvungna att intyga att de följde arbetssätt från ramverket, men OMB-memot M-26-05 upphävde det kravet i januari 2026. Myndigheter kan fortfarande begära intyg.

Vilken är den senaste versionen av SSDF?

Version 1.1 (SP 800-218, februari 2022) är den aktuella slutliga versionen. Version 1.2 publicerades som utkast i december 2025, så kontrollera dess status på NIST:s webbplats.

Vad är skillnaden mellan SSDF och SLSA?

SSDF täcker säker utveckling som helhet: människor, process och teknik. SLSA går på djupet med byggintegritet och proveniens. De fungerar bra tillsammans.

Kräver SSDF en SBOM?

Ramverket ber dig samla in och dela proveniensdata för komponenterna i varje release och nämner en SBOM som ett sätt att göra det. Det beskriver resultat snarare än att föreskriva ett specifikt verktyg.