scorecard
v5.0.0
Wir haben Scorecard entwickelt, um Open-Source-Betreuern dabei zu helfen, ihre Best Practices für die Sicherheit zu verbessern und Open-Source-Konsumenten dabei zu helfen, zu beurteilen, ob ihre Abhängigkeiten sicher sind.
Scorecard ist ein automatisiertes Tool, das eine Reihe wichtiger Heuristiken („Prüfungen“) im Zusammenhang mit der Softwaresicherheit bewertet und jeder Prüfung eine Punktzahl von 0–10 zuweist. Mithilfe dieser Bewertungen können Sie bestimmte Bereiche erkennen, in denen Verbesserungen erforderlich sind, um die Sicherheitslage Ihres Projekts zu stärken. Sie können auch die Risiken bewerten, die Abhängigkeiten mit sich bringen, und fundierte Entscheidungen darüber treffen, diese Risiken zu akzeptieren, alternative Lösungen zu bewerten oder mit den Betreuern zusammenzuarbeiten, um Verbesserungen vorzunehmen.
Die Inspiration für das Scorecard-Logo: „Du hast bestanden! Alle D's ... und eine A!“
Automatisieren Sie Analysen und Vertrauensentscheidungen zum Sicherheitsstatus von Open-Source-Projekten.
Nutzen Sie diese Daten, um die Sicherheitslage der kritischen Projekte, von denen die Welt abhängt, proaktiv zu verbessern.
Als Messinstrument für bestehende Richtlinien fungieren
Wenn OSS-Konsumenten bestimmte Verhaltensweisen aus ihren Abhängigkeiten erfordern, kann Scorecard verwendet werden, um diese zu messen. Mit der V5-Version sehen wir strukturierte Ergebnisse als eine Möglichkeit, dies zu erreichen, wenn eine unterstützte Analyse vorhanden ist. Anstatt archived auf eine Gesamtbewertung von Die OpenSSF verfolgt diesen Ansatz mit einer eigenen Security Baseline für Projekte.
Es handelt sich um einen endgültigen Bericht oder eine Anforderung, die alle Projekte befolgen sollten.
Scorecard ist nicht als Einheitslösung gedacht. Jeder Schritt bei der Erstellung unserer Ergebnisse basiert auf einer Meinung: Welche Prüfungen werden einbezogen oder ausgeschlossen, welche Bedeutung hat jede Prüfung und wie werden die Ergebnisse berechnet? Die Prüfungen selbst sind Heuristiken; Es gibt falsch-positive und falsch-negative Ergebnisse.
Ob aus Gründen der Anwendbarkeit, der Machbarkeit oder einer Meinungssache: Was in den Scorecard-Ergebnissen enthalten oder ausgeschlossen ist, führt zu vielen Diskussionen. Es ist unmöglich, eine Scorecard zu erstellen, die alle zufriedenstellt, da sich unterschiedliche Zielgruppen für unterschiedliche Teilbereiche des Verhaltens interessieren.
Insbesondere die aggregierten Bewertungen sagen Ihnen nichts darüber, welche individuellen Verhaltensweisen ein Repository zeigt oder nicht. Viele Prüfergebnisse werden zu einem einzigen Ergebnis zusammengefasst, und es gibt mehrere Möglichkeiten, zum gleichen Ergebnis zu gelangen. Diese Bewertungen ändern sich, wenn wir neue Heuristiken hinzufügen oder die vorhandenen verfeinern.
Scorecard wurde in Tausenden von Projekten eingesetzt, um Sicherheitsmetriken zu überwachen und zu verfolgen. Zu den prominenten Projekten, die Scorecard verwenden, gehören:
Navigieren Sie zum Webviewer, um die Ergebnisse für Projekte anzuzeigen, die regelmäßig von Scorecard gescannt werden. Sie können auch den Platzhaltertext (Plattform, Benutzer/Organisation und Repository-Name) im folgenden Vorlagenlink ersetzen, um einen benutzerdefinierten Scorecard-Link für ein Repo zu generieren: https://scorecard.dev/viewer/?uri=<github_or_gitlab>.com/<user_name_or_org>/<repository_name>
Zum Beispiel:
Um Ergebnisse für Projekte anzuzeigen, die nicht im Webviewer enthalten sind, verwenden Sie die Scorecard-CLI.
Wir führen wöchentlich einen Scorecard-Scan der 1 Million kritischsten Open-Source-Projekte durch, beurteilt nach ihren direkten Abhängigkeiten, und veröffentlichen die Ergebnisse in einem öffentlichen BigQuery-Datensatz.
Diese Daten sind im öffentlichen BigQuery-Datensatz openssf:scorecardcron.scorecard-v2 verfügbar. Die neuesten Ergebnisse sind in der BigQuery-Ansicht openssf:scorecardcron.scorecard-v2_latest verfügbar.
Sie können die Daten mit BigQuery Explorer abfragen, indem Sie zu Daten hinzufügen > Projekt nach Namen markieren > „openssf“ navigieren. Es könnte Sie beispielsweise interessieren, wie sich die Punktzahl eines Projekts im Laufe der Zeit verändert hat:
SELECT date , score FROM ` openssf.scorecardcron.scorecard-v2 ` WHERE repo . name = " github.com/ossf/scorecard " ORDER BY date ASC Mit dem bq -Tool können Sie die neuesten Ergebnisse im JSON-Format in den Google Cloud-Speicher extrahieren:
# Get the latest PARTITION_ID
bq query --nouse_legacy_sql 'SELECT partition_id FROM
openssf.scorecardcron.INFORMATION_SCHEMA.PARTITIONS WHERE table_name="scorecard-v2"
AND partition_id!="__NULL__" ORDER BY partition_id DESC
LIMIT 1'
# Extract to GCS
bq extract --destination_format=NEWLINE_DELIMITED_JSON
'openssf:scorecardcron.scorecard-v2$<partition_id>' gs://bucket-name/filename-*.json
Die Liste der überprüften Projekte ist in der Datei cron/internal/data/projects.csv in diesem Repository verfügbar. Wenn Sie möchten, dass wir mehr verfolgen, können Sie gerne gemeinsam mit anderen eine Pull-Anfrage senden. Derzeit wird diese Liste NUR von Projekten abgeleitet, die auf GitHub gehostet werden . Wir planen, sie in naher Zukunft zu erweitern, um Projekte zu berücksichtigen, die auf anderen Versionsverwaltungssystemen gehostet werden.
Der einfachste Weg, Scorecard für GitHub-Projekte zu verwenden, die Sie besitzen, ist die Scorecard-GitHub-Aktion. Die Aktion wird bei jeder Repository-Änderung ausgeführt und gibt Warnungen aus, die Betreuer auf der Registerkarte „Sicherheit“ des Repositorys anzeigen können. Weitere Informationen finden Sie in den Installationsanweisungen für Scorecard GitHub Action.
Um vorberechnete Scores von OSS-Projekten abzufragen, verwenden Sie die REST-API.
Damit Ihr Projekt auf der REST-API verfügbar ist, legen Sie publish_results: true in der Scorecard-GitHub-Aktionseinstellung fest.
Die von der REST-API bereitgestellten Daten sind unter CDLA Permissive 2.0 lizenziert.
Durch die Aktivierung von publish_results: true in Scorecard-GitHub-Aktionen können Betreuer außerdem ein Scorecard-Badge in ihrem Repository anzeigen, um ihre harte Arbeit zu zeigen. Dieses Abzeichen wird außerdem bei jeder am Repository vorgenommenen Änderung automatisch aktualisiert. Weitere Details finden Sie in diesem OSSF-Blogpost.
Um ein Abzeichen in das Repository Ihres Projekts aufzunehmen, fügen Sie einfach den folgenden Markdown zu Ihrer README-Datei hinzu:
[](https://scorecard.dev/viewer/?uri=github.com/{owner}/{repo})
Um einen Scorecard-Scan für Projekte auszuführen, die Ihnen nicht gehören, verwenden Sie die Installationsoption der Befehlszeilenschnittstelle.
Plattformen: Derzeit unterstützt Scorecard OSX- und Linux-Plattformen. Wenn Sie ein Windows-Betriebssystem verwenden, können Probleme auftreten. Beiträge zur Unterstützung von Windows sind willkommen.
Sprache: Sie müssen GoLang installiert haben, um Scorecard auszuführen (https://golang.org/doc/install)
scorecard ist als Docker-Container verfügbar:
docker pull gcr.io/openssf/scorecard:stableUm eine bestimmte Scorecard-Version (z. B. v3.2.1) zu verwenden, führen Sie Folgendes aus:
docker pull gcr.io/openssf/scorecard:v3.2.1So installieren Sie Scorecard als eigenständiges Gerät:
Besuchen Sie unsere Seite mit den neuesten Veröffentlichungen und laden Sie die richtige ZIP-Datei für Ihr Betriebssystem herunter.
Fügen Sie die Binärdatei Ihrem GOPATH/bin -Verzeichnis hinzu (verwenden Sie go env GOPATH um Ihr Verzeichnis bei Bedarf zu identifizieren).
Während des Veröffentlichungsprozesses generieren wir SLSA3-Signaturen mithilfe des slsa-framework/slsa-github-generators von OpenSSF. So überprüfen Sie eine Release-Binärdatei:
attestation.intoto.jsonl von der GitHub-Release-Seite herunter.slsa-verifier -artifact-path < the-zip > -provenance attestation.intoto.jsonl -source github.com/ossf/scorecard -tag < the-tag > | Paketmanager | Unterstützte Verteilung | Befehl |
|---|---|---|
| Nix | NixOS | nix-shell -p nixpkgs.scorecard |
| AUR-Helfer | Arch Linux | Verwenden Sie Ihren AUR-Helfer, um scorecard zu installieren |
| Homebrew | macOS oder Linux | brew install scorecard |
GitHub legt API-Ratenbeschränkungen für nicht authentifizierte Anfragen fest. Um diese Einschränkungen zu vermeiden, müssen Sie Ihre Anfragen authentifizieren, bevor Sie Scorecard ausführen. Es gibt zwei Möglichkeiten, Ihre Anfragen zu authentifizieren: entweder ein persönliches GitHub-Zugriffstoken erstellen oder eine GitHub-App-Installation erstellen.
public_repo zu wählen. Legen Sie das Token in einer Umgebungsvariablen namens GITHUB_AUTH_TOKEN , GITHUB_TOKEN , GH_AUTH_TOKEN oder GH_TOKEN fest, indem Sie die folgenden Befehle entsprechend Ihrer Plattform verwenden. # For posix platforms, e.g. linux, mac:
export GITHUB_AUTH_TOKEN= < your access token >
# Multiple tokens can be provided separated by comma to be utilized
# in a round robin fashion.
export GITHUB_AUTH_TOKEN= < your access token 1> , < your access token 2>
# For windows:
set GITHUB_AUTH_TOKEN= < your access token >
set GITHUB_AUTH_TOKEN= < your access token 1> , < your access token 2>ODER
set oder export ) folgen. GITHUB_APP_KEY_PATH=<path to the key file on disk>
GITHUB_APP_INSTALLATION_ID=<installation id>
GITHUB_APP_ID=<app id>
Diese Variablen können von der GitHub-Entwicklereinstellungsseite abgerufen werden.
Scorecard kann mit nur einem Argument ausgeführt werden, der URL des Ziel-Repositorys:
$ scorecard --repo=github.com/ossf-tests/scorecard-check-branch-protection-e2e
Starting [CII-Best-Practices]
Starting [Fuzzing]
Starting [Pinned-Dependencies]
Starting [CI-Tests]
Starting [Maintained]
Starting [Packaging]
Starting [SAST]
Starting [Dependency-Update-Tool]
Starting [Token-Permissions]
Starting [Security-Policy]
Starting [Signed-Releases]
Starting [Binary-Artifacts]
Starting [Branch-Protection]
Starting [Code-Review]
Starting [Contributors]
Starting [Vulnerabilities]
Finished [CI-Tests]
Finished [Maintained]
Finished [Packaging]
Finished [SAST]
Finished [Signed-Releases]
Finished [Binary-Artifacts]
Finished [Branch-Protection]
Finished [Code-Review]
Finished [Contributors]
Finished [Dependency-Update-Tool]
Finished [Token-Permissions]
Finished [Security-Policy]
Finished [Vulnerabilities]
Finished [CII-Best-Practices]
Finished [Fuzzing]
Finished [Pinned-Dependencies]
RESULTS
-------
Aggregate score: 7.9 / 10
Check scores:
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
| SCORE | NAME | REASON | DOCUMENTATION/REMEDIATION |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
| 10 / 10 | Binary-Artifacts | no binaries found in the repo | github.com/ossf/scorecard/blob/main/docs/checks.md#binary-artifacts |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
| 9 / 10 | Branch-Protection | branch protection is not | github.com/ossf/scorecard/blob/main/docs/checks.md#branch-protection |
| | | maximal on development and all | |
| | | release branches | |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
| ? | CI-Tests | no pull request found | github.com/ossf/scorecard/blob/main/docs/checks.md#ci-tests |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
| 0 / 10 | CII-Best-Practices | no badge found | github.com/ossf/scorecard/blob/main/docs/checks.md#cii-best-practices |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
| 10 / 10 | Code-Review | branch protection for default | github.com/ossf/scorecard/blob/main/docs/checks.md#code-review |
| | | branch is enabled | |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
| 0 / 10 | Contributors | 0 different companies found -- | github.com/ossf/scorecard/blob/main/docs/checks.md#contributors |
| | | score normalized to 0 | |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
| 0 / 10 | Dependency-Update-Tool | no update tool detected | github.com/ossf/scorecard/blob/main/docs/checks.md#dependency-update-tool |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
| 0 / 10 | Fuzzing | project is not fuzzed in | github.com/ossf/scorecard/blob/main/docs/checks.md#fuzzing |
| | | OSS-Fuzz | |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
| 1 / 10 | Maintained | 2 commit(s) found in the last | github.com/ossf/scorecard/blob/main/docs/checks.md#maintained |
| | | 90 days -- score normalized to | |
| | | 1 | |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
| ? | Packaging | no published package detected | github.com/ossf/scorecard/blob/main/docs/checks.md#packaging |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
| 8 / 10 | Pinned-Dependencies | unpinned dependencies detected | github.com/ossf/scorecard/blob/main/docs/checks.md#pinned-dependencies |
| | | -- score normalized to 8 | |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
| 0 / 10 | SAST | no SAST tool detected | github.com/ossf/scorecard/blob/main/docs/checks.md#sast |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
| 0 / 10 | Security-Policy | security policy file not | github.com/ossf/scorecard/blob/main/docs/checks.md#security-policy |
| | | detected | |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
| ? | Signed-Releases | no releases found | github.com/ossf/scorecard/blob/main/docs/checks.md#signed-releases |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
| 10 / 10 | Token-Permissions | tokens are read-only in GitHub | github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions |
| | | workflows | |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
| 10 / 10 | Vulnerabilities | no vulnerabilities detected | github.com/ossf/scorecard/blob/main/docs/checks.md#vulnerabilities |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- | Der GITHUB_AUTH_TOKEN muss auf einen gültigen Token gesetzt werden
docker run -e GITHUB_AUTH_TOKEN=token gcr.io/openssf/scorecard:stable --show-details --repo=https://github.com/ossf/scorecardUm eine bestimmte Scorecard-Version (z. B. v3.2.1) zu verwenden, führen Sie Folgendes aus:
docker run -e GITHUB_AUTH_TOKEN=token gcr.io/openssf/scorecard:v3.2.1 --show-details --repo=https://github.com/ossf/scorecard Für weitere Details darüber, warum eine Prüfung fehlschlägt, verwenden Sie die Option --show-details :
./scorecard --repo=github.com/ossf-tests/scorecard-check-branch-protection-e2e --checks Branch-Protection --show-details
Starting [Pinned-Dependencies]
Finished [Pinned-Dependencies]
RESULTS
-------
|---------|------------------------|--------------------------------|--------------------------------|---------------------------------------------------------------------------|
| SCORE | NAME | REASON | DETAILS | DOCUMENTATION/REMEDIATION |
|---------|------------------------|--------------------------------|--------------------------------|---------------------------------------------------------------------------|
| 9 / 10 | Branch-Protection | branch protection is not | Info: 'force pushes' disabled | github.com/ossf/scorecard/blob/main/docs/checks.md#branch-protection |
| | | maximal on development and all | on branch 'main' Info: 'allow | |
| | | release branches | deletion' disabled on branch | |
| | | | 'main' Info: linear history | |
| | | | enabled on branch 'main' Info: | |
| | | | strict status check enabled | |
| | | | on branch 'main' Warn: status | |
| | | | checks for merging have no | |
| | | | specific status to check on | |
| | | | branch 'main' Info: number | |
| | | | of required reviewers is 2 | |
| | | | on branch 'main' Info: Stale | |
| | | | review dismissal enabled on | |
| | | | branch 'main' Info: Owner | |
| | | | review required on branch | |
| | | | 'main' Info: 'administrator' | |
| | | | PRs need reviews before being | |
| | | | merged on branch 'main' | |
|---------|------------------------|--------------------------------|--------------------------------|---------------------------------------------------------------------------|
Mit Betreueranmerkungen können Betreuer Kontext hinzufügen, der zusammen mit den Ergebnissen der Scorecard-Prüfung angezeigt wird. Anmerkungen können Benutzern zusätzliche Informationen liefern, wenn Scorecard eine unvollständige Bewertung der Sicherheitspraktiken eines Projekts hat. Um die Anmerkungen des Betreuers für jede Prüfung anzuzeigen, verwenden Sie die Option --show-annotations .
Weitere Informationen zu verfügbaren Anmerkungen oder zum Erstellen von Anmerkungen finden Sie im Konfigurationsdokument.
Um Scorecard in einem GitLab-Repository auszuführen, müssen Sie ein GitLab-Zugriffstoken mit den folgenden Berechtigungen erstellen:
read_apiread_userread_repository Sie können Scorecard in einem GitLab-Repository ausführen, indem Sie die Umgebungsvariable GITLAB_AUTH_TOKEN festlegen:
export GITLAB_AUTH_TOKEN=glpat-xxxx
scorecard --repo gitlab.com/ < org > / < project > / < subproject >Ein Beispiel für die Verwendung von Scorecard in GitLab CI/CD finden Sie hier.
Während wir uns auf die Unterstützung von GitLab.com konzentrieren, funktioniert Scorecard auch mit selbst gehosteten GitLab-Installationen. Wenn Ihre Plattform in einer Subdomain gehostet wird (z. B. gitlab.foo.com ), sollte Scorecard sofort funktionieren. Wenn Ihre Plattform bei einem Slug gehostet wird (z. B. foo.com/bar/ ), müssen Sie die Umgebungsvariable GL_HOST festlegen.
export GITLAB_AUTH_TOKEN=glpat-xxxx
export GL_HOST=foo.com/bar
scorecard --repo foo.com/bar/ < org > / < project > Um einen GitHub Enterprise-Host github.corp.com zu verwenden, verwenden Sie die Umgebungsvariable GH_HOST .
# Set the GitHub Enterprise host without https prefix or slash with relevant authentication token
export GH_HOST=github.corp.com
export GITHUB_AUTH_TOKEN=token
scorecard --repo=github.corp.com/org/repo
# OR without github host url
scorecard --repo=org/repo Für Projekte in den Ökosystemen --npm , --pypi , --rubygems oder --nuget haben Sie die Möglichkeit, Scorecard mit einem Paketmanager auszuführen. Geben Sie den Paketnamen an, um die Prüfungen für den entsprechenden GitHub-Quellcode auszuführen.
Beispiel: --npm=angular .
Um nur bestimmte Prüfungen auszuführen, fügen Sie das Argument --checks mit einer Liste von Prüfnamen hinzu.
Beispiel: --checks=CI-Tests,Code-Review .
Die derzeit unterstützten Formate sind default (Text) und json .
Diese können mit dem Flag --format angegeben werden. Beispiel: --format=json .
Die folgenden Prüfungen werden standardmäßig alle für das Zielprojekt ausgeführt:
| Name | Beschreibung | Risikostufe | Token erforderlich | GitLab-Unterstützung | Notiz |
|---|---|---|---|---|---|
| Binäre Artefakte | Ist das Projekt frei von eingecheckten Binärdateien? | Hoch | PAT, GITHUB_TOKEN | Unterstützt | |
| Astschutz | Verwendet das Projekt Branch Protection? | Hoch | PAT ( repo oder repo> public_repo ), GITHUB_TOKEN | Unterstützt (siehe Hinweise) | Bestimmte Einstellungen werden nur mit einem Betreuer-PAT unterstützt |
| CI-Tests | Führt das Projekt Tests in CI durch, z. B. GitHub Actions, Prow? | Niedrig | PAT, GITHUB_TOKEN | Unterstützt | |
| CII-Best-Practices | Hat das Projekt ein OpenSSF (ehemals CII) Best Practices Badge auf der Stufe „Bestehen“, „Silber“ oder „Gold“ erhalten? | Niedrig | PAT, GITHUB_TOKEN | Validierung | |
| Code-Review | Führt das Projekt eine Codeüberprüfung durch, bevor der Code zusammengeführt wird? | Hoch | PAT, GITHUB_TOKEN | Validierung | |
| Mitwirkende | Hat das Projekt Mitwirkende aus mindestens zwei verschiedenen Organisationen? | Niedrig | PAT, GITHUB_TOKEN | Validierung | |
| Gefährlicher Workflow | Vermeidet das Projekt gefährliche Codierungsmuster in GitHub Action-Workflows? | Kritisch | PAT, GITHUB_TOKEN | Nicht unterstützt | |
| Abhängigkeits-Update-Tool | Verwendet das Projekt Tools, um seine Abhängigkeiten zu aktualisieren? | Hoch | PAT, GITHUB_TOKEN | Nicht unterstützt | |
| Fuzzing | Verwendet das Projekt Fuzzing-Tools, z. B. OSS-Fuzz, QuickCheck oder Fast-Check? | Medium | PAT, GITHUB_TOKEN | Validierung | |
| Lizenz | Erklärt das Projekt eine Lizenz? | Niedrig | PAT, GITHUB_TOKEN | Validierung | |
| Gepflegt | Ist das Projekt mindestens 90 Tage alt und wird gewartet? | Hoch | PAT, GITHUB_TOKEN | Validierung | |
| Angepinnte Abhängigkeiten | Deklariert und pinnen das Projekt Abhängigkeiten? | Medium | PAT, GITHUB_TOKEN | Validierung | |
| Verpackung | Erstellt und veröffentlicht das Projekt offizielle Pakete von CI/CD, z. B. GitHub Publishing? | Medium | PAT, GITHUB_TOKEN | Validierung | |
| SAST | Verwendet das Projekt statische Code-Analysetools, z. B. CodeQL, LGTM (veraltet), SonarCloud? | Medium | PAT, GITHUB_TOKEN | Nicht unterstützt | |
| Sicherheitspolitik | Enthält das Projekt eine Sicherheitsrichtlinie? | Medium | PAT, GITHUB_TOKEN | Validierung | |
| Signierte Veröffentlichungen | Signiert das Projekt Releases kryptografisch? | Hoch | PAT, GITHUB_TOKEN | Validierung | |
| Token-Berechtigungen | Deklariert das Projekt GitHub-Workflow-Tokens als schreibgeschützt? | Hoch | PAT, GITHUB_TOKEN | Nicht unterstützt | |
| Schwachstellen | Weist das Projekt nicht behobene Schwachstellen auf? Verwendet den OSV-Dienst. | Hoch | PAT, GITHUB_TOKEN | Validierung | |
| Webhooks | Verfügt der im Repository definierte Webhook über ein konfiguriertes Token zur Authentifizierung der Herkunft von Anforderungen? | Kritisch | Betreuer PAT ( admin: repo_hook oder admin> read:repo_hook doc | EXPERIMENTAL |
Detaillierte Informationen zu jeder Prüfung, ihren Bewertungskriterien und Abhilfemaßnahmen finden Sie auf der Dokumentationsseite der Prüfungen.
Eine Anleitung zu den Prüfungen, die Sie zu Beginn verwenden sollten, finden Sie im Leitfaden für Einsteiger zu Scorecard-Prüfungen.
Die Zwei-Faktor-Authentifizierung (2FA) bietet eine zusätzliche Sicherheitsebene beim Anmelden bei Websites oder Apps. 2FA schützt Ihr Konto, wenn Ihr Passwort kompromittiert wird, indem eine zweite Form der Authentifizierung erforderlich ist, z. B. Codes, die per SMS oder Authentifizierungs-App gesendet werden, oder die Berührung eines physischen Sicherheitsschlüssels.
Wir empfehlen Ihnen dringend, 2FA auf allen wichtigen Konten zu aktivieren, wo es verfügbar ist. 2FA ist keine Scorecard-Prüfung, da GitHub und GitLab diese Daten über Benutzerkonten nicht öffentlich machen. Diese Daten sollten wohl immer privat bleiben, da Konten ohne 2FA so anfällig für Angriffe sind.
Obwohl es sich nicht um eine offizielle Prüfung handelt, fordern wir alle Projektbetreuer dringend auf, 2FA zu aktivieren, um ihre Projekte vor Kompromittierung zu schützen.
Befolgen Sie die unter Zwei-Faktor-Authentifizierung konfigurieren beschriebenen Schritte
Wenn möglich, verwenden Sie entweder:
Als letzte Möglichkeit nutzen Sie SMS. Achtung: 2FA per SMS ist anfällig für SIM-Swap-Angriffe.
Jede einzelne Prüfung ergibt eine Punktzahl von 0 bis 10, wobei 10 die bestmögliche Punktzahl darstellt. Scorecard erstellt außerdem einen Gesamtscore, bei dem es sich um einen gewichteten Durchschnitt der einzelnen, nach Risiko gewichteten Schecks handelt.
Sehen Sie sich die Liste der aktuellen Scorecard-Prüfungen für die Risikostufe jeder Prüfung an.
Wenn Sie einen scheinbaren Fehler haben, nutzen Sie bitte das GitHub-Problemverfolgungssystem. Bevor Sie ein Problem melden, durchsuchen Sie bitte vorhandene Probleme, um festzustellen, ob Ihr Problem bereits abgedeckt ist.
Bevor Sie etwas beitragen, befolgen Sie bitte unseren Verhaltenskodex.
Anleitungen zum Mitwirken am Projekt finden Sie in der Dokumentation „Mitwirken“.
Wenn Sie einen Scheck hinzufügen möchten, lesen Sie bitte hier die Anleitung.
Wenn Sie sich in der Scorecard-Community engagieren möchten oder Ideen haben, über die Sie sich unterhalten möchten, besprechen wir dieses Projekt in den Sitzungen der OSSF Best Practices Working Group.
| Artefakt | Link |
|---|---|
| Scorecard-Entwicklerforum | ossf-scorecard-dev@ |
| Forum für Scorecard-Ankündigungen | ossf-scorecard-announce@ |
| Community-Treffen VC | Link zum Zoom-Meeting |
| Community-Treffenkalender | APAC-freundlich alle zwei Wochen donnerstags von 13:00 bis 14:00 Uhr pazifischer Zeit (öffentlicher OSSF-Kalender) Videoanruf: LFX-Zoom EMEA-freundlich Alle 4 Montagetage von 7:00 bis 8:00 Uhr pazifischer Zeit (öffentlicher OSSF-Kalender) Videoanruf: LFX-Zoom |
| Besprechungsnotizen | Notizen |
| Slack-Kanal | #Scorecard |
Betreuer sind in der CODEOWNERS-Datei aufgeführt.
Um ein Sicherheitsproblem zu melden, folgen Sie bitte den Anweisungen hier.
APAC-freundlich alle zwei Wochen donnerstags von 13:00 bis 14:00 Uhr pazifischer Zeit (öffentlicher OSSF-Kalender)
Videoanruf: LFX-Zoom
EMEA-freundlich Alle 4 Montagetage von 7:00 bis 8:00 Uhr pazifischer Zeit (öffentlicher OSSF-Kalender)
Videoanruf: LFX-Zoom
Die Tagesordnung und Sitzungsnotizen können Sie hier einsehen.
Antworten auf häufig gestellte Fragen zu Scorecard finden Sie in den FAQ.
