NIST SSDF (SP 800-218)

De vier groepen werkwijzen

Het SSDF deelt zijn werkwijzen in vier groepen in. Elke werkwijze beschrijft een uitkomst, en NIST zegt expliciet dat het geen checklist is: het is een basis voor planning op grond van risico.

Groep	Doel	Voorbeelden
Prepare the Organization (PO)	Mensen, processen en tools staan klaar	Beveiligingseisen vastleggen, rollen toewijzen, de ontwikkelomgeving beveiligen
Protect the Software (PS)	Code en releases zijn beschermd tegen manipulatie	Alle vormen van code beschermen, de integriteit van releases verifiëren, elke release archiveren
Produce Well-Secured Software (PW)	Weinig kwetsbaarheden in wat u uitbrengt	Ontwerpen voor beveiliging, goed beveiligde software hergebruiken, code beoordelen en testen
Respond to Vulnerabilities (RV)	Resterende fouten vinden en aanpakken	Kwetsbaarheden doorlopend identificeren, prioriteren en oplossen, grondoorzaken analyseren

De werkwijzen die uw softwareketen raken

• PO.3, ondersteunende toolchains, en PO.5, veilige omgevingen. Uw CI-systeem hoort bij wat u moet beschermen. Zie de beveiligingschecklist voor CI/CD-pipelines.
• PS.3, elke release archiveren en beschermen. Dit omvat het verzamelen van herkomstgegevens voor de componenten van elke release, en het SSDF noemt de SBOM als manier om dat te doen.
• PW.4, goed beveiligde software hergebruiken. Componenten van derden moeten worden beoordeeld en actueel worden gehouden, en daar komt software composition analysis in beeld.
• RV.1, kwetsbaarheden doorlopend identificeren. Dit is een doorlopende taak, geen controlepunt bij de release, dus het vraagt om monitoring van wat u al hebt geleverd.
• RV.2, beoordelen, prioriteren en verhelpen. Zie hoe u kwetsbaarheden prioriteert.

Is het SSDF verplicht?

Niet op zichzelf. Het is een publicatie van NIST, geen wet. Een aantal jaren was het direct van belang voor Amerikaanse federale leveranciers, omdat de OMB-memo's M-22-18 en M-23-16 hen verplichtten te verklaren dat ze werkwijzen uit het SSDF volgden. Dat veranderde op 23 januari 2026: OMB-memo M-26-05 trok beide in en stapte over op een risicogebaseerde aanpak. Agentschappen mogen het gemeenschappelijke verklaringsformulier en de standaarden van NIST nog gebruiken, maar zijn daar niet langer toe verplicht, dus leveranciers moeten erop rekenen dat de eisen per agentschap verschillen.

Buiten federale inkoop blijft het SSDF nuttig als gedeelde taal. Klanten ontlenen er onderdelen aan voor beveiligingsvragenlijsten, en het sluit aan op andere standaarden.

SSDF-versies

• Versie 1.1, SP 800-218, gepubliceerd in februari 2022, is de huidige definitieve versie.
• Versie 1.2, SP 800-218 Revision 1, is in december 2025 als concept gepubliceerd.
• SP 800-218A is een communityprofiel dat het SSDF uitbreidt naar generatieve AI en dual-use foundation models.

Hoe voert u het SSDF in?

1. Breng in kaart wat u vandaag doet. Loop de werkwijzen door en noteer waar u er al aan voldoet, en met welk bewijs.
2. Rangschik de hiaten op risico. Het SSDF verwacht dat u het toepast naar uw eigen risico, dus niet elke werkwijze verdient evenveel diepgang.
3. Automatiseer het bewijs. Bewijs dat uit de pipeline komt, blijft zonder extra werk actueel. Handmatig geschreven bewijs veroudert.
4. Wijs eigenaren aan. Elke werkwijze heeft iemand nodig die verantwoordelijk is. De meeste komen bij engineering te liggen, niet bij security.
5. Evalueer op vaste momenten. Werk de mapping bij als uw tools veranderen en naarmate versie 1.2 vordert.

SSDF, SLSA en de CRA

Het SSDF zegt wat een programma voor veilige ontwikkeling moet bereiken. SLSA gaat diep in op één onderdeel daarvan, buildintegriteit. De EU Cyber Resilience Act is een wet met eigen verplichtingen. Werk voor het ene komt ook de andere ten goede, omdat ze allemaal verwachten dat u weet wat er in uw software zit en kwetsbaarheden daarin afhandelt.

Waar CRACI past

Het SSDF is een breed programma, en geen enkele tool dekt het. CRACI levert bewijs voor de werkwijzen die afhangen van de build en van wat is geleverd: SBOM's van elke GitHub Actions-job, geïsoleerde jobs en egresscontrole in de buildomgeving, doorlopende monitoring van geleverde software en triage van wat daaruit naar voren komt. CRACI maakt u niet conform, en de mapping en de verklaring blijven bij u. Zie ketenbeveiliging van software met CRACI.

NIST SSDF: veelgestelde vragen

Wat is het NIST SSDF?

Het Secure Software Development Framework, gepubliceerd als NIST SP 800-218. Het is een verzameling werkwijzen voor het bouwen van veilige software, ingedeeld in vier groepen: de organisatie voorbereiden, de software beschermen, goed beveiligde software produceren en reageren op kwetsbaarheden.

Waar staat SSDF voor?

Secure Software Development Framework.

Is het SSDF verplicht?

Nee. Het is een richtlijn, geen wet. Amerikaanse federale leveranciers moesten vroeger verklaren dat ze werkwijzen eruit volgden, maar OMB-memo M-26-05 trok die eis in januari 2026 in. Agentschappen mogen nog steeds om zulke verklaringen vragen.

Wat is de nieuwste versie van het SSDF?

Versie 1.1 (SP 800-218, februari 2022) is de huidige definitieve versie. Versie 1.2 is in december 2025 als concept gepubliceerd, dus controleer de status op de site van NIST.

Wat is het verschil tussen het SSDF en SLSA?

Het SSDF behandelt veilige ontwikkeling als geheel, over mensen, processen en technologie heen. SLSA gaat diep in op buildintegriteit en herkomst. Ze vullen elkaar goed aan.

Vereist het SSDF een SBOM?

Het vraagt u herkomstgegevens voor de componenten van elke release te verzamelen en te delen, en noemt een SBOM als een manier om dat te doen. Het beschrijft uitkomsten en schrijft geen specifieke tool voor.