NIST SSDF (SP 800-218)

Die vier Praktikengruppen

Das SSDF ordnet seine Praktiken in vier Gruppen. Jede Praktik beschreibt ein Ergebnis, und NIST stellt ausdrücklich klar, dass es keine Checkliste ist, sondern eine Grundlage für eine risikobasierte Planung.

Gruppe	Ziel	Beispiele
Prepare the Organization (PO)	Menschen, Prozesse und Tools sind bereit	Sicherheitsanforderungen definieren, Rollen zuweisen, die Entwicklungsumgebung absichern
Protect the Software (PS)	Code und Releases sind vor Manipulation geschützt	Code in jeder Form schützen, die Integrität von Releases überprüfen, jedes Release archivieren
Produce Well-Secured Software (PW)	Wenige Schwachstellen in dem, was Sie veröffentlichen	Auf Sicherheit auslegen, gut gesicherte Software wiederverwenden, Code prüfen und testen
Respond to Vulnerabilities (RV)	Verbleibende Fehler finden und behandeln	Schwachstellen laufend identifizieren, priorisieren und beheben, Ursachen analysieren

Die Praktiken, die Ihre Lieferkette berühren

• PO.3, unterstützende Toolchains, und PO.5, sichere Umgebungen. Ihr CI-System gehört zu dem, was Sie schützen müssen. Siehe die Sicherheitscheckliste für CI/CD-Pipelines.
• PS.3, jedes Release archivieren und schützen. Dazu gehört, Provenienzdaten für die Komponenten jedes Releases zu erfassen, und das SSDF nennt die SBOM als einen Weg dafür.
• PW.4, gut gesicherte Software wiederverwenden. Drittanbieterkomponenten sollten geprüft und aktuell gehalten werden, und hier setzt die Software Composition Analysis an.
• RV.1, Schwachstellen laufend identifizieren. Das ist eine laufende Pflicht und kein Release-Gate, es verlangt also, das bereits Ausgelieferte zu überwachen.
• RV.2, bewerten, priorisieren und beheben. Siehe so priorisieren Sie Schwachstellen.

Ist das SSDF verpflichtend?

An sich nicht. Es ist eine Veröffentlichung des NIST, kein Gesetz. Einige Jahre lang war es für US-Bundeslieferanten direkt relevant, weil die OMB-Memos M-22-18 und M-23-16 sie verpflichteten, die Einhaltung daraus abgeleiteter Praktiken zu bestätigen. Das änderte sich am 23. Januar 2026: Das OMB-Memo M-26-05 hob beide auf und ging zu einem risikobasierten Ansatz über. Behörden dürfen das gemeinsame Attestierungsformular und die Standards des NIST weiter nutzen, müssen es aber nicht mehr. Lieferanten sollten also damit rechnen, dass die Anforderungen je nach Behörde variieren.

Außerhalb der öffentlichen Beschaffung des US-Bundes bleibt das SSDF als gemeinsame Sprache nützlich. Kunden übernehmen daraus Inhalte für ihre Sicherheitsfragebögen, und es lässt sich auf andere Standards abbilden.

SSDF-Versionen

• Version 1.1, SP 800-218, veröffentlicht im Februar 2022, ist die aktuelle finale Version.
• Version 1.2, SP 800-218 Revision 1, wurde im Dezember 2025 als Entwurf veröffentlicht.
• SP 800-218A ist ein Community-Profil, das das SSDF auf generative KI und Dual-Use-Foundation-Modelle ausweitet.

So führen Sie das SSDF ein

1. Den Ist-Zustand abbilden. Gehen Sie die Praktiken durch und halten Sie fest, wo Sie sie bereits erfüllen und mit welchen Nachweisen.
2. Die Lücken nach Risiko ordnen. Das SSDF erwartet, dass Sie es entsprechend Ihrem eigenen Risiko anwenden, nicht jede Praktik verdient also dieselbe Tiefe.
3. Die Nachweise automatisieren. Nachweise, die aus der Pipeline kommen, bleiben ohne Zusatzaufwand aktuell. Von Hand geschriebene Nachweise veralten.
4. Verantwortliche benennen. Jede Praktik braucht jemanden, der dafür zuständig ist. Die meisten liegen eher bei der Entwicklung als bei der Sicherheit.
5. In festen Abständen überprüfen. Aktualisieren Sie die Zuordnung, wenn sich Ihre Tools ändern und wenn Version 1.2 voranschreitet.

SSDF, SLSA und der CRA

Das SSDF sagt, was ein Programm für sichere Entwicklung erreichen sollte. SLSA geht bei einem Teil davon in die Tiefe, der Build-Integrität. Der EU Cyber Resilience Act ist ein Gesetz mit eigenen Pflichten. Arbeit für das eine lässt sich auf die anderen übertragen, denn alle erwarten, dass Sie wissen, was in Ihrer Software steckt, und dass Sie Schwachstellen darin behandeln.

Wo CRACI ansetzt

Das SSDF ist ein breit angelegtes Programm, und kein Tool deckt es ab. CRACI liefert Nachweise für die Praktiken, die vom Build und vom Ausgelieferten abhängen: SBOMs aus jedem GitHub-Actions-Job, isolierte Jobs und Egress-Kontrolle in der Build-Umgebung, laufende Überwachung ausgelieferter Software und die Sichtung dessen, was sie findet. CRACI macht Sie nicht konform, und die Zuordnung und die Attestierung bleiben bei Ihnen. Siehe Software-Lieferkettensicherheit mit CRACI.

NIST SSDF: häufig gestellte Fragen

Was ist das NIST SSDF?

Das Secure Software Development Framework, veröffentlicht als NIST SP 800-218. Es ist eine Sammlung von Praktiken für die Entwicklung sicherer Software, geordnet in vier Gruppen: die Organisation vorbereiten, die Software schützen, gut gesicherte Software produzieren und auf Schwachstellen reagieren.

Wofür steht SSDF?

Secure Software Development Framework.

Ist das SSDF verpflichtend?

Nein. Es ist eine Leitlinie, kein Gesetz. US-Bundeslieferanten mussten früher die Einhaltung daraus abgeleiteter Praktiken bestätigen, aber das OMB-Memo M-26-05 hob diese Pflicht im Januar 2026 auf. Behörden können weiterhin Attestierungen verlangen.

Was ist die neueste Version des SSDF?

Version 1.1 (SP 800-218, Februar 2022) ist die aktuelle finale Version. Version 1.2 wurde im Dezember 2025 als Entwurf veröffentlicht. Den Stand finden Sie auf der Website des NIST.

Was ist der Unterschied zwischen dem SSDF und SLSA?

Das SSDF behandelt sichere Entwicklung als Ganzes, über Menschen, Prozesse und Technologie hinweg. SLSA geht bei Build-Integrität und Provenienz in die Tiefe. Beide ergänzen sich gut.

Verlangt das SSDF eine SBOM?

Es verlangt, Provenienzdaten für die Komponenten jedes Releases zu erfassen und zu teilen, und nennt eine SBOM als einen Weg dafür. Es beschreibt Ergebnisse, statt ein bestimmtes Tool vorzuschreiben.