Anpassung Ihrer Aktionskonfiguration für die Überprüfung von Abhängigkeiten

Erfahre, wie du eine grundlegende Anpassung an deine Konfiguration für die Abhängigkeitsprüfungsaktion hinzufügen kannst.

Wer kann dieses Feature verwenden?

Repositorybesitzerinnen, Organisationsbesitzerinnen, Sicherheitsmanagerinnen und Benutzerinnen mit der Administratorrolle

In diesem Artikel

Einleitung

Die Abhängigkeitsüberprüfungsaktion prüft deine Pull Requests auf Änderungen bei Abhängigkeiten und gibt einen Fehler aus, wenn neue Abhängigkeiten bekannte Sicherheitsrisiken aufweisen. Wenn die Workflowausführung nach der Installation als erforderlich gekennzeichnet ist, werden Pull Requests, die bekannte anfällige Pakete einführen, am Zusammenführen gehindert.

In diesem Handbuch wird gezeigt, wie Sie drei häufig verwendete Anpassungen hinzufügen: Fehlerhafte Builds basierend auf Schweregrad der Verwundbarkeit, Abhängigkeitslizenz und Reservierungsumfang.

Voraussetzungen

In diesem Leitfaden wird davon ausgegangen, dass:

Schritt 1: Hinzufügen der Maßnahme zur Überprüfung der Abhängigkeit

In diesem Schritt fügen wir Ihrem Repository den Workflow zur Überprüfung der Abhängigkeit hinzu.

  1. Navigieren Sie auf GitHub zur Hauptseite des Repositorys.

  2. Klicke unter dem Repositorynamen auf Actions.

    Screenshot: Registerkarten für das Repository „github/docs“. Die Registerkarte „Aktionen“ ist mit einem orangefarbenen Rahmen hervorgehoben.

  3. Suchen Sie unter "Erste Schritte mit GitHub Actions" die Kategorie "Sicherheit", und klicken Sie dann auf Alle anzeigen.

  4. Suchen Sie "Überprüfung der Abhängigkeit", und klicken Sie dann auf Konfigurieren. Alternativ können Sie mithilfe der Suchleiste nach "Überprüfung der Abhängigkeit" suchen.

  5. Dadurch wird dieGitHub Actions-Workflow-Datei dependency-review.ymlder Abhängigkeitsprüfung geöffnet. Sie sollte Folgendes enthalten:

    YAML
    name: 'Dependency review'
on:
  pull_request:
    branches: [ "main" ]

permissions:
  contents: read

jobs:
  dependency-review:
    runs-on: ubuntu-latest
    steps:
      - name: 'Checkout repository'
        uses: actions/checkout@v5
      - name: 'Dependency Review'
        uses: actions/dependency-review-action@v4

Schritt 2: Ändern des Schweregrads

Sie können verhindern, dass Code, der anfällige Abhängigkeiten enthält, jemals zusammengeführt wird, indem Sie Abhängigkeitsüberprüfungsaktion auf erforderlich festlegen. Es lohnt sich jedoch zu beachten, dass das Blockieren von Sicherheitsrisiken mit geringem Risiko in einigen Fällen zu restriktiv sein kann. In diesem Schritt ändern wir den Schweregrad der Sicherheitsanfälligkeit, die dazu führt, dass ein Build mit der Option fail-on-severity fehlschlägt.

  1. Fügen Sie die Option fail-on-severity am Ende der Datei dependency-review.yml hinzu:

    YAML
          - name: 'Dependency Review'
        uses: actions/dependency-review-action@v4
        with:
          fail-on-severity: moderate

Schritt 3: Hinzufügen von zu blockierenden Lizenzen

Sicherheitsrisiken sind nicht der einzige Grund, warum Sie eine Abhängigkeit blockieren möchten. Wenn Ihr Unternehmen Beschränkungen hinsichtlich der Art der Lizenzen auferlegt, die Sie verwenden können, können Sie die Abhängigkeitsprüfung verwenden, um diese Richtlinien mit der Option deny-licenses zu erzwingen. In diesem Schritt werden wir eine Anpassung hinzufügen, die den Build unterbricht, wenn die Pull-Anfrage eine Abhängigkeit einführt, die die LGPL-2.0- oder BSD-2-Clause-Lizenz enthält.

  1. Fügen Sie die Option deny-licenses am Ende der Datei dependency-review.yml hinzu:

    YAML
          - name: 'Dependency Review'
        uses: actions/dependency-review-action@v4
        with:
          fail-on-severity: moderate
          deny-licenses: LGPL-2.0, BSD-2-Clause

Schritt 4: Hinzufügen von Reservierungsumfängen

Abschließend werden wir die Option fail-on-scopes verwenden, um zu verhindern, dass anfällige Abhängigkeiten mit bestimmten Bereitstellungsumgebungen, in diesem Fall der Entwicklungsumgebung, zusammengeführt werden.

  1. Fügen Sie die Option fail-on-scopes am Ende der Datei dependency-review.yml hinzu:

    YAML
          - name: 'Dependency Review'
        uses: actions/dependency-review-action@v4
        with:
          fail-on-severity: moderate
          deny-licenses: LGPL-2.0, BSD-2-Clause
          fail-on-scopes: development

Schritt 5: Überprüfen der Konfiguration

Die Datei dependency-review.yml sollte jetzt wie folgt aussehen:

YAML

name: 'Dependency Review'
on: [pull_request]


permissions:
  contents: read


jobs:
  dependency-review:
    runs-on: ubuntu-latest
    steps:
      - name: 'Checkout Repository'
        uses: actions/checkout@v5
      - name: Dependency Review
        uses: actions/dependency-review-action@v4
        with:
          fail-on-severity: moderate
          deny-licenses: LGPL-2.0, BSD-2-Clause
          fail-on-scopes: development

Sie können diese Konfiguration als Vorlage für Ihre eigenen benutzerdefinierten Konfigurationen verwenden.

Weitere Informationen zu allen möglichen Anpassungsoptionen finden Sie in der Infodatei in der Dokumentation zur Abhängigkeitsüberprüfung.

Bewährte Methoden

Beim Anpassen der Konfiguration für die Überprüfung der Abhängigkeit gibt es einige bewährte Methoden, die Sie befolgen können:

  • Wählen Sie blockierte Kontakte über Zulassungslisten aus. Es ist praktischer, eine Liste der "wirklich schlechten" Abhängigkeiten zu kompilieren, die Sie blockieren möchten, als eine inklusive Liste aller Bibliotheken zu erstellen, die Sie zulassen möchten.

  • Wählen Sie aus, ob Lizenzen blockiert werden sollen, anstatt anzugeben, welche Lizenzen zulässig sind. Es gibt eine Vielzahl von Lizenzen, daher ist es in der Regel praktischer, diejenigen auszuschließen, von denen Sie wissen, dass sie mit den aktuellen Lizenzen nicht kompatibel sind, als eine vollständige Liste der kompatiblen Lizenzen zu erstellen.

  • Klicken Sie auf die Option fail-on-severity. Ein Scheitern aufgrund der Schwere einer Schwachstelle ist eine gute Möglichkeit, um die Notwendigkeit von Sicherheit mit der Notwendigkeit, reibungslose Erfahrungen für Entwickler zu schaffen, in Einklang zu bringen.

Weiterführende Lektüre

  •         [AUTOTITLE](/code-security/supply-chain-security/understanding-your-software-supply-chain/configuring-the-dependency-review-action)

  •         [AUTOTITLE](/code-security/supply-chain-security/understanding-your-software-supply-chain/enforcing-dependency-review-across-an-organization)