NIST Secure Software Development Framework (SSDF): Leitfaden 2026

Sophie Laurent Legal & Compliance Lead, YuSMP Group · Bildet sichere Auslieferung auf die Frameworks und Selbstauskünfte ab, gegen die US-föderale und Enterprise-Käufer prüfen

Kurzfassung — das NIST SSDF in einem Absatz

Was ist das NIST Secure Software Development Framework (SSDF)?

Das NIST Secure Software Development Framework (SSDF) ist eine Sammlung übergeordneter, methodenunabhängiger sicherer Entwicklungspraktiken, die das US National Institute of Standards and Technology als Special Publication 800-218 veröffentlicht hat. Statt Tools oder einen Lebenszyklus vorzuschreiben, beschreibt das SSDF die Ergebnisse guter sicherer Entwicklung und gruppiert sie in vier Praktikfamilien. Version 1.1 definiert 19 Praktiken, aufgeteilt in 42 Aufgaben, jede mit Verweisen auf etablierte Quellen wie OWASP und BSIMM. Weil es ergebnisorientiert ist, passt derselbe Rahmen auf ein Agile-Team, eine DevOps-Pipeline oder ein Wasserfall-Programm.

Das Framework zählt am meisten dort, wo Software regulatorisches, finanzielles oder sicherheitsrelevantes Gewicht trägt — weshalb regulierte Organisationen, die mit unseren Teams für sichere Enterprise-Softwareentwicklung bauen, die SSDF-Konformität als Grundlinie für den Eintritt in föderale und große Enterprise-Märkte behandeln. Das SSDF ersetzt nicht Ihren Entwicklungsprozess; es gibt Ihnen ein gemeinsames Vokabular, um zu zeigen, dass der Prozess sicher ist. Wenn Sie den Auslieferungsprozess wollen, auf dem das Framework aufsetzt, führt unser Leitfaden zum sicheren Softwareentwicklungszyklus durch die Phasen; hier konzentrieren wir uns auf den NIST-Rahmen selbst — was er verlangt und wie Sie belegen, dass Sie ihn erfüllen.

Warum das SSDF existiert: EO 14028 und die Software-Lieferkette

Das SSDF existiert, weil Angriffe von einzelnen Anwendungen auf die Software-Lieferkette gewandert sind und die US-Regierung einen einzigen Standard dafür brauchte, was „sichere Entwicklung“ bedeutet. Aufsehenerregende Kompromittierungen von Buildsystemen und weit verbreiteten Komponenten zeigten, dass eine einzige manipulierte Abhängigkeit oder Pipeline Tausende nachgelagerter Organisationen auf einmal erreichen kann. Im Mai 2021 beauftragte die US Executive Order 14028 NIST damit, sichere Entwicklungspraktiken für an die Bundesregierung verkaufte Software zu definieren, und das SSDF (SP 800-218, finalisiert im Februar 2022) ist das Ergebnis.

Diese Herkunft erklärt die Gestalt des Frameworks. Es legt großes Gewicht auf den Schutz der Build-Pipeline und die Verifikation von Drittkomponenten — genau die Glieder, die Angreifer ausnutzen — statt allein auf den Anwendungscode, den ein Entwickler schreibt. Sie erklärt auch, warum das SSDF zum Beschaffungsinstrument wurde: Weil die Bundesregierung der größte einzelne Softwarekäufer ist, wird ein an ihre Einkäufe gebundenes Framework rasch zur faktischen Branchenerwartung. Für die Laufzeitkontrollen, die die Praktiken auf Framework-Ebene ergänzen, behandelt unser Leitfaden zu Best Practices für Web-App-Sicherheit, was in der Anwendung selbst zu härten ist.

Die vier SSDF-Praktikgruppen: PO, PS, PW, RV

Das NIST SSDF gliedert seine gesamte Arbeit in vier Praktikgruppen, und sie zu verstehen ist der schnellste Weg, das Framework zu verstehen. Jede Gruppe beantwortet eine andere Frage: Sind Sie aufgestellt, um sicher zu entwickeln, sind Ihre Software und ihr Build geschützt, wird die Software selbst sicher produziert, und können Sie reagieren, wenn etwas gefunden wird? Version 1.1 verteilt 19 Praktiken und 42 Aufgaben über diese vier Gruppen. Die Tabelle fasst zusammen, was jede abdeckt.

