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. Ein veröffentlichtes Paket, dessen Manifest eine ausführbare Datei erklärt, zählt als Anwendung und behält die Erwartung (siehe die Software-Klassifikation und Metrik 2.5.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