CISA hat am 30. Juli 2026 die Leitlinie „Open Source Software: Security Principles and Practices“ veröffentlicht. Sie behandelt die sichere Nutzung, Bewertung und Veröffentlichung von Open-Source-Software über den gesamten Lebenszyklus. Genannt werden das neue C4 Framework zur Vertrauensbewertung sowie Empfehlungen zu Schwachstellenmanagement, Software Bills of Materials, sicherer Entwicklung und offenen KI-Systemen. Für Unternehmen ist die zentrale Botschaft klar: Open Source ist kein einmaliger Beschaffungsvorgang, sondern ein dauerhaft zu steuernder Bestandteil der Software-Lieferkette. Der praktische Nutzen entsteht erst, wenn Auswahl, Betrieb und Ausstieg miteinander verbunden sind.
Phase 1: Geschäftskritikalität vor Projektpopularität
Die Auswahl beginnt nicht mit Sternen, Downloads oder einer bekannten Marke, sondern mit dem geplanten Einsatz. Ein Paket in einem internen Hilfstool hat einen anderen Risikokontext als eine Komponente in Identität, Zahlungsverkehr oder Produktionssteuerung. Verantwortliche dokumentieren Zweck, Datenzugriff, Ausfallwirkung, Exposition und Austauschbarkeit. Erst dadurch wird klar, wie tief die Prüfung gehen muss. Je größer der mögliche Geschäftsschaden, desto höhere Anforderungen gelten für Vertrauen, Pflegefähigkeit und Nachweisbarkeit.
Phase 2: Vertrauen mit C4 strukturiert bewerten
CISA führt das C4 Framework als Ansatz zur Vertrauensbewertung ein. Ohne Details zu erfinden, lässt sich der Zweck in praktische Prüfbereiche übersetzen: Wer trägt Verantwortung für das Projekt? Wie transparent sind Entwicklung und Änderungen? Wie werden Sicherheitsmeldungen behandelt? Welche Hinweise gibt es auf aktive Pflege und belastbare Veröffentlichungsprozesse? Ein Framework ersetzt kein Urteil, sorgt aber dafür, dass Teams wiederholbar dieselben Fragen stellen und Ausnahmen begründen.
- Verantwortung: Maintainer, Governance und Kontaktwege für Sicherheitsfragen identifizieren.
- Transparenz: Repository, Releases, Abhängigkeiten und Änderungsverlauf nachvollziehen.
- Reaktionsfähigkeit: Umgang mit Schwachstellen, Meldungen und Updates bewerten.
- Betriebsfähigkeit: internes Know-how, Fork- oder Ersatzoptionen und langfristige Pflege klären.
- Kontext: Prüftiefe an Daten, Exposition und Geschäftskritikalität anpassen.
Phase 3: Inventar und SBOM als Betriebsdaten nutzen
Eine Software Bill of Materials hilft nur, wenn sie aktuell, auffindbar und mit Produkten sowie Verantwortlichen verknüpft ist. Das Unternehmen muss wissen, wo eine Komponente eingesetzt wird, in welcher Version und mit welchen transitiven Abhängigkeiten. Eine SBOM ist deshalb kein Ablagedokument für Audits, sondern Eingangsdaten für Schwachstellenbewertung, Kundenkommunikation und Austauschentscheidungen. Die bestehende GNS-Berichterstattung zu SBOM-Mindestanforderungen bleibt dabei ein eigenes Thema; hier steht der OSS-Lebenszyklus im Mittelpunkt.
Für den Start reicht ein priorisiertes Inventar kritischer Anwendungen. Teams erfassen direkte und transitive Komponenten, Versionen, Herkunft, Lizenz, Owner und geplanten Aktualisierungsweg. Fehlende Angaben werden sichtbar als Risiko geführt. Der Prozess muss neue Abhängigkeiten bereits bei Pull Request oder Build erkennen, statt erst bei einem Vorfall manuell nach ihnen zu suchen.
Phase 4: Sicher integrieren und kontinuierlich pflegen
Open Source wird innerhalb der eigenen Architektur zu Unternehmenssoftware. Daher gelten sichere Entwicklungspraktiken auch für die Integration: Abhängigkeiten werden gepinnt, Artefakte aus kontrollierten Quellen bezogen, Änderungen überprüft und Builds reproduzierbar gestaltet, soweit der Kontext es erfordert. Automatische Updates ohne Tests sind ebenso riskant wie dauerhaft eingefrorene Versionen. Ein definierter Updatekanal mit Tests, Freigabe und Rückfallplan verbindet Geschwindigkeit und Kontrolle.
- Neue OSS-Komponente mit Zweck, Owner und Kritikalität registrieren.
- Vertrauen und Pflegefähigkeit anhand einheitlicher Kriterien bewerten.
- Version und Abhängigkeiten in Inventar und SBOM aufnehmen.
- Bezugsquelle, Build, Tests und Freigabe kontrollieren.
- Schwachstellen und Projektänderungen kontinuierlich überwachen.
- Update, Ersatz oder Ausstieg anhand dokumentierter Risiken entscheiden.
Phase 5: Schwachstellen nach tatsächlichem Risiko bearbeiten
Eine gemeldete CVE allein bestimmt nicht die Reihenfolge. Entscheidend sind Erreichbarkeit, Ausnutzbarkeit im eigenen Aufbau, Daten- und Berechtigungsumfang, aktive Ausnutzung und verfügbare Abhilfen. Teams brauchen eine verbindliche Verbindung zwischen externer Meldung, SBOM-Treffer, technischem Owner und Geschäftspriorität. Wird ein Update nicht sofort eingespielt, werden Ausgleichsmaßnahmen, Frist und Entscheider dokumentiert. So entsteht eine prüfbare Risikoentscheidung statt eines unübersichtlichen Backlogs.
Phase 6: Veröffentlichung und Open-Source-KI gesondert steuern
Wer selbst Software veröffentlicht, muss klären, welche Bestandteile offengelegt werden dürfen, wie Secrets und interne Daten ausgeschlossen bleiben und wer Sicherheitsmeldungen bearbeitet. Offene KI-Systeme erweitern diese Prüfung: Neben Code können Modellgewichte, Datensätze, Konfigurationen und Nutzungsgrenzen relevant sein. „Open Source“ ist bei KI kein ausreichendes Sicherheitsurteil. Unternehmen bewerten Herkunft, Lizenz, Datenfluss, ausführbaren Code, Modellzugriff und den Betriebskontext getrennt.
Ein 30-Tage-Startprogramm kann mit den zehn geschäftskritischsten Anwendungen beginnen. Woche eins bestimmt Owner und Kritikalität, Woche zwei erstellt oder verifiziert Inventar und SBOM, Woche drei bewertet zentrale OSS-Komponenten nach einheitlichen Vertrauenskriterien, Woche vier schließt die größten Lücken in Update- und Schwachstellenprozessen. Messbar sind Inventarabdeckung, Zeit bis zum Owner, Anteil bewerteter kritischer Komponenten, Update-Durchlaufzeit und dokumentierte Ausstiegspfade. Damit wird CISAs Leitlinie zu einem belastbaren Betriebsmodell statt zu einer weiteren Richtlinie im Archiv.