Open Source im Unternehmen: Wer kümmert sich um die Abhängigkeiten?

Der unsichtbare Teil der eigenen Software

Ein selbst entwickelter Dienst besteht oft aus mehr als dem Code des eigenen Teams. Bibliotheken, Laufzeitumgebungen und weitere Komponenten bringen zusätzliche Abhängigkeiten mit. Wenn später eine Schwachstelle bekannt wird, hilft die Frage nach dem ursprünglichen Entwickler allein nicht weiter. Das Unternehmen muss wissen, welche ausgelieferte Version betroffen ist, wo sie läuft und wer die Korrektur verantwortet.

Eine Software Bill of Materials, kurz SBOM, beschreibt Bestandteile und ihre Beziehungen. Die US-Telekommunikationsbehörde NTIA hat dafür 2021 Mindestbestandteile veröffentlicht. Die Grundidee einer nachvollziehbaren Stückliste bleibt nützlich, auch wenn sich Formate und konkrete Anforderungen weiterentwickeln. Eine SBOM ist jedoch weder ein Sicherheitszertifikat noch die Zusage, dass alle Bestandteile aktuell und fehlerfrei sind.

Eine Liste pro ausgelieferter Version

Der praktische Einstieg beginnt bei einem klar abgegrenzten Produkt. Erfassen Sie nicht nur die direkt eingebundenen Bibliotheken, sondern auch deren mitgelieferte Abhängigkeiten. Verknüpfen Sie die Liste mit einer eindeutig identifizierbaren veröffentlichten Version. Sonst beschreibt das Dokument möglicherweise den heutigen Entwicklungsstand, während im Betrieb eine andere Zusammenstellung läuft.

Für die Nutzung im Unternehmen sollte zusätzlich feststehen, welchem Dienst und welchem verantwortlichen Team diese Version zugeordnet ist. Diese Zuordnung muss nicht vollständig in der SBOM selbst stehen; sie kann über ein verbundenes Inventar erfolgen. Entscheidend ist, dass eine Meldung über eine Komponente zu den tatsächlich betroffenen Anwendungen führt. Eine umfangreiche Datei ohne Verbindung zum Betrieb löst diese Aufgabe nicht.

Vereinbaren Sie bei eingekaufter Software, in welchem Format, zu welchem Zeitpunkt und für welche Version der Lieferant Komponentendaten bereitstellt. Klären Sie auch, wie Korrekturen an einer fehlerhaften Stückliste kommuniziert werden. Ein einmal übergebenes Dokument verliert seinen Wert, wenn spätere Aktualisierungen nicht mehr damit verbunden werden können.

Ein Alarm braucht eine begründete Einordnung

Eine gemeldete Schwachstelle ist ein Prüfauftrag. Zunächst muss geklärt werden, ob die betroffene Version tatsächlich enthalten ist und ob die verwundbare Funktion in der konkreten Anwendung erreichbar ist. Hinzu kommen mögliche Angriffswege, vorhandene Schutzmaßnahmen und die Bedeutung des Dienstes. Daraus ergibt sich die Dringlichkeit. Die bloße Anzahl offener Meldungen bildet das Geschäftsrisiko nur unvollständig ab.

Die Entscheidung gehört in einen nachvollziehbaren Vorgang: Befund, betroffene Systeme, Begründung, Verantwortliche und nächste Frist. Wird ein Update verschoben, sollte die alternative Maßnahme ebenso konkret sein wie der Termin für eine erneute Prüfung. Eine pauschale Ausnahme ohne Ablaufdatum kann über Jahre übersehen werden. Eine begründete Nichtbetroffenheit ist dagegen ein nützliches Ergebnis, wenn ihre Voraussetzungen dokumentiert bleiben.

Das NIST Secure Software Development Framework behandelt sichere Entwicklung und den Umgang mit Schwachstellen als zusammenhängende Aufgaben. Für Anwenderunternehmen folgt daraus eine organisatorische Anforderung: Entwicklung, Einkauf und Betrieb brauchen eine gemeinsame Sprache. Wer eine Komponente auswählt, wer den Dienst betreibt und wer im Notfall eine Änderung freigibt, sollte schon vor dem ersten Alarm geklärt sein.

Projektkennzahlen sind Hinweise, keine Freigabe

OpenSSF Scorecard untersucht Sicherheitspraktiken von Open-Source-Projekten anhand automatisierter Prüfungen. Einzelne Ergebnisse können beispielsweise auf fehlende Schutzmaßnahmen im Entwicklungsprozess hinweisen. OpenSSF zeigt in einem Fachbeitrag, wie sich solche Informationen mit einer SBOM verbinden lassen. Der Nutzen liegt in gezielten Prüfaufträgen; aus einem Gesamtwert allein lässt sich keine verlässliche Freigabe für jeden Einsatz ableiten.

Auch ein auffälliger Einzelbefund benötigt Kontext. In dem veröffentlichten OpenSSF-Beispiel mussten zunächst verdächtig wirkende Binärdateien näher untersucht werden; sie dienten dort Test- beziehungsweise Bauzwecken. Die redaktionelle Schlussfolgerung lautet deshalb: Lassen Sie ein Werkzeug Auffälligkeiten suchen, aber definieren Sie zusätzlich, wer sie fachlich bewertet. Beliebtheit, Downloadzahlen oder eine hohe Punktzahl ersetzen diese Prüfung nicht.

Für besonders wichtige Komponenten sollten außerdem Wartung, nachvollziehbare Veröffentlichungen und erreichbare Sicherheitskontakte betrachtet werden. Die Frage nach einem Ersatz ist legitim: Gibt es eine realistische Alternative, wenn das Projekt nicht mehr gepflegt wird? Ein Austausch muss nicht sofort erfolgen. Ein dokumentierter Ausweichweg kann aber verhindern, dass eine einzelne Bibliothek später ein gesamtes Vorhaben blockiert.

Der nächste Patch ist der eigentliche Praxistest

Messen Sie den Prozess an einer konkreten Änderung. Wie schnell findet das Team die betroffenen Dienste? Kann es eine korrigierte Version bauen und in einer geeigneten Umgebung testen? Sind Rückkehr zum vorherigen Stand, Sicherung und Beobachtung nach der Veröffentlichung vorbereitet? Erst wenn dieser Ablauf funktioniert, wird aus der Bestandsaufnahme eine betriebliche Fähigkeit.

Für einen ersten Monat reicht ein begrenzter Umfang: ein geschäftskritischer Dienst, eine aktuelle Stückliste, eine klar benannte Verantwortung und ein geübter Aktualisierungsvorgang. Erweitern Sie den Umfang anschließend schrittweise. Der sinnvolle Erfolgsmaßstab ist die Anzahl nachvollziehbar behandelter Risiken und die Zeit bis zur wirksamen Korrektur. Die Größe der gesammelten Komponentenliste allein sagt darüber wenig aus.

• Komponentenlisten mit veröffentlichten Versionen und laufenden Diensten verbinden.
• Meldungen nach tatsächlicher Betroffenheit und Geschäftsrisiko priorisieren.
• Ausnahmen begründen, befristen und erneut prüfen.
• Den Weg vom Befund bis zum veröffentlichten Update praktisch erproben.