Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Wichtigste Erkenntnisse
- Ohne eine Begutachtung durch einen Dritten unterzeichnet der Vorstandsvorsitzende oder ein vom Unternehmen bevollmächtigter Mitarbeiter das Formular.
- Der Unterzeichner versichert nach bestem Wissen und Gewissen, dass der Hersteller die in diesem Formular beschriebenen Verfahren derzeit konsequent anwendet.
- Gemäß dem OMB-Memo M-26-05 entscheidet nun jede Bundesbehörde selbst, ob sie das Formular anfordert; daher kann eine Behörde, an die Sie verkaufen, es weiterhin verlangen.
- Open-Source-Software von Drittanbietern fällt nicht direkt in den Geltungsbereich des Formulars, dennoch bestätigen die Hersteller, dass sie die damit verbundenen Risiken bewältigen.
Wenn eine Bundesbehörde das Formular zur Bescheinigung der sicheren Softwareentwicklung anfordert und Ihr Unternehmen eine Selbstbescheinigung abgibt, anstatt eine Bewertung durch einen Dritten beizufügen, muss der Unterzeichner Ihr Vorstandsvorsitzender (CEO) oder eine von ihm benannte Person sein, die Mitarbeiter des Unternehmens ist und befugt ist, das Unternehmen rechtlich zu vertreten. Ob eine Behörde dies überhaupt anfordert, liegt nun gemäß dem Memo M-26-05 des Office of Management and Budget (OMB) vom 23. Januar 2026 in ihrem eigenen Ermessen.
Dieser Unterzeichner hat sich vielleicht noch nie damit befasst, wie Open-Source-Abhängigkeiten in Ihre Builds gelangen, doch sein Name steht am Ende unter einer Erklärung darüber, wie Ihr Unternehmen das Risiko von Code handhabt, den Ihr Team nicht selbst geschrieben hat.
In dem Formular wird eine Person gebeten, Praktiken zu bestätigen, die von mehreren Teams durchgeführt werden. Diese Bestätigung ist mit Einschränkungen verbunden, und bei einigen der darin enthaltenen Begriffe bleibt es dem Verfasser überlassen, zu entscheiden, was diese erfüllt. Ein Unterzeichner, der sowohl die Einschränkungen als auch die offen formulierten Begriffe versteht, ist wesentlich besser in der Lage, eine korrekte Erklärung zu unterzeichnen.
Wie das Formular zur Bescheinigung der sicheren Softwareentwicklung zur Option wurde
Die Cybersecurity and Infrastructure Security Agency (CISA) hat das Formular am 11. März 2024 veröffentlicht. Softwarehersteller, d. h. die Unternehmen, die Software entwickeln oder kompilieren, verwenden es, um zu bestätigen, dass die von ihnen ausgelieferte Software in Übereinstimmung mit festgelegten Sicherheitsstandards entwickelt wurde.
Einige Jahre lang hatte das OMB diese Bescheinigung vorgeschrieben. Das am 14. September 2022 veröffentlichte und am 9. Juni 2023 durch das Memo M-23-16 aktualisierte Memo M-22-18 erlaubt es einer Behörde, betroffene Software erst dann zu nutzen, wenn deren Hersteller bescheinigt, dass die Entwicklungsverfahren im Einklang mit dem „Secure Software Development Framework“ (SSDF) stehen.
Am 23. Januar 2026 wurden dann durch M-26-05 beide Vermerke aufgehoben. Die Behörden können nun selbst entscheiden, ob sie das CISA-Formular verwenden möchten. Sie können auch Vertragsbedingungen aufnehmen, die einen Hersteller verpflichten, auf Anfrage eine aktuelle Software-Stückliste (SBOM) vorzulegen. Das Formular selbst wurde nicht überarbeitet und verweist weiterhin auf die beiden aufgehobenen Vermerke als Rechtsgrundlage, sodass einige seiner Anweisungen nicht mehr gelten.
Für einen Hersteller, der nicht alle Verfahren nachweisen kann, enthält das Formular dennoch einen Aktionsplan und Meilensteine (POA&M) zur Schließung der Lücken, gestützt durch eine Verlängerung oder Ausnahmegenehmigung des OMB. M-26-05 sieht keinen Ersatz für dieses Verfahren vor, daher sollte ein Hersteller in dieser Situation bei der anfragenden Behörde nachfragen, was diese stattdessen akzeptiert.
Was der Unterzeichner festlegt und was offen bleibt
In Abschnitt III des Formulars mit der Überschrift „Bescheinigung und Unterschrift“ wird eine Person gebeten, im Namen des Herstellers zu erklären, dass die Software in Übereinstimmung mit den dort aufgeführten Praktiken entwickelt wurde. Der Abschnitt enthält vier nummerierte Aussagen, denen jeweils zwei einschränkende Formulierungen vorangestellt sind. Der Unterzeichner bescheinigt, dass der Hersteller „nach bestem Wissen“ diese Praktiken bei der Entwicklung der in Abschnitt I genannten Software „derzeit konsequent anwendet“. Diese Praktiken umfassen die Entwicklungsumgebung, die Code-Lieferkette, die Herkunft (Aufzeichnungen darüber, woher der Code stammt und wie er erstellt wurde) sowie die Vorgehensweise des Herstellers bei der Erkennung und Behebung von Sicherheitslücken. Abschnitt III enthält keine Bestimmung, die den Unterzeichner verpflichtet, zu erklären, dass die Software frei von Sicherheitslücken ist.
Beide Einschränkungen schränken die Aussage ein. „Derzeit“ bezieht sich auf die zum Zeitpunkt der Unterzeichnung des Formulars geltenden Praktiken, und „nach bestem Wissen“ beschränkt die Aussage auf das, was dem Unterzeichner bekannt ist. Weder in den Anweisungen noch in Abschnitt III wird angegeben, was ein Unterzeichner tun muss, um zu bestätigen, dass die Praktiken umgesetzt werden, und die benannte Person benötigt keine bestimmte Berufsbezeichnung. Daher entscheidet der Produzent, wer für die Praktiken bürgt – beispielsweise die Teams, die die Builds durchführen –, bevor jemand unterschreibt. Eine Unterschrift auf dieser Grundlage ist nur so fundiert wie das Wissen dieser Teams.
Tabelle 1. Angaben des Formulars zur Unterschrift
| Artikel | Was im Formular steht | Grundlage |
|---|---|---|
| Unterzeichner | Der Geschäftsführer des Softwareherstellers oder ein von ihm benannter Mitarbeiter, der befugt ist, das Unternehmen zu vertreten | Anweisungen zum Ausfüllen des Formulars |
| Umfang | Unternehmensweit, einzelne Produkte, mehrere Produkte oder bestimmte Produktversionen | Formular, Abschnitt I |
| Alternative | Dem Formular liegt ein Gutachten eines unabhängigen Dritten bei; in diesem Fall unterzeichnet der Hersteller das Formular nicht. | Anweisungen zum Ausfüllen des Formulars und Abschnitt III |
Ein Hersteller kann anstelle einer Unterschrift eine Bewertung durch einen Dritten beifügen. Der Prüfer muss eine unabhängige Prüfstelle (Third Party Assessor Organization, 3PAO) sein, die entweder im Rahmen des Federal Risk and Authorization Management Program (FedRAMP) zertifiziert oder von einem zuständigen Behördenvertreter schriftlich genehmigt wurde. Die Bewertung muss zudem auf der Grundlage der einschlägigen Leitlinien des National Institute of Standards and Technology (NIST) erfolgen, die alle im Formular aufgeführten Elemente abdecken. FedRAMP bezeichnet diese Organisationen nun als unabhängige Gutachter, obwohl im CISA-Formular weiterhin der Begriff „3PAO“ verwendet wird. Um eine Begutachtung zu verwenden, kreuzt der Hersteller ein Kästchen in Abschnitt III an und fügt sie bei.
Wo Komponenten von Drittanbietern in der Aufstellung stehen
In Abschnitt I sind vier Kategorien aufgeführt, die das Formular nicht abdeckt. Eine davon sind sogenannte Open-Source- und proprietäre Komponenten von Drittanbietern, d. h. solche, die in das von einer Behörde genutzte Software-Endprodukt integriert sind. Ein Hinweis im selben Abschnitt besagt, dass die Unterzeichner die in Abschnitt III genannten Vorgehensweisen für den vom Hersteller entwickelten Code bestätigen. In den Anweisungen heißt es jedoch, dass Hersteller, die Komponenten von Drittanbietern verwenden, bestätigen müssen, bestimmte in Abschnitt III genannte Maßnahmen ergriffen zu haben, um die Risiken der Nutzung dieser Komponenten zu minimieren. Im Zusammenspiel bedeuten der Ausschluss und die Anweisungen, dass der Unterzeichner nicht für den Code von Drittanbietern selbst bürgt, sondern nur für die Maßnahmen des Herstellers zur Bewältigung dieses Risikos.
In den Aussagen 2 und 3 werden Komponenten von Drittanbietern namentlich erwähnt. In Aussage 2 wird ein „nach bestem Wissen und Gewissen unternommener Aufwand“ gefordert, um vertrauenswürdige Quellcode-Lieferketten aufrechtzuerhalten, wobei „automatisierte Tools oder vergleichbare Prozesse“ eingesetzt werden sollen, um die Sicherheit von internem Code und Komponenten von Drittanbietern zu gewährleisten und damit verbundene Schwachstellen zu verwalten. In Aussage 3 wird der Hersteller aufgefordert, die Herkunft von internem Code und Komponenten von Drittanbietern „soweit wie möglich“ nachzuweisen. Zur Information: Der Anhang des Formulars ordnet beide Punkte den SSDF-Aufgaben zu, einschließlich der Aufgabe, Open-Source-Komponenten zu überprüfen.
Beide Aussagen lassen Ermessensspielraum. Das Formular enthält keine Definition der Begriffe „vertrauenswürdige Quellcode-Lieferketten“ oder „vergleichbare Prozesse“ und legt auch nicht fest, in welchem Umfang die Rückverfolgbarkeit als realisierbar angesehen wird. Jeder Hersteller muss selbst herausfinden, was diese Begriffe für seine eigene Software bedeuten, und der Unterzeichner bestätigt das Ergebnis lediglich nach bestem Wissen und Gewissen.
Außerdem hängt dies davon ab, welchen Code von Drittanbietern ein Build enthält, und das Formular überlässt die Wahl der Methode dem Hersteller. Ein Hersteller, der diesen Code nicht auflisten kann, hat keine Möglichkeit zu wissen, ob er eine der beiden Anforderungen erfüllt.
Auch in Abschnitt III wird nichts über Komponenten gesagt, deren Wartung durch den Upstream-Entwickler eingestellt wurde. In Aussage 4 wird weiterhin eine Richtlinie oder ein Verfahren gefordert, um entdeckte Sicherheitslücken vor der Veröffentlichung zu beheben. Bei einer Komponente, deren Betreuer keine Korrekturen mehr bereitstellen, kann sich diese Richtlinie nicht auf eine Veröffentlichung durch den Upstream-Entwickler stützen. Damit bleiben Optionen wie der Austausch der Komponente oder das Patchen der verwendeten Version, entweder intern oder durch einen Anbieter, der Korrekturen zurückportiert.
Was auf die Unterschrift folgt
Mit der Unterzeichnung des Formulars gehen Verpflichtungen ein, die über das Datum der Unterzeichnung hinausreichen. Abschnitt III enthält eine Erklärung, wonach der Hersteller jede Behörde, die das Formular erhalten hat, benachrichtigen wird, „falls und sobald“ er die Praktiken nicht mehr konsequent anwendet. Eine Fußnote fügt hinzu, dass eine solche Bescheinigung auch für zukünftige Versionen des genannten Produkts bindend ist, bis der Hersteller diesen Stellen mitteilt, dass seine Entwicklungspraktiken nicht mehr den Vorgaben entsprechen. Die Benachrichtigungspflicht gilt vom Hersteller gegenüber den Stellen, und das Formular enthält keine Angaben dazu, wie der Unterzeichner über eine Abweichung informiert wird. Die Teams, die die Praktiken umsetzen, werden eine Abweichung wahrscheinlich als Erste bemerken. Der Hersteller benötigt einen Prozess, über den diese Teams dies dem Unterzeichner melden können.
In der für das Ministerium für Innere Sicherheit verfassten Datenschutzerklärung des Formulars werden zwei Konsequenzen dargelegt. Werden die angeforderten Informationen nicht bereitgestellt, kann dies dazu führen, dass die Behörde die Nutzung der Software einstellt. Die vorsätzliche Angabe falscher oder irreführender Informationen kann einen Verstoß gegen das Bundesstrafgesetz 18 U.S.C. § 1001 darstellen.
Hinweis: Jede Behörde, die das Formular verwendet, muss eine eigene Datenschutzerklärung gemäß dem Datenschutzgesetz bereitstellen, sodass der Wortlaut der Folgenbeschreibung, den der Unterzeichner sieht, je nach Behörde variieren kann.
Ein Unterzeichner, der sicherstellen möchte, dass die Bescheinigung korrekt bleibt, sollte sich vor der Unterzeichnung darüber informieren, welche Teams für die einzelnen Verfahren bürgen, wie der Hersteller Begriffe wie „vergleichbare Prozesse“ und „durchführbar“ definiert hat und wie diese Teams einen Verstoß melden werden.
Wissen, was in Ihre Builds einfließt
SecureChain von TuxCare überprüft den Code jedes Open-Source-Pakets auf versteckte Malware und erstellt das Paket aus dem Quellcode in abgesicherten, isolierten Umgebungen neu. Ein Paket, das die Überprüfung nicht besteht, wird von Ihrer Umgebung ferngehalten. Jedes Paket, das Sie erhalten, enthält eine SBOM mit einer Auflistung seines Inhalts sowie einen Herkunftsnachweis. Solange das Upstream-Projekt ein Paket noch pflegt, patcht SecureChain es im Rahmen einer Service-Level-Vereinbarung (SLA), und der „Endless Lifecycle Support“ (ELS) stellt auch nach Beendigung der Upstream-Pflege weiterhin Korrekturen bereit. SecureChain deckt Open-Source-Abhängigkeiten in JavaScript, Python, Java, Go und PHP ab.
Wenn Ihr Team nicht sagen kann, was in den Open-Source-Abhängigkeiten enthalten ist, die in Ihre Builds einfließen, oder wer diese patcht, sobald die Weiterentwicklung im Upstream eingestellt wird, liefert SecureChain Antworten auf beide Fragen.
FAQ
Was ist das CISA-Formular zur Bescheinigung der sicheren Softwareentwicklung?
Es handelt sich um das Formular, mit dem Softwarehersteller bestätigen, dass ihre Software in Übereinstimmung mit den Praktiken des „Secure Software Development Framework“ (SSDF) entwickelt wurde. Die Cybersecurity and Infrastructure Security Agency (CISA) hat es am 11. März 2024 veröffentlicht. Bei der Selbstbescheinigung durch den Hersteller wird das Formular vom Vorstandsvorsitzenden (CEO) oder einer von ihm benannten Person unterzeichnet, die als Mitarbeiter befugt ist, das Unternehmen rechtlich zu vertreten. Alternativ kann ein Hersteller eine Bewertung durch einen unabhängigen Dritten beifügen.
Ist das Formular zur Bescheinigung der sicheren Softwareentwicklung optional oder weiterhin obligatorisch?
Dies ist nun keine behördenübergreifende Vorschrift mehr. Das Memo M-26-05 des Office of Management and Budget (OMB) vom 23. Januar 2026 hob die Memos M-22-18 (14. September 2022) und M-23-16 (9. Juni 2023) auf, die es den Behörden erlaubt hatten, betroffene Software erst nach einer Bestätigung durch den Hersteller zu nutzen. Jede Behörde entscheidet nun selbst, ob sie das Formular verwendet; daher kann eine bestimmte Behörde Sie weiterhin darum bitten, eines vorzulegen.
Welche Software wird in diesem Formular behandelt?
Die Anweisungen gelten für Software, die nach dem 14. September 2022 (dem Datum des OMB-Memos M-22-18) entwickelt wurde, für ältere Software, bei der nach diesem Datum eine wesentliche Versionsänderung vorgenommen wurde, sowie für Software, deren Hersteller fortlaufende Änderungen bereitstellt, wie beispielsweise Software-as-a-Service. Diese Vorschriften stammten aus den Memos M-22-18 und M-23-16, die durch M-26-05 aufgehoben wurden; daher kann eine Behörde, die das Formular nun anfordert, den Geltungsbereich selbst festlegen. Die Anweisungen und Vertragsbedingungen der anfordernden Behörde sind hierfür maßgeblich. In Abschnitt I des Formulars sind außerdem vier Kategorien aufgeführt, die das Formular nicht abdeckt, darunter in das Produkt integrierte Komponenten von Drittanbietern.
Wie werden in dem Formular Komponenten von Drittanbietern und Open-Source-Komponenten behandelt?
Open-Source- und proprietäre Komponenten von Drittanbietern, die in das Produkt integriert sind, sind vom Geltungsbereich ausgeschlossen. In den Anweisungen heißt es außerdem, dass Hersteller, die Komponenten von Drittanbietern verwenden, bestätigen müssen, dass sie die im Abschnitt „Bescheinigung“ (Abschnitt III) des Formulars aufgeführten Maßnahmen ergriffen haben, um die Risiken, die mit der Nutzung dieser Komponenten verbunden sind, zu minimieren. Zwei dieser Maßnahmen – zur Sicherheit der Lieferkette und zur Herkunft – nennen die Komponenten direkt.
Was steht im Formular zu falschen oder fehlenden Angaben?
In der für das Ministerium für Innere Sicherheit verfassten Datenschutzerklärung heißt es, dass die Nichtbereitstellung der angeforderten Informationen dazu führen kann, dass die Behörde die Nutzung der Software einstellt. Die vorsätzliche Angabe falscher oder irreführender Informationen kann einen Verstoß gegen 18 U.S.C. § 1001, eine Strafvorschrift, darstellen. Jede Behörde, die das Formular verwendet, stellt ihre eigene Datenschutzerklärung bereit.
Kann eine Begutachtung durch einen Dritten die Unterschrift ersetzen?
Ja. Ein Hersteller kann eine Bewertung einer unabhängigen Bewertungsorganisation (3PAO) beifügen, die im Rahmen des Federal Risk and Authorization Management Program (FedRAMP) zertifiziert oder von einem zuständigen Behördenvertreter schriftlich genehmigt wurde. Die 3PAO muss alle Elemente des Formulars anhand der einschlägigen NIST-Leitlinien bewerten. Der Hersteller kreuzt dann das Kästchen in Abschnitt III an, fügt die Bewertung bei und unterschreibt nicht.
Was passiert mit einer Bescheinigung, wenn die Software ein neues Update erhält?
Eine Bescheinigung gilt für zukünftige Versionen des genannten Produkts, bis der Hersteller den Behörden mitteilt, dass seine Entwicklungspraktiken nicht mehr den Anforderungen entsprechen. Dies steht im Einklang mit einer Zusage im Unterschriftsbereich selbst, in der sich der Hersteller verpflichtet, jede Behörde, die das Formular erhalten hat, zu benachrichtigen, falls er die Praktiken nicht mehr konsequent anwendet.
