Open-Source-Komponenten bewerten und pflegen

Begriffe vorab

• Abhängigkeit: Fremde Bibliothek oder Paket, das dein Projekt nutzt.
• Transitive Abhängigkeit: Abhängigkeit einer Abhängigkeit.
• Lockfile: Datei, die genaue Versionen festschreibt.
• Pinning: Festlegen auf eine bestimmte Version oder einen bestimmten Prüfwert.
• OpenSSF Scorecard: Automatisches Werkzeug, das Sicherheitspraktiken eines Open-Source-Projekts bewertet.

Vor dem Einbau: Ist die Komponente gesund?

Jede Abhängigkeit vergrößert die Angriffsfläche. Prüfe vor dem Einbau, ob sie gepflegt wird, wer dahintersteht, wie schnell auf Meldungen reagiert wird und ob es einen Weg gibt, Schwachstellen zu melden. Ein Hilfsmittel ist die OpenSSF Scorecard, die im November 2020 vorgestellt wurde: Sie prüft automatisch Sicherheitspraktiken eines Projekts und vergibt eine Bewertung von 0 bis 10. Zu den Prüfungen gehören zum Beispiel Branch-Protection (Schutz vor ungeprüften Änderungen), Dependency-Update-Tool (automatische Aktualisierung der Abhängigkeiten) und Pinned-Dependencies (festgelegte Versionen). Nach einer Quelle sind es 18 Kriterien.

Während des Betriebs: Pflegen statt vergessen

• Versionen festschreiben (Lockfile), damit Builds reproduzierbar bleiben und sich keine Überraschungen einschleichen.
• Automatische Update-Vorschläge nutzen und diese prüfen, statt blind zu übernehmen.
• Ungenutztes entfernen: Jede entfernte Abhängigkeit ist eine weniger.
• Sicherheitsmeldungen beobachten für die Komponenten, die wirklich kritisch sind.
• Bei Aufgabe eines Projekts rechtzeitig einen Ersatz suchen.

Die Grenzen von Bewertungen

Ein hoher Score bedeutet gute Praxis, nicht fehlerfreien Code. Ein niedriger Score kann bei kleinen, ruhigen Projekten auch einfach heißen, dass Automatisierung fehlt. Der Score ersetzt weder Codeprüfung noch eigene Tests.

Beispiel: Plugin auswählen

Zwei WordPress-Plugins erfüllen dieselbe Aufgabe. Plugin A wurde zuletzt vor drei Jahren aktualisiert, hat keinen Meldeweg für Schwachstellen und viele Abhängigkeiten. Plugin B wird regelmäßig gepflegt, veröffentlicht Änderungen mit nachvollziehbaren Hinweisen und hat eine security.txt. Die Wahl fällt auf B, auch wenn A ein paar Funktionen mehr bietet.

Weniger Abhängigkeiten sind besser als besser bewertete Abhängigkeiten.

Zum Selbermachen

1. Liste die zehn wichtigsten Abhängigkeiten eines Projekts auf und notiere Datum der letzten Version und den Meldeweg für Schwachstellen.
2. Aktiviere für ein Projekt einen automatischen Update-Hinweis und prüfe die ersten Vorschläge.

Verwandte Themen

Open Source → „SBOM und SLSA“ und „Schwachstellen verstehen und melden“. WordPress → „WordPress-Plugin-Deepdive“. Lieferkette → „XZ Utils und CRA“.

Prüfstatus: Belegt (Stand 1. Oktober 2026): Die OpenSSF Scorecard (Vorstellung im November 2020, Bewertung 0–10, die Prüfungen Branch-Protection, Dependency-Update-Tool und Pinned-Dependencies) wurde gegen OpenSSF-Seiten und Fachbeiträge geprüft. Nicht einzeln belegt: die Zahl von 18 Kriterien (nur aus einer Fachpublikation; die Zahl kann sich mit neuen Versionen ändern), die Pflegeliste (Einordnung in eigenen Worten) und das Pluginbeispiel (konstruiert).

Quellen

• OpenSSF – „Security Scorecards for Open Source Projects“ (6. November 2020) und scorecard.dev
• OpenSSF Scorecard: „On the Path Toward Ecosystem-wide Automated Security Metrics“ (arXiv 2208.03412)