NIST SSDF (SP 800-218)

De fire praksisgruppene

SSDF ordner praksisene sine i fire grupper. Hver praksis oppgir et resultat, og NIST er tydelig på at det ikke er en sjekkliste: Det er et grunnlag for planlegging basert på risiko.

Gruppe	Mål	Eksempler
Prepare the Organization (PO)	Mennesker, prosesser og verktøy er klare	Definere sikkerhetskrav, tildele roller, sikre utviklingsmiljøet
Protect the Software (PS)	Kode og utgivelser er sikret mot manipulering	Beskytte alle former for kode, verifisere utgivelsers integritet, arkivere hver utgivelse
Produce Well-Secured Software (PW)	Et lavt antall sårbarheter i det du gir ut	Designe for sikkerhet, gjenbruke godt sikret programvare, gjennomgå og teste kode
Respond to Vulnerabilities (RV)	Finne gjenværende feil og håndtere dem	Identifisere sårbarheter kontinuerlig, prioritere og rette dem, analysere rotårsaker

Praksisene som berører leverandørkjeden din

• PO.3, støttende verktøykjeder, og PO.5, sikre miljøer. CI-systemet ditt er en del av det du må beskytte. Se sikkerhetssjekklisten for CI/CD-pipelines.
• PS.3, arkivere og beskytte hver utgivelse. Dette omfatter å samle inn provenance-data for komponentene i hver utgivelse, og SSDF nevner SBOM som en måte å gjøre det på.
• PW.4, gjenbruke godt sikret programvare. Tredjepartskomponenter bør vurderes og holdes oppdatert, og det er der software composition analysis passer inn.
• RV.1, identifisere sårbarheter fortløpende. Dette er en løpende plikt, ikke en sjekk ved utgivelse, så det krever overvåking av det du allerede har levert.
• RV.2, vurdere, prioritere og rette. Se slik prioriterer du sårbarheter.

Er SSDF obligatorisk?

Ikke i seg selv. Det er en NIST-publikasjon, ikke en lov. I noen år var det direkte viktig for amerikanske føderale leverandører, fordi OMB-notatene M-22-18 og M-23-16 krevde at de attesterte praksiser hentet fra det. Det endret seg 23. januar 2026: OMB-notatet M-26-05 opphevet begge og gikk over til en risikobasert tilnærming. Byråer kan fortsatt bruke det felles attesteringsskjemaet og NISTs standarder, men de er ikke lenger pålagt det, så leverandører bør regne med at kravene varierer fra byrå til byrå.

Utenfor føderale innkjøp er SSDF fortsatt nyttig som et felles språk. Kunder låner fra det i sikkerhetsspørreskjemaer, og det kan kobles til andre standarder.

SSDF-versjoner

• Versjon 1.1, SP 800-218, publisert i februar 2022, er den gjeldende endelige versjonen.
• Versjon 1.2, SP 800-218 Revision 1, ble publisert som utkast i desember 2025.
• SP 800-218A er en community-profil som utvider SSDF til generativ AI og dual-use foundation models.

Slik tar du i bruk SSDF

1. Kartlegg hva du gjør i dag. Gå gjennom praksisene og registrer hvor du allerede oppfyller dem, og med hvilken dokumentasjon.
2. Ranger hullene etter risiko. SSDF forventer at du anvender det etter din egen risiko, så ikke hver praksis fortjener samme dybde.
3. Automatiser dokumentasjonen. Dokumentasjon som kommer ut av pipelinen, holder seg oppdatert uten ekstra arbeid. Dokumentasjon skrevet for hånd blir utdatert.
4. Utpek eiere. Hver praksis trenger en ansvarlig. De fleste vil ligge hos utvikling, ikke hos sikkerhet.
5. Gå gjennom med faste mellomrom. Oppdater kartleggingen etter hvert som verktøyene dine endres og versjon 1.2 kommer videre.

SSDF, SLSA og CRA

SSDF sier hva et program for sikker utvikling bør oppnå. SLSA går i dybden på én del av det, byggeintegritet. EUs Cyber Resilience Act er en lov med egne forpliktelser. Arbeid som gjøres for ett av dem, kommer de andre til gode, fordi alle forventer at du vet hva som er i programvaren din, og at du håndterer sårbarheter i den.

Hvor CRACI passer inn

SSDF er et bredt program, og ikke noe verktøy dekker det. CRACI leverer dokumentasjon for praksisene som avhenger av bygget og av det som er levert: SBOM-er fra hver GitHub Actions-jobb, isolerte jobber og egress-kontroll i byggemiljøet, løpende overvåking av levert programvare og prioritering av det som blir funnet. CRACI gjør deg ikke konform, og kartleggingen og attesteringen blir værende hos deg. Se sikkerhet i programvareleverandørkjeden med CRACI.

NIST SSDF: ofte stilte spørsmål

Hva er NIST SSDF?

Secure Software Development Framework, publisert som NIST SP 800-218. Det er et sett med praksiser for å bygge sikker programvare, ordnet i fire grupper: forberede organisasjonen, beskytte programvaren, produsere godt sikret programvare og respondere på sårbarheter.

Hva står SSDF for?

Secure Software Development Framework.

Er SSDF obligatorisk?

Nei. Det er veiledning, ikke lov. Amerikanske føderale leverandører måtte tidligere attestere praksiser fra det, men OMB-notatet M-26-05 opphevet det kravet i januar 2026. Byråer kan fortsatt be om attesteringer.

Hva er den nyeste versjonen av SSDF?

Versjon 1.1 (SP 800-218, februar 2022) er den gjeldende endelige versjonen. Versjon 1.2 ble publisert som utkast i desember 2025, så sjekk NISTs nettsted for status.

Hva er forskjellen på SSDF og SLSA?

SSDF dekker sikker utvikling som helhet, på tvers av mennesker, prosesser og teknologi. SLSA går i dybden på byggeintegritet og provenance. De fungerer godt sammen.

Krever SSDF en SBOM?

Det ber deg samle inn og dele provenance-data for komponentene i hver utgivelse, og nevner en SBOM som én måte å gjøre det på. Det beskriver resultater i stedet for å kreve et bestemt verktøy.