Übersetzung: englisches Original von Italo Vignoli
Am 30. Juli 2026 veröffentlichte die US-amerikanische Cybersecurity and Infrastructure Security Agency das Dokument Open Source Software: Security Principles and Practices– einen 31-seitigen Leitfaden für zivile Bundesbehörden. Er ist kostenlos erhältlich und mit der Kennzeichnung TLP:CLEAR versehen, was bedeutet, dass er uneingeschränkt weitergegeben werden darf.
Das Dokument richtet sich an US-Bundesbehörden und erfüllt die Vorgaben zweier Präsidialdekrete zur Cybersicherheit auf Bundesebene. Es behandelt vier Bereiche: die Nutzung von Open-Source-Lösungen, die Beteiligung an Open-Source-Projekten, die Entwicklung von Open-Source-Software sowie die Evaluierung von Open-Source-Modellen der künstlichen Intelligenz. Die nachstehenden Anmerkungen beziehen sich auf die ersten drei dieser Bereiche.
Die darin enthaltenen Analysen sind nicht auf einen bestimmten Rechtsraum beschränkt; auch öffentliche Verwaltungen anderswo – etwa in Europa – werden feststellen, dass das Dokument unter Verwendung der Terminologie des Risikomanagements verschiedene Standpunkte darlegt, die von der Open-Source-Community bereits seit zwei Jahrzehnten vertreten werden.
Was die Richtlinie tatsächlich besagt
Die Kernaussage ist präziser, als es die Schlagzeilen vermuten lassen. Die CISA behauptet nicht, dass Open-Source-Software sicherer sei als proprietäre Software. Sie stellt vielmehr fest, dass Open-Source-Software „weder riskanter noch weniger riskant ist als andere Software“, und verortet den Unterschied an anderer Stelle: Bei Open Source kann eine Organisation die Code-Qualität und die Sicherheit direkt beurteilen, anstatt sich allein auf die Zusicherungen des Anbieters zu verlassen.
Hierbei geht es um die Überprüfbarkeit, nicht um Fehlerquoten. Zudem ist dies die haltbarere und für die Beschaffung folgenreichere Argumentation. Wenn eine Behörde proprietäre Software prüft, bewertet sie die Aussage eines Anbieters über dessen eigenes Produkt. Prüft sie hingegen Open-Source-Software, so bewertet sie das Produkt selbst.
Der Leitfaden zieht daraus ausdrücklich die entsprechende Schlussfolgerung. Zu den Vorteilen, die für Bundesbehörden aufgeführt werden, zählt eine verringerte Anbieterbindung (Vendor Lock-in): Offene Standards und veränderbarer Code, so die CISA, schützen Behörden vor „Fallen der Abhängigkeit von proprietären Systemen“. Damit hat eine nationale Cybersicherheitsbehörde das Thema Anbieterbindung in einem Sicherheitsdokument behandelt – und nicht in einem Dokument zur Wettbewerbspolitik. Dies markiert einen bedeutsamen Wandel hinsichtlich des Kontexts, in dem dieses Argument angeführt wird.
Das C4-Framework
Der für die Praxis nützlichste Teil des Leitfadens ist Anhang A; er beschreibt das C4-Framework zur Bewertung der Vertrauenswürdigkeit eines Open-Source-Projekts. Dessen Grundannahme lautet: Da Mitwirkende unter Umständen pseudonym agieren und keiner Lieferverpflichtung unterliegen, lässt sich die Vertrauenswürdigkeit nicht anhand der Frage beurteilen, wer die Software erstellt hat. Entscheidend ist vielmehr, *wie* die Software erstellt wurde – ein Aspekt, der bei der Open-Source-Entwicklung sichtbar wird, bei der geschlossenen Entwicklung hingegen nicht.
C4 unterteilt die entsprechenden Nachweise in vier Kategorien:
- Codebasis– Aktualität der Commits, bekannte Schwachstellen, Aktualität der Abhängigkeiten.
- Community– Anzahl der Maintainer, institutionelle Struktur, Einbettung des Projekts in eine Stiftung.
- Verhaltensweisen– Vorhandensein einer Richtlinie zur Offenlegung von Schwachstellen, Erforderlichkeit von Code-Reviews, Praxis beim Zusammenführen eigener Commits durch Maintainer, Lizenz, Verhaltenskodex.
- Konfiguration– Sicherheit der Standardeinstellungen sowie unterstützte Härtungsmaßnahmen.
Der Rahmen wird in fünf Schritten angewendet: Identifizierung messbarer Kriterien, Festlegung der Risikotoleranz und Gewichtung der Kriterien, Erfassung von Beobachtungen (unter Einsatz automatisierter Werkzeuge, sofern verfügbar), Bewertung anhand der einzelnen Kriterien sowie Vergleich des Ergebnisses mit der Toleranzschwelle.
Wir ermutigen öffentliche Verwaltungen dazu, diesen Rahmen auf LibreOffice anzuwenden. Für jede Kategorie lassen sich Belege aus öffentlich zugänglichen Quellen anführen: eine lückenlose Commit-Historie seit 2010, eine veröffentlichte Sicherheitsrichtlinie samt Verfahren zur Offenlegung von Schwachstellen, obligatorische Peer-Reviews, eine OSI-konforme Lizenz, ein dokumentierter Verhaltenskodex sowie eine Governance-Struktur – die „The Document Foundation“, eine deutsche Stiftung mit gewähltem Vorstand –, die öffentlich dokumentiert und nicht bloß behauptet ist.
Wir ermutigen Verwaltungen zudem, denselben Rahmen auf jede infrage kommende Lösung – einschließlich proprietärer Systeme – anzuwenden und dabei festzuhalten, welche Fragen sich beantworten lassen und welche nicht.
Mitwirken und die Support-Frage
Der Leitfaden geht auch auf eine Frage ein, die öffentliche Verwaltungen im Zusammenhang mit der Einführung von Open Source regelmäßig stellen: Wer ist für Fehlerbehebungen verantwortlich? Die Antwort der CISA lautet, dass keine einzelne Stelle dazu verpflichtet ist, diese bereitzustellen, und dass Behörden daher entsprechende Vorkehrungen treffen sollten – etwa durch den Einsatz von internem Personal, die Beauftragung externer Dienstleister oder eine Kombination aus beidem. Dabei sollten sie im Umgang mit Upstream-Projekten zwei Prinzipien befolgen: Zusammenarbeit statt Forderungen und die Rückführung von Fehlerbehebungen in das Upstream-Projekt.
Dies beschreibt die Funktionsweise des LibreOffice-Ökosystems treffend. Support, langfristige Wartung und kundenspezifische Entwicklungen werden von zertifizierten Entwicklern und Migrationsspezialisten geleistet; deren Beiträge fließen in die gemeinsame Codebasis zurück und kommen so auch allen anderen Implementierungen zugute. Der Leitfaden weist zu Recht darauf hin, dass dies eine entsprechende Planung seitens der Organisationen erfordert. Ebenso richtig ist die Feststellung, dass die daraus resultierenden Verbesserungen geteilt und nicht exklusiv vereinnahmt werden.
Die CISA merkt zudem an, dass eine Organisation als letzten Ausweg die Pflege eines Forks übernehmen kann, falls ein Projekt nicht mehr gewartet wird. Für diese Option gibt es bei proprietärer Software kein Äquivalent; dort endet der Support nach dem Zeitplan des Anbieters, ohne dass es eine vergleichbare Lösungsmöglichkeit gäbe.
Anmerkung zum Geltungsbereich
Das Dokument nennt kein bestimmtes Produkt. Die CISA erklärt ausdrücklich, dass sie keine kommerziellen Unternehmen, Produkte oder Dienstleistungen empfiehlt, und nichts in diesem Leitfaden ist als Bewertung einer bestimmten Software zu verstehen. Vielmehr werden darin Kriterien aufgeführt. Die Feststellung, dass LibreOffice diese erfüllt, stammt von uns und stützt sich auf Belege, die von jedermann überprüft werden können.
Open Source Software: Security Principles and Practicesist bei der CISA erhältlich: https://www.cisa.gov/resources-tools/resources/open-source-software-security-principles-and-practices
Die Ankündigung der CISA: https://www.cisa.gov/news-events/news/cisa-guide-helps-federal-agencies-securely-and-effectively-use-open-source-software
