Drei Jahrzehnte lang spielte die Kryptografie bei der Entwicklung von „ software “ nur eine untergeordnete Rolle. Sie diente dem Schutz des Datenverkehrs und der Signierung gelegentlicher Releases, war jedoch in den Führungsetagen kaum ein Thema.
Das hat sich geändert. Heute unterzeichnet ein Geschäftsführer persönlich ein Dokument, in dem er bestätigt, dass sein Unternehmen sichere Entwicklungspraktiken befolgt, und das SSDF steht im Mittelpunkt dieses Versprechens.
Diese Signatur ist keine reine Formalität. Es handelt sich um eine formelle, rechtlich bedeutsame Erklärung, und die ihr zugrunde liegenden Nachweise müssen stichhaltig sein, falls ein Käufer auf Bundesebene jemals Einsicht darin verlangt. In diesem Leitfaden wird erläutert, was das Rahmenwerk verlangt, warum die Codesignierung und die Schlüsselverwaltung so wichtig sind und wie man stichhaltige Nachweise erstellt.
Was NIST SP 800-218 (SSDF) eigentlich ist
Das „Secure Software Development Framework“ (SSDF) ist die NIST-Sonderveröffentlichung 800-218. Das NIST hat im Februar 2022 die Version 1.1 veröffentlicht.
Anstelle einer verbindlichen Checkliste beschreibt das SSDF Ergebnisse, die eine sichere Entwicklung erzielen sollte. Dadurch können Teams das Rahmenwerk auf jeden beliebigen Entwicklungslebenszyklus anwenden, den sie bereits nutzen. Das Rahmenwerk gliedert diese Ergebnisse in vier Gruppen:
- Bereiten Sie das Unternehmen vor: Stellen Sie sicher, dass Mitarbeiter, Prozesse und Tools bereit sind, um „ software “ sicher zu entwickeln.
- Schützen Sie die „ software “: Schützen Sie alle Arten von Code vor Manipulationen und unbefugtem Zugriff.
- Entwicklung sicherer software: Entwerfen, erstellen und testen Sie software so, dass die Website zum Zeitpunkt der Veröffentlichung möglichst wenige Sicherheitslücken aufweist.
- Auf Sicherheitslücken reagieren: Probleme in veröffentlichten Versionen von „ software “ aufspüren, bewerten und beheben und anschließend deren erneutes Auftreten verhindern.
Warum SSDF zu einer Beschaffungsanforderung wurde
Aufgrund einer Reihe von Maßnahmen auf Bundesebene wurde das Rahmenwerk von „bewährten Praktiken“ zu einer „Beschaffungsvoraussetzung“ umgestaltet. Die Durchführungsverordnung 14028 (12. Mai 2021) wies die Behörden an, die Anforderungen an die Sicherheit der Lieferkette von „ software “ zu verschärfen.
Das OMB-Memorandum M-22-18 (14. September 2022), geändert durch M-23-16 (9. Juni 2023), ging noch einen Schritt weiter. Es machte die bescheinigte SSDF-Konformität zur Voraussetzung für die Nutzung der betroffenen „ software “ durch Bundesbehörden. In der Praxis mussten die Hersteller eine entsprechende Erklärung unterzeichnen, bevor die Behörden weiterhin Einkäufe tätigen konnten. Die Executive Order 14306 (6. Juni 2025) hob daraufhin die Bestimmungen der EO 14144 zu Bescheinigungen und zum Vertragstext gemäß FAR auf und wies das NIST an, das SSDF zu aktualisieren.
Die aktuelle Situation ist differenzierter. Mit dem OMB-Memorandum M-26-05 (23. Januar 2026) wurden die Memoranden M-22-18 und M-23-16 aufgehoben und die behördenweite Vorschrift durch einen behördengeführten, risikobasierten Ansatz ersetzt. Die Verwendung des CISA-Standardformulars ist für die Behörden nun optional und nicht mehr verpflichtend. Die Behörden behalten den Ermessensspielraum, Bescheinigungen und SBOMs anzufordern, und der FAR-Fall 2023-002 bleibt offen.
Wen geht das an (und das betrifft nicht nur Lieferanten des Bundes)?
Drei Gruppen sind davon unmittelbar betroffen. Erstens alle Hersteller von „ software “, die an Bundesbehörden verkaufen. Zweitens der Geschäftsführer oder der bevollmächtigte Vertreter, der den Vertrag tatsächlich unterzeichnet.
Drittens – und in zunehmendem Maße – gewerbliche Käufer. Banken, Einrichtungen des Gesundheitswesens und Großunternehmen beziehen sich mittlerweile in Fragebögen zum Lieferantenrisiko auf das SSDF. Das Rahmenwerk hat sich zu einem gemeinsamen Vokabular für sichere Entwicklung entwickelt und reicht somit weit über Aufträge der Bundesbehörden hinaus.
Die Bestätigung ist eine Unterschrift, kein Kontrollkästchen.
Die Hersteller unterzeichnen das von der CISA bereitgestellte Formular zur Bestätigung der Entwicklung sicherer „ Software “. Der Vorstandsvorsitzende oder ein benannter leitender Angestellter bestätigt nach bestem Wissen und Gewissen, dass die entsprechenden Verfahren umgesetzt sind.
Was die Sache noch komplizierter macht: Es gibt kein Zertifizierungssystem durch Dritte. Kein Prüfer stellt ein Zertifikat aus, das diese Frage endgültig klärt. Die Konformität beruht ausschließlich auf den Nachweisen, die ein Hersteller intern aufbewahrt.
Das Formular weist darauf hin, dass die vorsätzliche Angabe falscher oder irreführender Informationen einen Verstoß gegen 18 U.S.C. § 1001, eine Strafvorschrift, darstellen kann und dass eine falsche Bescheinigung zudem zivilrechtliche Folgen gemäß dem „False Claims Act“ nach sich ziehen kann. Dadurch wird eine Lücke in der Dokumentation zu einem rechtlichen Risiko, weshalb der Nachweis hinter der Unterschrift ebenso wichtig ist wie die Unterschrift selbst.
Die Verfahren, die für SSDF das größte kryptografische Gewicht haben
Mehrere Verfahren hängen unmittelbar von der Codesignierung und der Schlüsselverwaltung ab. Da es sich hierbei um Verfahren handelt, die Prüfer anhand kryptografischer Nachweise verifizieren können, verdienen sie die größte Aufmerksamkeit.
PS.1: Schütze alle Arten von Code vor Manipulationen
PS.1 fordert Produzenten dazu auf, Quell-, Build- und Release-Artefakte vor unbefugten Änderungen zu schützen. Das bedeutet, dass Zugriffskontrollen und Integritätsschutz über die gesamte Pipeline hinweg durchgesetzt werden müssen. Signierte Commits und geschützte Build-Systeme liefern Ihnen Manipulationsnachweise, die Sie später vorlegen können.
PS.2: Den Verbrauchern die Möglichkeit geben, die Integrität der Veröffentlichung zu überprüfen
PS.2 fordert einen Mechanismus, mit dem Verbraucher überprüfen können, ob eine Version mit den Angaben des Herstellers übereinstimmt. In der Praxis signiert man jedes Release-Artefakt kryptografisch und veröffentlicht das Verifizierungsmaterial. Jeder, der die „ software “ herunterlädt, kann dann die Signatur überprüfen, bevor er dem Code vertraut.
PS.2 und PO.5: Schutz der Signaturschlüssel selbst
Eine Signatur ist nur so vertrauenswürdig wie der dahinterstehende Schlüssel. PS.2 fordert eine regelmäßige Überprüfung des Code-Signaturprozesses, einschließlich der Erneuerung, Rotation, Sperrung und des Schutzes von Zertifikaten. PO.5 befasst sich mit den sicheren Umgebungen, in denen die Signatur erfolgt, einschließlich der Build- und Verteilungsumgebungen.
Das bedeutet, private Schlüssel unter hardware zu generieren und zu speichern, die Berechtigung zum Signieren einzuschränken sowie die Erneuerung, Rotation und Sperrung der Schlüssel nach einem festgelegten Zeitplan zu überprüfen. Mit einem gestohlenen Signaturschlüssel kann ein Angreifer Malware signieren, die wie Ihre aussieht; daher schützt diese Kontrollmaßnahme sowohl Sie als auch Ihre Kunden.
PW.6: Kompilierungsabsicherung
PW.6 trägt den Titel „Konfiguration der Kompilierungs-, Interpreter- und Build-Prozesse zur Verbesserung der Sicherheit von ausführbaren Dateien“. Es ergänzt die Signierung von Artefakten, ersetzt sie jedoch nicht.
Das Ziel besteht darin, die Anzahl der Sicherheitslücken und die Kosten für deren Behebung zu reduzieren, indem Fehler bereits vor Beginn der Tests beseitigt werden. Dabei sind zwei Aufgaben zu erfüllen: Erstens sollen Compiler, Interpreter und Build-Tools eingesetzt werden, die Funktionen zur Verbesserung der Sicherheit bieten. Zweitens muss entschieden werden, welche Funktionen verwendet werden sollen, diese müssen konfiguriert und die genehmigten Konfigurationen konsequent angewendet werden.
RV.2: Signierte SBOMs und Herkunftsnachweise für eine schnelle Reaktion
Wenn eine Sicherheitslücke bekannt wird, hängt die Reaktionsgeschwindigkeit davon ab, genau zu wissen, was ausgeliefert wurde. RV.2 bevorzugt signierte „ Software “-Stücklisten (SBOMs) und Herkunftsnachweise. Mit signierten SBOMs lassen sich betroffene Komponenten schnell identifizieren und die Echtheit des Bestands nachweisen, wodurch sich der Zeitraum zwischen Bekanntwerden der Sicherheitslücke und deren Behebung verkürzt.
Zusammenstellung der Nachweise zur Untermauerung der Bescheinigung
Das unterzeichnete Formular ist nur der kleinste Teil der Konformitätsprüfung. Ausschlaggebend ist ein Nachweispaket, das belegt, dass die Verfahren tatsächlich umgesetzt werden. Stellen Sie diese sechs Unterlagen zusammen und legen Sie für jede davon im Vorfeld die entsprechenden Nachweise vor:
- Nachweisunterlagen: Bewahren Sie das unterzeichnete Formular sowie die Belege auf, die jede darin enthaltene Angabe untermauern.
- Schutz von Codesignaturschlüsseln: Zeigen Sie, dass sich private Schlüssel in „ hardware “ befinden und dass der Zugriff auf die Signaturfunktion kontrolliert wird.
- Überprüfung der Release-Integrität: Zeigen Sie einen funktionierenden Mechanismus auf, mit dem Verbraucher ein Release überprüfen können.
- Zugriffskontrolle für die Build-Pipeline: Führen Sie Protokolle, aus denen hervorgeht, wer wann auf die Build- und Release-Infrastruktur zugreifen konnte.
- Signierte SBOM und Herkunftsdaten: Erstellen Sie signierte Komponentenverzeichnisse und Herkunftsdaten für veröffentlichte software.
- Ehrliche Selbsteinschätzung: Fragen Sie sich, ob diese Belege einer Überprüfung standhalten würden, und schließen Sie anschließend alle Lücken, die Sie feststellen.
Wie Keyfactor helfen Keyfactor
Keyfactor bietet den Produzenten von „ software “ die Möglichkeit, diese Vorgehensweisen in Belege umzuwandeln, die aus einem einzigen System stammen und nicht aus einem Dutzend voneinander getrennter Tools.
Keyfactor AgileSec ist der grundlegende erste Schritt. Es ermittelt und inventarisiert kryptografische Ressourcen in Code, Build-Pipelines und der Cloud-Infrastruktur, sodass Sie sehen können, wo sich Signaturschlüssel und Zertifikate tatsächlich befinden. AgileSec erstellt außerdem signierte SBOM- und Herkunftsdaten, die RV.2 unterstützen, sowie zentralisierte Berichte für das Nachweispaket zur Zertifizierung.
EJBCA stellt die Zertifikate für die vertrauenswürdige Signierung aus und verwaltet diese. Es stellt die Zertifizierungsstelle sowie die Code-Signatur-Zertifikate bereit, die die Signaturidentitäten entlang Ihrer gesamten Build- und Release-Kette verankern.
Keyfactor SignServer zentralisiert den Signaturvorgang. Es signiert Commits, Releases, Build-Ergebnisse und Container-Images von einem einzigen System aus, das direkt mit PS.1, PS.2, PS.3 und den gehärteten Builds hinter PW.6 verknüpft ist. Für verteilte CI/CD-Teams integriert Keyfactor Signum die Codesignatur in bestehende Entwickler-Workflows.
Keyfactor Command automatisiert den von PO.3 und PS.2 geforderten Lebenszyklus von Zertifikaten und Schlüsseln. Es verwaltet den Lebenszyklus von Codesignaturschlüsseln und Zertifikaten und erstellt die zentralisierten Berichte, die in Ihr Nachweispaket einfließen.
Verbinden Sie all dies mit der „ Keyfactor Trust Control Plane“ – einem zentralen System, das Signaturschlüssel und Nachweise überwacht, bereitstellt, koordiniert und verwaltet. Wenn die Nachweise für Ihre Bescheinigung aus einer Hand stammen, wird deren Schutz zur Routine und ist kein hektisches Unterfangen mehr.
SSDF zu einer signierten, nachweisbaren Funktion machen
Die SSDF-Konformität ist eine Betriebsfähigkeit und kein einmaliges Projekt. Schlüssel werden gewechselt, Pipelines ändern sich und Schwachstellen treten zutage, daher müssen die Nachweise stets auf dem neuesten Stand sein.
Der Vorteil liegt in der Synergie. Dieselbe Infrastruktur für Signaturen und Nachweise, die einer Bundesbescheinigung zugrunde liegt, erfüllt auch die Anforderungen an kommerzielle Sicherheitsfragebögen von Banken, dem Gesundheitswesen und Unternehmenskunden. Einmal eingerichtet, sind beide Anforderungen erfüllt.
Fangen Sie gleich an: Erstellen Sie eine Bestandsaufnahme darüber, wie Ihr Code und Ihre Releases signiert werden, überprüfen Sie, wie die Signaturschlüssel geschützt sind, und legen Sie Nachweise vor, die Sie auch bei einer genauen Prüfung verteidigen können. Fordern Sie eine Demo an, um zu sehen, wie „ Keyfactor “ sichere Entwicklung zu einer signierten, nachweisbaren Fähigkeit macht.
Haben Sie Fragen zu SSDF? Wir haben die Antworten.
Was ist NIST SP 800-218 (SSDF)?
NIST SP 800-218 ist das „Secure Software Development Framework“ (Rahmenwerk für die sichere Entwicklung von Software), eine Sammlung ergebnisorientierter Vorgehensweisen, die in vier Gruppen unterteilt sind: Vorbereitung der Organisation, Schutz der software, Erstellung gut gesicherter software und Reaktion auf Schwachstellen. Es beschreibt, was eine sichere Entwicklung erreichen soll, anstatt eine feste Checkliste vorzuschreiben.
Wer muss die SSDF-Vorgaben einhalten?
Jeder „ software “-Anbieter, der an die US-Bundesregierung verkauft, muss möglicherweise selbst bestätigen, dasser dieSSDF-Vorgaben einhält. Kommerzielle Abnehmer wie Banken, Organisationen im Gesundheitswesen und große Unternehmen beziehen sich in ihren Fragebögen zum Lieferantenrisiko zunehmend auf die SSDF, sodass deren Geltungsbereich weit über Geschäfte mit der Bundesregierung hinausreicht.
Was ist das CISA-Formular zur Bestätigung der Entwicklung sicherer Software ( Software , SSDF)?
Es handelt sich um das Formular, das Hersteller von „ software “ unterzeichnen, um zu erklären, dass sie die SSDF-Vorgaben befolgen. Die Richtlinien M-22-18 und M-23-16 verpflichteten die Behörden, dieses Formular einzuholen. Das OMB hat beide Richtlinien im Januar 2026 aufgehoben, sodass die Verwendung des Formulars nun im Ermessen der jeweiligen Behörde liegt. Wenn eine Behörde das Formular anfordert, unterzeichnet der Geschäftsführer oder ein Beauftragter, der als Mitarbeiter befugt ist, das Unternehmen rechtsverbindlich zu vertreten, und bestätigt nach bestem Wissen und Gewissen, dass die entsprechenden Praktiken umgesetzt werden.
Ist die SSDF-Bescheinigung rechtsverbindlich?
Ja. Es handelt sich um eine formelle, rechtlich bedeutsame Erklärung, und vom Unterzeichner wird erwartet, dass er ausreichende Nachweise aufbewahrt, um diese im Falle einer Anfechtung verteidigen zu können. Eine falsche Bescheinigung kann zu einem Risiko im Sinne des „False Claims Act“ führen, wodurch die Folgen über die eines typischen Compliance-Verstoßes hinausgehen.
Inwiefern hängt die Codesignierung mit dem SSDF zusammen?
PS.1 schützt alle Arten von Code vor Manipulationen durch Commit-Signierung, Codesignierung und Hashes. PS.2 verlangt einen Mechanismus zur Überprüfung der Release-Integrität unter Verwendung von Codesignierung, veröffentlichten Hashes und einer regelmäßigen Überprüfung der Zertifikatserneuerung, -rotation, -sperrung sowie des Schlüsselschutzes. PS.3 befasst sich mit der Archivierung von Releases einschließlich ihrer Integritäts- und Herkunftsdaten.
Nach welchen Nachweisen suchen die Prüfer?
Sie suchen nachden Belegen, die der Bescheinigung zugrunde liegen, und nicht nur nachdem unterschriebenen Formular: geschützte Code-Signaturschlüssel, ein funktionierender Mechanismus zur Überprüfung der Integrität der Veröffentlichung, protokollierte Zugriffskontrolle über die Build-Infrastruktur sowie signierte SBOMs und Herkunftsnachweise. Die zentrale Frage ist, ob diese Nachweise Bestand hätten, falls die Bescheinigung angefochten würde.
Ist für das SSDF eine Zertifizierung durch eine unabhängige Stelle erforderlich?
Nein. Das Rahmenwerk sieht kein formelles Zertifizierungsverfahren durch eine unabhängige Stelle vor, sodass der Nachweis der Konformität auf internen Belegen und Bescheinigungen beruht und nicht auf einem Audit-Zertifikat. Damit liegt es in der Verantwortung der Organisation, stichhaltige Nachweise aufzubewahren.
Was ist der erste praktische Schritt zur Einhaltung der SSDF-Vorgaben?
Verschaffen Sie sich zunächst einen Überblick darüber, wie Code und Releases signiert werden und wie die Signaturschlüssel geschützt sind. Legen Sie anschließend eine signierte Build-Pipeline fest und zentralisieren Sie die Nachweise. Wenn Sie diese Funktion einmal eingerichtet haben, können Sie sowohl behördliche Bescheinigungen als auch kommerzielle Sicherheitsfragebögen aus demselben System heraus beantworten.
