Zusammenfassung

  • OpenSSF Scorecard bewertet ausgewählte automatisierte Prüfungen mit null bis zehn Punkten und bildet daraus einen risikogewichteten Gesamtwert.
  • Das Projekt beschreibt die Prüfungen selbst als Heuristiken mit Fehlalarmen und Übersehungen und lehnt den Anspruch eines allgemeinen Endurteils ab.
  • Ein Scan kann eine Abhängigkeitsprüfung strukturieren, bestimmt aber weder die konkrete verwendete Version noch Risikotoleranz, Ausnahme, Zuständigkeit oder Reaktion des Verbrauchers.

Der richtige Nutzen einer begrenzten Messung

OpenSSF Scorecard liest bestimmte, automatisierbar sichtbare Signale eines Repositorys und ordnet sie einzelnen Prüfungen zu. Das hilft Maintainerinnen und Maintainers bei Verbesserungen und Nutzern freier Software bei der Frage, welche Abhängigkeitsrisiken näher untersucht werden sollten. Es ist kein Urteil darüber, dass eine Software sicher sei oder für einen bestimmten Einsatz freigegeben werde.

Die Dokumentation setzt diese Grenze selbst. Auswahl, Gewichtung und Berechnung der Checks beruhen auf Wertungen. Heuristiken können falsch-positive und falsch-negative Ergebnisse liefern. Scorecard will weder einen abschließenden Bericht noch eine für jedes Projekt passende Pflicht sein. Der Gesamtwert verrät nicht, welche einzelnen Verhaltensweisen ihn erzeugten; dieselbe Zahl kann aus unterschiedlichen Prüfbildern entstehen und sich bei veränderten Heuristiken verschieben.

Gerade deshalb ist die Zahl brauchbar. Sie beschreibt eine definierte Beobachtung eines Ziels zu einem Zeitpunkt mit den verfügbaren Daten. Sie beschreibt nicht automatisch alle Quellstände, keine vollständige Lieferkette und keine reale Betriebsumgebung eines anderen Unternehmens.

Ein Mittelwert übernimmt keine Verantwortlichkeit

Ein einzelner Wert lässt sich leicht in Dashboards, Badges und Lieferantenlisten übernehmen. Daraus entsteht schnell eine scheinbar objektive Freigabeschwelle. Doch der Gesamtwert ist ein gewichteter Durchschnitt von Checks unterschiedlicher Art. Zwei Projekte können denselben Wert erreichen, obwohl bei dem für einen konkreten Einsatz wichtigen Check gegensätzliche Befunde vorliegen.

Die Check-Dokumentation macht die Beschränkung sichtbar. Maintained nutzt beobachtbare Aktivität in einem begrenzten Zeitraum und sagt zugleich, dass geringe Aktivität nicht zwingend ein Risiko bedeutet. SBOM sucht nach einer Komponentenliste an festgelegten Stellen in Quelle, Pipeline oder Release. Ein Fund belegt das Vorhandensein einer Liste, nicht deren Vollständigkeit, Aktualität für ein ausgeliefertes Binärartefakt oder Eignung für die Expositionsanalyse eines Nutzers.

Auch der Beobachtungsweg gehört zum Ergebnis. Öffentliche wöchentliche Scans haben einen angegebenen Umfang; die API lässt bei großem Maßstab einzelne Checks aus; ein Lauf mit anderem Zugriff kann andere Belege sehen. Aufgelöste Referenz, Zeitpunkt, Werkzeugversion, Datenzugang, Einzelwerte und Details müssen neben der Zahl erhalten bleiben. Sonst wird ein heutiger Wert fälschlich zum Nachweis eines früheren Releases oder eines anderen Artefakts.

Eine Anmerkung erklärt, sie verifiziert nicht

Ein niedriger Wert beweist weder eine Schwachstelle noch Nachlässigkeit, einen Angriff oder aufgegebene Wartung. Er sagt lediglich, dass eine bestimmte automatische Prüfung das erwartete Signal nicht fand. Scorecard weist ausdrücklich darauf hin, dass eine Praxis vorhanden sein kann, ohne erkannt zu werden.

Die Maintainer-Anmerkungen erlauben Kontext etwa mit test-data, remediated, not-applicable, not-supported und not-detected. Das kann eine unvollständige Beobachtung verständlicher machen. Es bleibt jedoch eine Erklärung der Maintainer, keine unabhängige Prüfung und keine Anweisung an jede nutzende Organisation, die Abhängigkeit zu akzeptieren.

Getrennt bleiben müssen daher drei Aufzeichnungen: die Messung des Werkzeugs, die Kontextangabe der Maintainer und die Entscheidung des Verbrauchers. Letztere betrifft ein konkretes Paket, einen Commit oder ein Build-Artefakt sowie Privilegien, Datenpfade, Alternativen, Kompensationsmaßnahmen, Entscheidungsverantwortung und Frist.

Die Entscheidung liegt beim Betreiber

Eine Organisation kann ein Release-Paket, einen festgeschriebenen Commit, einen internen Spiegel oder ein eigenes Build-Artefakt einsetzen. Sie kann ihm andere Rechte und Daten zugänglich machen als andere Nutzer. Sie kann eine befristete Ausnahme akzeptieren, isolieren, überwachen, weitere Nachweise verlangen, ersetzen oder auf die Nutzung verzichten. Keine dieser Handlungen ist das Ergebnis eines gewichteten Durchschnitts.

Ein schlanker Scan-zu-Abhängigkeitsnachweis hält die Rollen auseinander. Der Messteil nennt Repository und aufgelöste Referenz, Scorecard-Version und Scanzeit, Datenbeschränkungen, Gesamtwert, relevante Einzelchecks, Details und Anmerkungen. Der Entscheidungsteil nennt das konkrete Paket oder Release, den Nutzungskontext, weitere Belege, die zuständige Person, die Schwelle oder Ausnahmebegründung, die gewählte Maßnahme und den nächsten Prüfimpuls.

Das macht aus Scorecard kein Zertifizierungssystem. Es verhindert nur, dass eine Beobachtung unbemerkt die Autorität einer lokalen Entscheidung übernimmt.

Quellen

  1. OpenSSF Scorecard README
  2. OpenSSF Scorecard Check-Dokumentation
  3. OpenSSF Scorecard Maintainer-Anmerkungen