Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Wichtigste Erkenntnisse
- Das „Secure Software Development Framework“ (SSDF) des NIST (National Institute of Standards and Technology) fordert Sie dazu auf, Komponenten von Drittanbietern, einschließlich Open-Source-Komponenten, kontinuierlich anhand Ihrer eigenen Anforderungen zu überprüfen.
- Ein Schwachstellenscan ist nur ein Teil der Überprüfung, und die Beispiele des SSDF beziehen sich auch auf den Wartungsstatus und die Integrität.
- Bei Open-Source-Software gibt es in der Regel keinen Anbieter, der nachweisen muss, dass eine Komponente Ihren Anforderungen entspricht; daher muss Ihr Team diese Nachweise selbst erbringen.
- Zu diesen Nachweisen gehört auch die Provenienz, also eine Aufzeichnung über die Herkunft und die Änderungen jeder Komponente. Eine Komponentenliste allein reicht dafür nicht aus.
- Bei der Verifizierung geht es im Wesentlichen um vier Entscheidungen: Anforderungen, Nachweise, Sicherheitsmaßnahmen vor der Erstellung und einen Plan für nicht gewartete Komponenten. Beginnen Sie mit den Anforderungen.
Wenn ein Kunde fragt, wie Sie die Open-Source-Bibliotheken in Ihrem Produkt überprüfen, ist diese Frage wahrscheinlich durch das „Secure Software Development Framework“ (SSDF) des NIST geprägt. Eine der darin festgelegten Aufgaben – PW.4.4 in der Gruppe „Produce Well-Secured Software“ – fordert Hersteller dazu auf, Komponenten von Drittanbietern, einschließlich Open-Source-Komponenten, anhand selbst definierter Anforderungen zu überprüfen.
Ein aussagekräftiger Scan-Bericht umfasst bekannte Schwachstellen, doch die Beispiele in PW.4.4 geben zudem Aufschluss darüber, ob eine Komponente weiterhin gepflegt wird und ob ihre Integrität bestätigt werden kann. Die Aufgabe selbst definiert weder den Begriff „überprüfen“, noch nennt sie ein bestimmtes Tool oder gibt vor, welche Nachweise aufzubewahren sind.
Damit bleibt es an Ihnen, die Anforderungen zu formulieren und den Nachweis zu erbringen. Und bei Open-Source-Komponenten steht in der Regel kein Vertrag hinter der Bibliothek, sodass kein Anbieter verpflichtet ist, Ihnen diesen Nachweis zu erbringen.
Der Stand des NIST SSDF im Jahr 2026
Das NIST veröffentlicht das SSDF als Sonderveröffentlichung (SP) 800-218. Die aktuelle endgültige Fassung ist das „Secure Software Development Framework (SSDF) Version 1.1: Empfehlungen zur Minderung des Risikos von Software-Schwachstellen“ vom Februar 2022. Die darin enthaltenen Vorgehensweisen sind in vier Gruppen unterteilt, die jeweils mit einem zweistelligen Code gekennzeichnet sind: „Prepare the Organization“ (PO), „Protect the Software“ (PS), „Produce Well-Secured Software“ (PW) und „Respond to Vulnerabilities“ (RV). Jede Vorgehensweise hat eine Kennung, beispielsweise PW.4, und ihre Aufgaben sind mit einer zusätzlichen Nummer versehen, beispielsweise PW.4.4.
Die Version 1.1 richtet sich an Softwarehersteller und Software-Abnehmer und besagt, dass Nichtregierungsorganisationen sie freiwillig nutzen können. Sie beschreibt die darin enthaltenen Vorgehensweisen als Grundlage für eine risikobasierte Planung und weist darauf hin, dass sie nicht als Checkliste gedacht sind. Das NIST stellt den SSDF als gemeinsames Vokabular dar, das Abnehmer gegenüber ihren Lieferanten verwenden können; daher wird eine Anforderung in der Regel über die Richtlinien eines Einkäufers oder einen Vertrag an Sie weitergegeben, in dem darauf verwiesen wird.
Anmerkung: Das NIST hat am 17. Dezember 2025 als Reaktion auf die Executive Order 14306 einen ersten öffentlichen Entwurf von SP 800-218, Revision 1, „Secure Software Development Framework“ (SSDF), Version 1.2, veröffentlicht. Stand Oktober 2026 ist Version 1.1 weiterhin die endgültige Fassung. Der Entwurf behält PW.4.4 und die Provenienz-Aufgabe PS.3.2 mit derselben Nummerierung und demselben Wortlaut bei und fügt unter PW.4.4 zwei neue Vorgehensweisen sowie Beispieltexte hinzu. Dieser Artikel orientiert sich an Version 1.1.
Was PW.4.4 aussagt und was es offen lässt
PW.4.4 fordert Hersteller dazu auf, sicherzustellen, dass erworbene kommerzielle, Open-Source- und sonstige Softwarekomponenten von Drittanbietern während ihres gesamten Lebenszyklus den von der Organisation festgelegten Anforderungen entsprechen. Diese Formulierung überlässt die Festlegung der Anforderungen Ihnen und nennt Open-Source-Komponenten ausdrücklich. Außerdem sorgt sie dafür, dass die Überprüfung so lange fortgesetzt wird, wie Sie die Komponente nutzen – also weit über eine einmalige Überprüfung bei der Einführung hinaus.
Darüber hinaus stellt das NIST sieben fiktive Anwendungsbeispiele zur Verfügung.
| PW.4.4 Beispiel | Was ist abgedeckt? | Grundlage |
|---|---|---|
| Beispiele 1 und 2: Überprüfung auf öffentlich bekannte Sicherheitslücken, die von den Anbietern noch nicht behoben wurden, einschließlich automatischer Erkennung in der Toolchain | Bekannte Mängel der Komponente | SP 800-218 Version 1.1, fiktiv |
| Beispiel 3: Nutzung vorhandener Ergebnisse kommerzieller Überprüfungsdienste | Ergebnisse der externen Überprüfung | SP 800-218 Version 1.1, fiktiv |
| Beispiel 4: Vergewissern Sie sich, dass die Komponente weiterhin aktiv gewartet wird und das Ende der Lebensdauer (EOL) noch nicht erreicht hat, einschließlich der Behebung neu entdeckter Sicherheitslücken | Supportstatus und Behebung neuer Fehler | SP 800-218 Version 1.1, fiktiv |
| Beispiel 5: Erstellen Sie einen Aktionsplan für Komponenten, die nicht mehr gewartet werden oder bald nicht mehr verfügbar sein werden | Ihre Reaktion nach Ablauf des Supports | SP 800-218 Version 1.1, fiktiv |
| Beispiel 6: Überprüfung der Integrität durch digitale Signaturen oder andere Mechanismen | Unversehrtheit des Artefakts | SP 800-218 Version 1.1, fiktiv |
| Beispiel 7: den Code überprüfen, analysieren oder testen | Der Code selbst | SP 800-218 Version 1.1, fiktiv |
Die Überprüfung auf bekannte Schwachstellen deckt zwei dieser sieben Beispiele ab, sodass ein Scan-Bericht allein bereits einen Teil der Aufgabe erfüllt. Ein Scan auf bekannte Schwachstellen gibt in der Regel keinen Aufschluss darüber, ob ein Artefakt intakt ist oder ob die Komponente noch gepflegt wird – diese Fragen werden in den Beispielen 4 und 6 behandelt.
Der Entwurf des SSDF 1.2 enthält ein achtes Beispiel unter PW.4.4: Überprüfen Sie regelmäßig Bibliotheken von Drittanbietern auf Änderungen der Eigentumsverhältnisse und bewerten Sie die Auswirkungen jeder einzelnen Änderung. Bei einem Scan auf bekannte Schwachstellen wird eine Änderung der Eigentumsverhältnisse in der Regel nicht erkannt, daher wäre für dieses Beispiel eine eigene Überprüfung erforderlich.
Bei einer nicht mehr gepflegten Komponente sieht der Aktionsplan aus Beispiel 5 in der Regel eine der folgenden drei Möglichkeiten vor: Austausch der Komponente, Patchen der von Ihnen verwendeten Version oder schriftliche Akzeptanz des Risikos. Die mittlere Option bedeutet, dass jemand den Fix schreiben und testen muss – und dieser Jemand sind Sie, es sei denn, Sie haben dies bereits an jemand anderen delegiert.
Bei Open Source gibt es oft keinen Anbieter, der Ihnen Belege vorlegen kann
PO.1.3, die Aufgabe des SSDF im Umgang mit Lieferanten, umfasst die Übermittlung von Anforderungen an Dritte, die kommerzielle Komponenten bereitstellen. Zu den Beispielen gehören die Aufnahme von Anforderungen in Verträge, die Verpflichtung der Lieferanten, zu bestätigen, dass ihre Software diese Anforderungen erfüllt, sowie die Forderung nach Herkunftsdaten und Mechanismen zur Integritätsprüfung für alle Komponenten ihrer Software.
Der von Ihnen ausgelieferte Open-Source-Code fällt unter PW.4.4, jedoch nicht unter PO.1.3. Daher fordert das SSDF Sie auf, ihn zu überprüfen, ohne dass eine Aufgabe zur Festlegung von Bedingungen mit den Autoren vorgesehen ist. In der Praxis wird eine Bibliothek in der Regel ohne Vertrag bereitgestellt, sodass es in der Regel keinen Vertragspartner gibt, der verpflichtet ist, Ihnen Nachweise zur Herkunft oder Integrität zu übermitteln. Jemand auf Ihrer Seite muss diese Nachweise erstellen oder sammeln.
Ihre Anforderungen stehen an erster Stelle, und PO.1.1 ist der Ausgangspunkt des SSDF für deren Formulierung. Das zweite Beispiel befasst sich mit der Festlegung von Richtlinien zur Absicherung Ihrer Entwicklungsprozesse, einschließlich solcher für Open-Source- und andere Komponenten von Drittanbietern. Formulieren Sie diese, bevor Sie irgendwelche Tools evaluieren. PW.4.4 misst Komponenten anhand Ihrer Anforderungen, und die Standardprüfungen eines Tools treten häufig an deren Stelle, wenn Sie diesen Schritt überspringen.
Ein kurzes Anforderungsdokument kann regeln, welche Wartungsmaßnahmen zulässig sind, was geschieht, wenn eine Komponente nicht mehr vom Hersteller unterstützt wird, wer eine Ausnahme genehmigt und wie die Integrität überprüft wird. Das fünfte Beispiel in PO.1.3 beschreibt einen Prozess für den Umgang mit Anforderungen, die eine Komponente nicht erfüllt, einschließlich der regelmäßigen Überprüfung genehmigter Ausnahmen. Sie können denselben Prozess auch für Open-Source-Komponenten anwenden.
Aus dem SSDF: PW.4.1 – Die Aufgabe des SSDF im Zusammenhang mit der Beschaffung von Komponenten umfasst zwei Beispiele, die Schritte beschreiben, die Ihr Team ohne einen Lieferanten unternehmen kann. Zum einen geht es darum, für jede Komponente Herkunftsinformationen wie eine Software-Stückliste (SBOM) oder eine Zusammensetzungsanalyse zu beschaffen. Zum anderen geht es darum, genehmigte und geprüfte Open-Source-Komponenten in einem oder mehreren Repositorien zu hosten.
Ohne einen Zwischenhändler gibt es in der Regel nichts zwischen der Veröffentlichung eines Betreuers und Ihrem Build, es sei denn, Sie richten eine Sicherheitsmaßnahme ein. Zu den Möglichkeiten gehören die Überprüfung von Signaturen, sofern diese von den Herausgebern bereitgestellt werden, das Neukompilieren aus dem Quellcode oder die Überprüfung der eingehenden Daten, bevor diese Ihre Build-Umgebung erreichen. In den fiktiven Beispielen des SSDF werden einige davon erwähnt, darunter Signaturen in PW.4.4 und das Kompilieren aus dem Quellcode in PW.4.1.
Die Herkunft gemäß PS.3.2 ist mehr als nur eine Komponentenliste
PS.3.2 gehört zur „Protect the Software“-Gruppe der SSDF. Darin werden Hersteller aufgefordert, Herkunftsdaten für alle Komponenten jeder Version zu erfassen, zu sichern, zu pflegen und weiterzugeben, wobei eine SBOM als Beispiel für einen Speicherort dieser Daten genannt wird. Bei Open-Source-Komponenten gibt es in der Regel keinen Anbieter, der verpflichtet ist, Ihnen diese Daten zur Verfügung zu stellen.
Das NIST definiert „Provenienz“ in Anlehnung an die Special Publication 800-53 als die Chronologie der Herkunft, Entwicklung, Eigentumsverhältnisse, des Standorts und der Änderungen einer Komponente. Nach dieser Definition gibt eine Liste mit Namen und Versionen Auskunft darüber, was in einer Version enthalten ist, während die Chronologie Aufschluss darüber gibt, woher die einzelnen Teile stammen und was mit ihnen geschehen ist. Eine Komponentenliste enthält nicht automatisch diese zweiten Informationen. Prüfen Sie daher, ob Ihre SBOM diese Historie erfasst oder lediglich die Liste enthält.
Die Beispiele unter PS.3.2 umfassen die Weitergabe der Daten an Acquirer und Ihre eigenen Reaktionsteams, den Schutz ihrer Integrität, damit Empfänger sie überprüfen können, sowie ihre Aktualisierung, sobald eine Komponente aktualisiert wird. PS.3.2 spricht von „allen Komponenten“ und verwendet den Begriff „transitiv“ nicht. Die Anwendung auf Abhängigkeiten, die Sie nie direkt ausgewählt haben, ist eine Schlussfolgerung, die sich jedoch aus dem Wort „alle“ ergibt. Entscheiden Sie anhand Ihrer Anforderungen, ob transitive Abhängigkeiten in den Geltungsbereich fallen, und halten Sie diese Entscheidung fest.
Neben SBOMs tauchen zwei weitere Begriffe auf. SLSA (Supply-chain Levels for Software Artifacts) ist eine eigenständige Spezifikation zur Lieferkettensicherheit, deren „Build Level 3“ eine gehärtete Build-Plattform beschreibt, die vor Manipulationen während des Build-Vorgangs schützt. VEX-Dokumente (Vulnerability Exploitability eXchange), wie sie von der Cybersecurity and Infrastructure Security Agency (CISA) beschrieben werden, geben den Status eines Produkts in Bezug auf eine bestimmte Schwachstelle an, z. B. „betroffen“, „nicht betroffen“ oder „behoben“. Beide liefern Ihnen Nachweise für SSDF-Aufgaben. SLSA-Provenienzdaten erfassen, wer ein Paket mit welchem Prozess und aus welchen Eingaben erstellt hat, was Teil der Historie ist, die Sie gemäß PS.3.2 aufbewahren müssen. Ein VEX-Eintrag zeigt an, ob eine bekannte Sicherheitslücke eine Komponente betrifft – genau das wird im ersten Beispiel von PW.4.4 abgefragt.
Welche Angaben zu den Komponenten im Bundesbescheinigungsformular abgefragt wurden
Früher erkundigten sich die Beschaffer der Bundesbehörden direkt nach Komponenten von Drittanbietern. Gemäß den Rundschreiben M-22-18 und M-23-16 des Office of Management and Budget (OMB) mussten die Behörden Bescheinigungen von Softwareherstellern einholen, und die CISA sowie das OMB veröffentlichten zu diesem Zweck am 11. März 2024 das „Secure Software Development Attestation Form“ (Formular zur Bescheinigung der sicheren Softwareentwicklung).
In Abschnitt III des Formulars müssen Hersteller bestätigen, dass sie sich nach bestem Wissen und Gewissen bemühen, vertrauenswürdige Quellcode-Lieferketten aufrechtzuerhalten, indem sie automatisierte Tools oder vergleichbare Prozesse einsetzen, die die Sicherheit von Komponenten von Drittanbietern gewährleisten und damit verbundene Schwachstellen verwalten. Außerdem müssen sie bestätigen, dass sie die Herkunft von Komponenten von Drittanbietern „soweit wie möglich“ nachweisen können. Im Anhang des Formulars werden diese Punkte den SSDF-Aufgaben zugeordnet, darunter PW.4.4 und PS.3.2.
Das Formular erfasst nicht die Open-Source- und proprietären Komponenten von Drittanbietern, die in das von einer Behörde verwendete Produkt integriert sind. Hersteller, die diese Komponenten verwenden, bestätigen jedoch dennoch, dass sie die in Abschnitt III genannten Maßnahmen ergriffen haben, um das Risiko einer Abhängigkeit von diesen Komponenten zu verringern.
Am 23. Januar 2026 wurden durch das OMB-Memo M-26-05 die Memos M-22-18 und M-23-16 aufgehoben. Behörden können das Formular weiterhin verwenden und SBOMs vertraglich vorschreiben; das Memo nennt SP 800-218 als Referenz, auf die sie zurückgreifen können. Darin heißt es, es gebe „keine universelle Einheitsmethode“ zur Sicherung der von den Behörden betriebenen Software und Hardware, sodass es jeder Behörde selbst überlassen bleibt, Sicherheitsrichtlinien festzulegen, die ihrem Risikoprofil entsprechen.
| Dokument | Was dort steht | Aktueller Stand | Grundlage |
|---|---|---|---|
| SP 800-218, Version 1.1 | Definiert PW.4.4 und PS.3.2 | Abschluss, Februar 2022 | NIST-Leitfaden |
| SP 800-218, Revision 1, Entwurf (SSDF 1.2) | Behält beide Aufgaben bei und fügt neues Material hinzu | Erster öffentlicher Entwurf | NIST-Leitlinienentwurf |
| OMB M-22-18 und M-23-16 | Verpflichtete Behörden zur Einholung von Bescheinigungen | Aufgehoben am 23. Januar 2026 | OMB-Richtlinie |
| Bescheinigungsformular | Die Produzenten bestätigen die Anwendung von Verfahren, die aus dem SSDF stammen | Optional für Agenturen | Behördenformular (CISA und OMB) |
| OMB M-26-05 | Die Behörden legen ihre eigenen Richtlinien zur Qualitätssicherung fest | Aktuell | OMB-Richtlinie |
Da die Vorschriften M-22-18 und M-23-16 aufgehoben wurden, hängt es von den Richtlinien und dem Vertrag des jeweiligen Käufers ab, ob dieser fragt, wie Sie die Komponenten überprüfen oder deren Herkunft nachverfolgen.
Entscheiden, was Verifizierung für Ihre Abhängigkeiten bedeutet
In der Praxis läuft die Verifizierung auf vier Entscheidungen hinaus: Welche Anforderungen muss eine Komponente erfüllen, welche Nachweise bewahren Sie auf, was steht zwischen einer Upstream-Veröffentlichung und Ihrem Build, und was tun Sie, wenn ein Upstream-Betreuer die Unterstützung für diese Komponente einstellt? Die ersten beiden Punkte sind richtlinienbezogene Aufgaben, die nur Ihr Team erledigen kann. Bei den letzten beiden Punkten können Tools die sich wiederholenden Arbeiten übernehmen.
SecureChain von TuxCare fungiert als Zwischenstufe zwischen den Upstream-Releases und Ihrem Build. Es überprüft den Quellcode von Open-Source-Paketen auf Malware und verdächtige Muster, erstellt die Pakete aus diesem Quellcode in gehärteten, isolierten Umgebungen neu und versorgt sie im Rahmen einer Service-Level-Vereinbarung weiterhin mit Patches, solange der Upstream aktiv ist. Der „Endless Lifecycle Support“ (ELS) stellt auch nach Beendigung der Upstream-Wartung weiterhin Korrekturen bereit und deckt damit die zuvor beschriebene Option „Patch für die von Ihnen verwendete Version“ ab. Die Abdeckung umfasst JavaScript, Python, Java, Go, Rust und PHP. TuxCare stellt außerdem für jedes Paket SBOMs, VEX-Datensätze und eine Herkunftsnachweis nach SLSA Level 3 bereit.
Wenn Sie überlegen, wie Sie mit Open-Source-Paketen umgehen sollen, die nicht geprüft oder nicht gepflegt werden, fragen Sie uns, was SecureChain abdeckt.
FAQ
Was ist das NIST SSDF?
Das NIST SSDF ist das „Secure Software Development Framework“ (Rahmenwerk für sichere Softwareentwicklung), das das NIST, die US-amerikanische Normungsbehörde, als „Special Publication“ (SP) 800-218 veröffentlicht. Es unterteilt sichere Entwicklungspraktiken in die Bereiche „Vorbereitung der Organisation“, „Schutz der Software“, „Erstellung sicherer Software“ und „Reaktion auf Schwachstellen“. Die aktuelle endgültige Version ist 1.1 vom Februar 2022.
Für wen ist das NIST-SSDF gedacht?
Softwarehersteller, wie beispielsweise kommerzielle Anbieter und interne Entwicklungsteams, sowie Software-Abnehmer, darunter Bundesbehörden und andere Organisationen, bilden die beiden Hauptzielgruppen. Laut NIST, der US-amerikanischen Normungsbehörde, können auch nichtstaatliche Organisationen das „Secure Software Development Framework“ (SSDF) freiwillig nutzen. Ein Unternehmen, das auf Open-Source-Komponenten aufbaut, gilt als Hersteller.
Gilt der SSDF auch für Open-Source-Software?
Teilweise. Im „Secure Software Development Framework“ (SSDF) werden sowohl bei der Aufgabe zur Verifizierung von Komponenten von Drittanbietern (PW.4.4) als auch bei der Aufgabe zu deren Beschaffung (PW.4.1) Open-Source-Komponenten genannt. Die Aufgabe zur Übermittlung von Anforderungen an Lieferanten (PO.1.3) nennt ausschließlich kommerzielle Komponenten. Das NIST (die US-amerikanische Normungsbehörde) führt eine SSDF-Baseline für Open-Source-Software unter den von ihr in Betracht gezogenen Maßnahmen auf, hat jedoch bis Oktober 2026 noch keine veröffentlicht.
Was sind fiktive Anwendungsbeispiele im SSDF?
Im „Secure Software Development Framework“ (SSDF) sind fiktive Implementierungsbeispiele Mustertools, -prozesse oder -methoden, die bei der Durchführung einer Aufgabe hilfreich sein könnten. Die US-amerikanische Normungsbehörde NIST weist darauf hin, dass weder ein Beispiel noch eine Kombination davon vorgeschrieben ist und dass es sich dabei nicht um die einzigen Optionen handelt.
Zertifiziert das NIST irgendetwas im Rahmen des SSDF?
Das NIST, die US-amerikanische Normungsbehörde, veröffentlicht das „Secure Software Development Framework“ (SSDF) als Leitfaden; in den SSDF-Unterlagen wird kein Zertifizierungsprogramm beschrieben. Das Bescheinigungsformular der Bundesregierung akzeptiert sowohl eine Selbstbescheinigung des Herstellers als auch eine Bewertung durch Dritte, und das Office of Management and Budget (OMB) schreibt das Formular nicht mehr behördenübergreifend vor.