Der Reihe nach gelesen, erzählen die Gruppen eine Geschichte: PO macht die Organisation bereit, PS schützt Code und Pipeline, PW produziert die Software sicher, und RV schließt die Schleife, wenn eine Schwachstelle auftaucht. Der Großteil der täglichen Engineering-Arbeit — Bedrohungsmodellierung, sicheres Programmieren, Abhängigkeitsprüfung, Testen — liegt in PW, weshalb sie die meisten Praktiken enthält. PS ist die Gruppe, die am unmittelbarsten aus Lieferkettenangriffen entstanden ist: Hier leben Signierung, Herkunftsnachweis und Buildsystem-Schutz. Behandeln Sie die Praktiken nicht als Reifegradleiter; sie sind Ergebnisse, die fortlaufend zu erreichen sind, keine Stufen, die man einmal durchläuft.

Was sich 2025–2026 geändert hat: Selbstauskunft und EO 14306

Die größte jüngere Änderung ist, dass der Durchsetzungsmechanismus rund um das SSDF 2025 gelockert wurde, während die Pflicht zur Einhaltung des Frameworks blieb. Nach EO 14028 veröffentlichte CISA im März 2024 ein Selbstauskunftsformular zur sicheren Softwareentwicklung, und die OMB-Memoranden M-22-18 und M-23-16 verpflichteten Bundesbehörden, diese Selbstauskunft von ihren Software-Lieferanten einzuholen. Dann entfernte die Executive Order 14306 im Juni 2025 die Pflicht, dass CISA die Selbstauskünfte zentral validiert, und strich die zugehörige Änderung der Federal Acquisition Regulation.

Der praktische Effekt für Software-Lieferanten 2026 ist subtil, aber wichtig: Der zentralisierte Validierungsschritt ist weg, doch die Erwartung, dass Sie das SSDF einhalten und prüfbare Nachweise vorlegen können, ist es nicht. Behörden können das Selbstauskunftsformular weiterhin anfordern, und Enterprise-Käufer verlangen dieselben Nachweise zunehmend unabhängig von jeder föderalen Vorgabe. NIST hat das Framework zudem weiterentwickelt — ein Begleitprofil, SP 800-218A, erweitert das SSDF auf KI-Systeme, und die Arbeit an SP 800-218 Rev. 1 frischt die Praktiken auf. Behandeln Sie die Versionsnummern und die Mechanik der Selbstauskunft als bewegliches Ziel; behandeln Sie die vier Praktikgruppen als den stabilen Kern, um den herum Sie Policy bauen.

SBOM: nachweisen, was in Ihrer Software steckt

Eine Software Bill of Materials (SBOM) ist das einzelne Artefakt, das mehrere SSDF-Praktiken am unmittelbarsten belegt, weshalb es eine eigene Erwähnung verdient. Eine SBOM ist ein maschinenlesbares Inventar jeder Komponente und Abhängigkeit in einem Build — die Zutatenliste Ihrer Software. Die Praktiken der Gruppe Produce Well-Secured Software (PW) verlangen, dass Sie Dritt- und Open-Source-Komponenten beschaffen, verifizieren und nachverfolgen, und die Gruppe Respond to Vulnerabilities (RV) verlangt, dass Sie reagieren, wenn sich eine davon als verwundbar erweist. Eine SBOM ist es, die beides von einem Wunsch in etwas Belegbares verwandelt.

Der konkrete Nutzen zeigt sich am schlimmsten Tag. Wird eine schwerwiegende Schwachstelle in einer beliebten Bibliothek offengelegt, fragt jeder Käufer und Regulierer: Sind Sie betroffen, und wo? Ohne SBOM bedeutet die Antwort ein Audit unter Druck. Mit einer je Release erzeugten und aufbewahrten SBOM ist es ein Nachschlagen. Deshalb ist eine SBOM je Release — in einem Standardformat wie SPDX oder CycloneDX — zur Grunderwartung föderaler und Enterprise-Käufer geworden, die die SSDF-Konformität bewerten, nicht zu einem optionalen Zusatz.

Wer muss das NIST SSDF einhalten?

Von jeder Organisation, die Software für die US-Bundesregierung produziert, wird in der Praxis erwartet, dass sie das NIST SSDF einhält — und eine wachsende Gruppe von Enterprise-Käufern erwartet es ebenfalls. Als NIST-Veröffentlichung ist das Framework freiwillig, doch die darauf aufbauenden Beschaffungsregeln machen die Konformität zur Bedingung, um in mehreren Märkten Geschäfte zu tätigen. Die am stärksten betroffenen Gruppen sind unten aufgeführt.

