OpenSSF Scorecard

Die OpenSSF Scorecard ist ein branchenüblicher Satz automatisierter Checks, der die Sicherheitslage eines Open-Source-Repositorys bewertet. fremforge führt sie wöchentlich für jedes Repository deiner Organisation aus und zeigt das Ergebnis als Spalte unter /<org>/_admin/repos-overview an.

Die Checks

Die Checks der Scorecard decken Build-Sicherheit, den Umgang mit Schwachstellen und die Reife eines Projekts ab. Die wichtigsten:

• Branch-Protection: Ist der Standard-Branch mit erforderlichen Reviews und Status-Checks geschützt?
• Code-Review: Welcher Anteil der letzten Merges hatte ein Code-Review?
• Pinned-Dependencies: Sind die CI-Abhängigkeiten auf bestimmte Versionen oder SHAs festgelegt?
• Token-Permissions: Nutzt die CI Token mit minimalen Rechten?
• Signed-Releases: Sind Release-Artefakte kryptografisch signiert?
• SAST: Führt das Projekt in der CI eine statische Analyse aus?
• Vulnerabilities: Enthält der Abhängigkeitsbaum bekannte CVEs?
• Maintained: Gibt es im Repository aktuelle Commits oder Aktivität bei Issues?

Jeder Check liefert einen Wert von 0 bis 10. Der Gesamtwert ist der gewichtete Durchschnitt. Eine glatte 10 ist selten; „gut" liegt im Bereich 7 bis 9.

Wie fremforge sie ausführt

Die Scorecard ist kein CI-Workflow pro Repository. Sie läuft wöchentlich auf isolierter Plattform-Infrastruktur: Es landet keine Workflow-Datei in deinen Repositorys, und du verbrauchst dafür keine Runner-Minuten. So funktioniert es:

1. Einmal pro Woche stellt fremforge jeden aktiven Mandanten für einen Scan in die Warteschlange. Mandanten mit einem laufenden Durchlauf werden übersprungen.
2. Ein Scan wird von einem schreibgeschützten Bot pro Mandant ausgeführt, der deine Repositorys lesen, aber nicht in sie schreiben kann.
3. Der Scan listet die Repositorys des Mandanten auf und vergleicht den aktuellen HEAD des Standard-Branches jedes Repositorys mit dem HEAD, der beim letzten Scan erfasst wurde. Repositorys, deren HEAD sich nicht bewegt hat, werden übersprungen: Der Wert kann sich nicht geändert haben, also gibt es nichts neu zu berechnen.
4. Jedes geänderte Repository klont der Scan flach in ein temporäres Arbeitsverzeichnis auf isolierter Plattform-Infrastruktur, führt die Binärdatei scorecard --local gegen den lokalen Checkout aus und speichert das resultierende Ergebnis-JSON (einschließlich der neuen HEAD-Referenz).
5. Durchläufe, die nach dem Absturz eines Workers hängen geblieben sind, werden in einen fehlgeschlagenen Zustand zurückgesetzt, sodass der Mandant beim nächsten wöchentlichen Lauf wieder in die Warteschlange kommt.

fremforge speichert das Ergebnis pro (tenant, repo) und zeigt den Gesamtwert als Spalte auf der Seite Repos (/<org>/_admin/repos-overview). Klicke auf eine Zeile, um die Details pro Check zu sehen.

Die Ingest-API /scorecard/results gibt es weiterhin für Ergebnisse, die extern oder aus einem Workflow gepusht werden, aber sie ist nicht mehr der Standardweg; das ist der oben beschriebene wöchentliche Scan auf Plattformseite.

Den Wert einordnen

Der Wert ist ein Richtungssignal, kein Compliance-Gate. Ein Repository mit einem Wert von 6,5, das eine gepflegte Bibliothek mit Branch-Schutz und SAST enthält, steht deutlich besser da als ein Repository mit dem Wert 8, das zufällig bei kosmetischen Checks gut abschneidet.

Wir raten davon ab, „Scorecard-Wert < X" in eine Regel einzubauen, die Merges blockiert. Die richtige Stelle für ein solches Gate ist:

• Branch-Protection schlägt fehl: Behebe das unter /<org>/_admin/security/policies/repository-rules#org-baseline (bereits ein eigenes Signal).
• SAST schlägt fehl: Sieh unter /<org>/_admin/code-security nach (bereits ein eigenes Signal).

Nutze die Scorecard, um die Lücke zwischen ähnlichen Repositorys zu betrachten: Wenn acme/api 8,5 erreicht und acme/web 6,5, wo liegt die Lücke, und ist sie gewollt?

Wo der Scan läuft: Hinweis zur Datenresidenz

Die Scorecard-Binärdatei selbst ist Open Source (Apache-2.0). Der Scan läuft auf isolierter, netzwerkseitig abgeschotteter Plattform-Infrastruktur von fremforge (T Cloud Public, eu-de), nicht auf deinen CI-Runnern. Er wird von einem schreibgeschützten Bot pro Mandant ausgeführt, der deine Repositorys lesen, aber nicht in sie schreiben kann.

Was das für deine Daten bedeutet:

• Der Klon ist temporär. Der Scan klont jedes geänderte Repository flach in ein temporäres Arbeitsverzeichnis, führt scorecard --local gegen diesen lokalen Checkout aus und löscht das Arbeitsverzeichnis, wenn der Durchlauf endet. Der Quellcode wird nie dauerhaft gespeichert und verlässt die Plattform nie ins öffentliche Internet: Der Bot holt ihn über das interne Netz aus dem eigenen Forgejo deines Mandanten, und die Scorecard-Binärdatei läuft mit --local (keine ausgehenden Aufrufe an APIs nach Art von GitHub für die Checks, die wir ausführen).
• Nur das JSON mit den Check-Ergebnissen wird aufbewahrt. Pro (tenant, repo) speichern wir die Werte pro Check und die gescannte HEAD-Referenz: keinen Quellcode, keine Dateiinhalte, keine Ausschnitte aus Commits.
• Es bleibt in eu-de. Sowohl der Klon als auch der Scan laufen innerhalb der in der EU betriebenen Plattform, im Einklang mit dem Grundsatz von fremforge, keine US-Unterauftragsverarbeiter einzusetzen.

Das ist eine Änderung gegenüber dem früheren Modell, in dem die Scorecard als Workflow auf deinen eigenen CI-Runnern lief. Der Scan läuft jetzt auf der Infrastruktur von fremforge; die oben beschriebene Datenresidenz und der schreibgeschützte Bot sind die Mittel, mit denen wir diese Grenze eng halten.

Siehe auch

• Branch-Schutz: bestimmt den Branch-Protection-Wert.
• SBOMs: bestimmt die Werte für Dependencies und Vulnerabilities.