Verbesserung der Sicherheitseinstellungen Ihrer GitHub-Repositories durch Hinzufügen der OSSF-Scorecard-Aktion

Kürzlich habe ich damit begonnen, die OSSF Scorecard Aktion zu meinen (Aktions-)Repositories. Dies ist eine GitHub-Aktion, die die OSSF Scorecard prüft Ihr Repository, um festzustellen, ob Sie bewährte Praktiken befolgen, z. B. eine Sicherheitsrichtlinie haben, ein Code-Scan-Tool verwenden usw. Mit diesem Badge können Sie Ihren Benutzern einen schnellen Überblick über die Sicherheit Ihres Repositorys geben. OSSF steht für 'Open Source Security Foundation' und ist eine Initiative zur Verbesserung der Sicherheit von Open Source Repositories.

Scorecard Aktion

Die Scorecard-Aktion bewirkt drei Dinge (wenn Sie die Standardeinstellungen verwenden):

1. Analysieren Sie Ihr Repository auf die Prüfungen
2. Laden Sie die Ergebnisse auf die Registerkarte Sicherheit von GitHub hoch (mit einer SARIF-Datei)
3. Laden Sie die Ergebnisse in die OSSF-API hoch (eine Web-API, die Sie sogar selbst hosten können). Mit den in die OSSF-API hochgeladenen Daten können Sie dann ein Abzeichen mit Ihrem neuesten Ergebnis abrufen und dieses in Ihrem Repository anzeigen:

Scoring

Die Aktion prüft Ihr Repository gegen mehrere Prüfungen und errechnet dann für jede Prüfung eine Punktzahl auf einer Skala von 0 bis 10. Basierend auf dem Risiko für diese Prüfung wird die Punktzahl dann mit einer Gewichtung multipliziert. Die endgültige Punktzahl ist der Durchschnitt aller gewichteten Punktzahlen. Je höher die Punktzahl, desto besser.

Einige der Prüfungen, die durchgeführt werden, sind:

• Zweig-Schutz: Ist der Verzweigungsschutz für die Standardverzweigung aktiviert?
• Sind die GitHub Action-Versionen an SHA-Hashes gepinnt, gemäß den Best Practices?
• Verwendet das Repository ein Code-Scan-Tool? Beachten Sie, dass diese Prüfung derzeit nur CodeQL und SonarCloud unterstützt.
• Wurde eine Sicherheitsrichtlinie festgelegt?
• Gibt es eine Definitionsdatei für Dependabot?

Einrichten

Die Einrichtung ist so einfach wie das Aufrufen des OSSF Scorecard Aktion Repo und kopieren Sie das Workflow-Beispiel. Fügen Sie diese Datei zu einer neuen Workflow-Datei in Ihrem Repository hinzu und führen Sie sie von der Standardverzweigung aus (normalerweise main). Nach dem ersten Durchlauf können Sie einen Link in Ihre README.md-Datei einfügen, um das Abzeichen anzuzeigen.

Das Ergebnis ist ein Abzeichen, das den aktuellen Punktestand anzeigt:

Warnungen beim Scannen von Codes

Die Standard-Workflow lädt die Prüfergebnisse auch als SARIF-Datei in die Code-Scanning-Warnungen hoch, die Sie auf der Registerkarte Sicherheit Ihres Repositorys finden. Jede Überprüfung kann ein oder mehrere Ergebnisse liefern, so dass Sie für jedes Ergebnis eine Warnung erhalten. Auf diese Weise können Sie die Probleme nacheinander beheben.

Noch besser ist, dass die meisten dieser Warnmeldungen Ihnen konkrete Vorschläge zur Behebung des Problems machen. Die obige Meldung enthält zum Beispiel einen Link zum Schritt Sicherheit Anwendung, die Ihr Repository analysiert und Ihnen einen Pull Request mit den Änderungen zur Behebung des Problems übermittelt. Sie konzentrieren sich auf drei Dinge:

• Beschränken Sie die Berechtigung für den GITHUB_TOKEN
• Sicherheitsagent für den von GitHub gehosteten Runner hinzufügen (nur Ubuntu)
• Aktionen mit einem vollständigen SHA-Hash verknüpfen

Beschränken Sie die Berechtigung für den GITHUB_TOKEN

Eine der besten Praktiken ist es, immer anzugeben, welche Berechtigungen Sie für das GitHub-Token, das in Ihrem Arbeitsablauf verwendet wird, zulassen möchten. Die Standardeinstellung ist permissiv: Sie lautet read und write für alles in Ihrem Repo. Ich habe dafür plädiert, dass die Leute dies auf der Organisationsebene immer schreibgeschützt machen.

Da Sie nicht sehen können, welche Rechte die Organisation hat, ist es am besten, wenn Sie die Rechte immer angeben. Sie können sie oben in Ihrer Workflow-Datei hinzufügen:

permissions: read-all

Und jetzt können Sie sie bei Bedarf auf der Auftragsebene außer Kraft setzen. Wenn Sie zum Beispiel in einen Zweig pushen müssen, können Sie Folgendes hinzufügen write zum contents Erlaubnis:

jobs:
  build:
    permissions:
        contents: write
    runs-on: ubuntu-latest
    steps:
     # etc

Sicherheitsagent für den von GitHub gehosteten Runner hinzufügen (nur Ubuntu)

Diese Einstellung möchte ich mir genauer ansehen. Es scheint, dass Sie einen Sicherheitsagenten zu Ihrem auf GitHub gehosteten Runner hinzufügen können (nur für Ubuntu verfügbar). Es ist ein zusätzliches Produkt von Schritt Sicherheit das kostenlos erhältlich ist. Es analysiert den Netzwerkverkehr im Auftrag und protokolliert ihn in seinem System. Nach ein paar Durchläufen wissen sie, welche Art von Datenverkehr zu erwarten ist, und dann können Sie dies im Grunde in eine Firewall-Regel umwandeln. Alle Verstöße werden dann protokolliert und blockiert. Dies kann Ihnen einen besseren Schutz bieten (da standardmäßig jeglicher Datenverkehr erlaubt ist).

Auf jeden Fall etwas, das Sie sich genauer ansehen sollten!

Aktionen mit einem vollständigen SHA-Hash verknüpfen

Die letzte Option besteht darin, Ihre Aktionen an einen vollständigen SHA-Hash zu binden. Dies ist eine bewährte Praxis, die ich seit Jahren eine Zeit lang befürwortet. Es ist ein bisschen mehr Arbeit, aber es stellt sicher, dass Ihr Workflow nicht von einem böswilligen Akteur beeinträchtigt wird, der eine neue Version einer Aktion veröffentlicht. Was mir wirklich gut gefällt, ist, dass diese Einstellung Ihre Workflow-Datei analysiert (entweder eingefügt oder nur alle Workflows in Ihrem öffentlichen Repo) und dann die SHA-Hashes der Aktionen vorschlägt, indem sie deren neueste Version betrachtet! Noch besser: Die neueste Version wird im Kommentar neben dem SHA-Hash gespeichert, so dass Sie nachvollziehen können, woher der Hash stammt. Sogar Dependabot versteht diesen Kommentar und wird ihn in seinen Versionsupdate-PRs aktualisieren!