• Föderale Software-Lieferanten. Unternehmen, die Software oder Software-as-a-Service an US-Behörden verkaufen, müssen eine Selbstauskunft zur sicheren Softwareentwicklung vorlegen, gestützt auf SSDF-konforme Praktiken und Nachweise.
• Zulieferer föderaler Auftragnehmer. Ist Ihre Software in ein Produkt eingebettet, das ein Hauptauftragnehmer an die Regierung verkauft, fließt die SSDF-Erwartung typischerweise an Sie weiter.
• Enterprise-SaaS- und Plattform-Anbieter. Große Enterprise-Käufer verweisen in Sicherheitsfragebögen und Lieferantenprüfungen zunehmend auf das SSDF, unabhängig von jeder föderalen Bindung.
• Software in regulierten Branchen. Lieferanten in Finanzwesen, Gesundheit und kritischer Infrastruktur nutzen das SSDF neben Branchenregeln, um Prüfern sichere Entwicklung nachzuweisen.

Trifft heute nichts davon auf Sie zu, lohnt sich das Framework dennoch als gut strukturierte Grundlinie — doch die Dringlichkeit skaliert damit, wie nah Sie an föderalen oder großen Enterprise-Käufern sind. Für die angrenzenden Assurance-Frameworks, nach denen Käufer fragen, siehe unseren Leitfaden zu SOC 2 Type II für SaaS-Startups, der sich natürlich mit einem SSDF-Programm ergänzt.

Wie Sie das SSDF umsetzen: ein Schritt-für-Schritt-Weg

Der schnellste Weg, das SSDF zu übernehmen, ist, zuerst Ihren aktuellen Prozess darauf abzubilden und dann die Lücken zu schließen — nicht, Ihren Entwicklungslebenszyklus um das Framework herum neu zu bauen. Die meisten Teams tun bereits viel von dem, was das SSDF verlangt; die Arbeit besteht darin, es explizit, konsistent und belegt zu machen. Dies sind die praktischen Schritte, der Reihe nach.

1. Bilden Sie Ihre aktuellen Praktiken auf die vier Gruppen ab. Nehmen Sie PO, PS, PW und RV und notieren Sie ehrlich, was Sie für jede bereits tun. Diese Lückenanalyse ist das ganze Projekt im Kleinen und zeigt meist, dass Sie weiter sind als erwartet.
2. Weisen Sie jeder Praktik einen Verantwortlichen zu. Jede SSDF-Praktik braucht eine benannte Rolle, die dafür verantwortlich ist. Nicht zugewiesene Praktiken sind die, die unter Termindruck verrutschen.
3. Schützen Sie die Pipeline (PS). Sperren Sie Quell- und Buildsysteme ab, kontrollieren Sie den Zugriff und signieren Sie Ihre Artefakte, damit ihre Integrität und Herkunft verifizierbar sind. Dies ist die Gruppe, die die meisten Angreifer ins Visier nehmen und die Käufer am genauesten prüfen.
4. Automatisieren Sie PW in der Pipeline. Verdrahten Sie Prüfungen für sicheres Programmieren, statische Analyse, Abhängigkeits- und SBOM-Erzeugung in CI/CD, sodass sie bei jeder Änderung laufen statt in einem Quartalsreview.
5. Bauen Sie eine Schwachstellenreaktion auf (RV). Veröffentlichen Sie einen Annahme- und Offenlegungsweg und legen Sie Patch-SLAs nach Schweregrad fest, sodass die Reaktion ein definierter Prozess ist, keine Improvisation.
6. Halten Sie es als Policy schriftlich fest und sammeln Sie Nachweise. Dokumentieren Sie jede Praktik, das Tool oder Tor, das sie durchsetzt, und wo die Nachweise liegen. Auf dieser Dokumentation ruhen eine Selbstauskunft und ein Audit.

Gehen Sie diese Schritte, und das SSDF hört auf, eine Compliance-Last zu sein, und wird zur Beschreibung, wie Sie ohnehin arbeiten. Der Build-Prozess, an den die Automatisierung andockt, ist in unserem Prozess der individuellen Softwareentwicklung behandelt, und die Engineering-Gewohnheiten, die PW erfüllen, stehen in unserem Leitfaden zu Best Practices der Softwareentwicklung.

SSDF vs. sicherer SDLC und andere Frameworks

Das SSDF ist ein Rahmen von Ergebnissen; ein sicherer SDLC ist Ihr Prozess, und andere Standards dienen benachbarten Zwecken — sie ergänzen also, statt zu konkurrieren. Teams, die neu in diesem Feld sind, fragen oft, ob das SSDF ihren sicheren SDLC, OWASP SAMM oder SOC 2 ersetzt. Das tut es nicht. Sie betreiben tagtäglich einen sicheren SDLC, nutzen das SSDF als gemeinsame Selbstauskunftssprache und greifen zu Reifegradmodellen oder Auditstandards, wenn Sie messen oder zertifizieren müssen. Die Tabelle ordnet jeden ein.

