Sicherheitslage misst sichtbare Sicherheitshygiene, gestützt auf die OpenSSF Scorecard — den neutralen, versionierten, werkzeugneutralen Sicherheitsstandard der Open Source Security Foundation. Sie liefert den Basiswert der Kategorie Sicherheit, die 16% des Index trägt; das Exposition gegenüber Hochrisikojurisdiktionen kann ihn nur über den veröffentlichten Richtlinienmultiplikator reduzieren.
- Kategorie: Sicherheit (Basis vor dem Multiplikator)
- Gewicht im Gesamtindex: 16% vor der Jurisdiktionsrichtlinien-Anpassung
- Metrikschlüssel:
security_posture
Wie der Wert berechnet wird
Jeder Scorecard-Check wird zu einer Komponente, gewichtet nach Scorecards eigener Risikostufe:
| Scorecard-Risikostufe | Komponentengewicht |
|---|---|
| Kritisch | 10 |
| Hoch | 7,5 |
| Mittel | 5 |
| Niedrig | 2,5 |
Der aggregierte 1–100-Wert folgt daher Scorecards 0–10-Gesamtwert (value ≈ aggregate × 10). Checks, die Scorecard als ergebnislos meldet — etwa Branch-Protection ohne Admin-Token — werden ausgeschlossen und renormalisiert, niemals als null gewertet. Diese Regel verhindert, dass gut geführte Projekte mit Tooling außerhalb von GitHub nahe null gelesen werden; sie ist in den Methodikversionen (0.6.0) dokumentiert.
Jeder Bericht stellt die vollständige Aufschlüsselung je Check dar — Wert, Begründung und ein Link zur Scorecard-Dokumentation für jeden Check.
Geteilte Evidenz
Die Sicherheit behält das vollständige risikogewichtete Scorecard-Ergebnis. Sieben Checks belegen zusätzlich andere Gesundheitsdimensionen. Sechs liefern dort kleine, separat gewichtete OpenSSF Scorecard: …-Komponenten: Maintained, Signed-Releases, Contributors, Code-Review, CI-Tests und Pinned-Dependencies. Der siebte, License, ist das einzige Lizenzsignal in der Community-Gesundheit — dort generisch als License dargestellt, mit einem Fallback auf GitHubs Community-Profil, wenn keine Scorecard verfügbar ist. Dies ist beabsichtigter kategorienübergreifender Einfluss, keine Wiederverwendung der Sicherheitsrisiko-Gewichte von Scorecard. Ergebnislose (n/a) Checks bleiben überall ausgeschlossen.
Was die Checks belohnen
Die Praktik, nie die Konfigurationsdatei eines Anbieters:
- Automatisierte Abhängigkeitsaktualisierung — Dependabot, Renovate oder jedes anerkannte Werkzeug.
- Statische Analyse (SAST) — CodeQL, Semgrep oder Gleichwertiges.
- Keine bekannten verwundbaren Abhängigkeiten — der Check mit dem höchsten Risiko.
- Workflow-Tokens mit minimalen Rechten, gepinnte Abhängigkeiten, signierte Releases, eine Sicherheitsrichtlinie und mehr.
Der Fallback-Pfad
Scorecard benötigt seine CLI; ist sie nicht verfügbar, greift die Metrik auf grobe Dateibaum-Signale zurück, und der Bericht kennzeichnet die Quelle ausdrücklich (inputs.source == "file_signals"):
| Fallback-Komponente | Gewicht | Anmerkung |
|---|---|---|
| Sicherheitsrichtlinie (SECURITY.md) | 30 | |
| Dependabot-Konfiguration | 25 | |
| Abhängigkeits-Lockdateien | 25 | nur Anwendungen — Bibliotheken veröffentlichen konventionsgemäß ohne eingecheckte Lockdatei, daher wird der Check für sie ausgeschlossen (siehe 0.9.0) |
| CodeQL-Workflow | 20 |
Das Ergebnis lesen
- Den Gesamtwert mit der Tabelle je Check vergleichen: Ein mittlerer Wert mit einem fehlgeschlagenen kritischen Check ist eine andere Lage als gleichförmige Mittelmäßigkeit.
n/a-Zeilen sind ergebnislose Checks — ausgeschlossen, nicht fehlgeschlagen.
Den Wert verbessern
SECURITY.mdveröffentlichen, automatisierte Abhängigkeitsaktualisierungen aktivieren und einen SAST-Workflow ergänzen.- Bekannte verwundbare Abhängigkeiten zuerst beheben — höchstes Risikogewicht, höchster realer Nutzen.
- Explizite minimale Berechtigungen für CI-Workflows setzen und Drittanbieter-Actions pinnen.
Verwandt: Sicherheit · Methodikversionen