Das saubere mentale Modell ist geschichtet: Ihr sicherer SDLC ist die Praxis, das SSDF ist, wie Sie sie beschreiben und dazu Selbstauskunft geben, und OWASP SAMM oder SOC 2 messen oder zertifizieren sie. Weil das SSDF ausdrücklich auf OWASP und BSIMM zurückgreift, bedeutet seine Übernahme nicht, bereits unter diesen Modellen geleistete Arbeit zu verwerfen — es bedeutet, sie in der Sprache auszudrücken, die föderale und Enterprise-Beschaffung heute erwartet.

SP 800-218A: das SSDF für KI-Systeme

Wenn Sie KI- oder generative KI-Systeme bauen, erweitert NIST SP 800-218A das SSDF, um die Risiken abzudecken, die klassische Software nicht hat, ohne den Kernrahmen zu ersetzen. 2024 als Begleitprofil veröffentlicht, behält SP 800-218A dieselben vier Praktikgruppen und legt Aufgaben speziell für die KI-Modellentwicklung darüber — die Bedrohungen, die entstehen, wenn Ihre Software trainiert statt nur programmiert wird. Sie behalten das SSDF, das Sie bereits umsetzen, und fügen diese Praktiken obenauf hinzu.

In der Praxis gruppieren sich die Ergänzungen um Daten und Modelle. Die Integrität und Herkunft der Trainingsdaten werden Teil von Protect the Software; Modellvergiftung, Datenvergiftung und Modell-Exfiltration werden zu Bedrohungen des Modells in Produce Well-Secured Software; und die Überwachung auf modellspezifischen Missbrauch erweitert Respond to Vulnerabilities bis in die Produktion. Liefern Sie KI-Funktionen aus, kombinieren Sie dies mit unseren Leistungen zur Integration generativer KI für die Engineering-Seite und der Checkliste zur EU-KI-Verordnung für die regulatorische Seite im europäischen Markt.

NIST-SSDF-Compliance-Checkliste

Die meisten SSDF-Programme scheitern am Banalen: eine Praktik ohne Verantwortlichen, eine Policy, die nie in die Pipeline verdrahtet wurde, oder eine Selbstauskunft ohne Nachweise dahinter. Diese Checkliste hält das Wesentliche sichtbar:

• Bilden Sie jede Praktik auf einen Verantwortlichen ab. Jede Praktik der vier Gruppen braucht eine benannte Rolle, sonst wird sie niemands Aufgabe, wenn der Zeitplan enger wird.
• Schützen und signieren Sie Ihren Build (PS). Zugriffskontrollierte Quellen, eine gehärtete Pipeline und signierte Artefakte sind die Lieferkettenkontrollen, die Käufer zuerst prüfen.
• Automatisieren Sie sichere Prüfungen in CI/CD (PW). Statische Analyse, Abhängigkeits-Scanning und SBOM-Erzeugung, die bei jeder Änderung laufen, schlagen jedes vierteljährliche manuelle Review.
• Erzeugen und bewahren Sie eine SBOM je Release. Sie ist das Artefakt, das die Frage „sind wir betroffen?“ in Minuten statt Tagen beantwortet.
• Betreiben Sie eine echte Schwachstellenreaktion (RV). Ein veröffentlichter Annahme- und Offenlegungsweg samt Patch-SLAs nach Schweregrad macht die Reaktion zu einem Prozess, keiner Improvisation.
• Dokumentieren Sie die Policy und bewahren Sie die Nachweise. Eine Selbstauskunft ist nur so gut wie die Policy, das Release, in dem sie lief, und die Abzeichnung hinter jeder Aussage.
• Verfolgen Sie die Framework-Version. Vergewissern Sie sich, dass Sie auf die aktuelle SP-800-218-Revision abbilden, und ergänzen Sie SP 800-218A, wenn Sie KI-Systeme bauen.

FAQ

Was ist das NIST Secure Software Development Framework (SSDF)?

Das NIST Secure Software Development Framework (SSDF) ist eine Sammlung übergeordneter, methodenunabhängiger sicherer Entwicklungspraktiken, die NIST als Special Publication 800-218 veröffentlicht hat. Es gliedert sichere Softwarearbeit in vier Praktikgruppen: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) und Respond to Vulnerabilities (RV). Version 1.1 definiert 19 Praktiken und 42 Aufgaben. Weil es Ergebnisse statt Tools beschreibt, passt es gleichermaßen auf Agile, DevOps und Wasserfall, und es ist zum Referenzrahmen geworden, gegen den US-föderale Software-Lieferanten eine Selbstauskunft abgeben.

Welche vier Praktikgruppen hat das NIST SSDF?

Das NIST SSDF hat vier Praktikgruppen. Prepare the Organization (PO) richtet Menschen, Prozesse und Tools ein, einschließlich Sicherheitsanforderungen und Entwicklerschulung. Protect the Software (PS) schützt Code und Buildsysteme vor Manipulation und verifiziert Integrität und Herkunft der Software. Produce Well-Secured Software (PW) ist die größte Gruppe und umfasst sicheres Design, Bedrohungsmodellierung, sicheres Programmieren, die Prüfung von Dritt- und SBOM-Komponenten sowie Tests vor dem Release. Respond to Vulnerabilities (RV) deckt das Finden, Offenlegen und Beheben von Schwachstellen nach dem Release ab.

Ist die NIST-SSDF-Konformität 2026 verpflichtend?

Das NIST SSDF ist freiwillige Orientierung, doch die Konformität ist faktisch erforderlich, um Software an die US-Bundesregierung zu verkaufen. Nach den OMB-Memoranden M-22-18 und M-23-16 müssen Behörden von den Lieferanten, deren Software sie nutzen, eine Selbstauskunft zur sicheren Softwareentwicklung einholen. Die Executive Order 14306 vom Juni 2025 hob die zentrale Validierung dieser Selbstauskünfte durch CISA auf und strich die zugehörige Änderung der Federal Acquisition Regulation, doch die grundlegende Pflicht, dem SSDF zu folgen und prüfbare Nachweise vorzulegen, bleibt. Enterprise-Käufer verlangen dieselben Nachweise zunehmend auch ohne föderale Vorgabe.

Was ist der Unterschied zwischen dem NIST SSDF und einem sicheren SDLC?

Ein sicherer SDLC ist Ihr eigener Auslieferungsprozess mit in jede Phase eingebauter Sicherheit; das NIST SSDF ist ein Rahmen ergebnisorientierter Praktiken, gegen den Sie diesen Prozess abbilden. Das SSDF schreibt weder Phasen noch Tools oder eine Methode vor — es definiert als Praktiken und Aufgaben, wie gute sichere Entwicklung aussieht, sodass Sie zeigen können, dass Ihr Agile- oder DevOps-SDLC sie bereits erfüllt. In der Praxis betreiben Teams tagtäglich einen sicheren SDLC und nutzen das SSDF als gemeinsame Sprache für Audits, Enterprise-Sicherheitsprüfungen und die föderale Selbstauskunft.

Was ist NIST SP 800-218A?

NIST SP 800-218A ist ein 2024 veröffentlichtes Begleitprofil zum SSDF, das sichere Entwicklungspraktiken und Aufgaben speziell für die Entwicklung von KI- und generativen KI-Modellen ergänzt. Es erweitert dieselben vier Praktikgruppen auf Risiken, die klassische Software nicht kennt, etwa die Integrität der Trainingsdaten, die Modellherkunft sowie Modell- und Datenvergiftung. Teams, die KI-Systeme bauen, behalten das Kern-SSDF und legen SP 800-218A darüber, statt einen separaten Rahmen einzuführen.

Wie hängt SBOM mit dem NIST SSDF zusammen?

Eine Software Bill of Materials (SBOM) ist eines der konkreten Artefakte, die die SSDF-Praktiken Produce Well-Secured Software (PW) und Respond to Vulnerabilities (RV) verlangen. PW erfordert, dass Sie Dritt- und Open-Source-Komponenten beschaffen, verifizieren und nachverfolgen; eine SBOM ist das Inventar, das dies ermöglicht und Sie schnell beantworten lässt, ob eine neu offengelegte Schwachstelle Ihre Software betrifft. Eine SBOM je Release zu erzeugen und aufzubewahren ist inzwischen eine Grunderwartung föderaler und Enterprise-Käufer, die die SSDF-Konformität bewerten.

Zuletzt aktualisiert am 30. Juli 2026. Framework-Referenzen beziehen sich auf NIST SP 800-218 (SSDF v1.1), SP 800-218A für KI, die Arbeit an SP 800-218 Rev. 1, die US Executive Orders 14028 und 14306, OMB M-22-18 und M-23-16 sowie das CISA-Selbstauskunftsformular zur sicheren Softwareentwicklung, zitiert als allgemeine Orientierung. Die Mechanik der Selbstauskunft und die Framework-Versionen ändern sich — prüfen Sie die aktuelle NIST-Veröffentlichung und die Beschaffungsregeln für Ihre Situation und behandeln Sie dies als Ausgangspunkt, nicht als Rechtsberatung.