Bewährte Methoden zum Sichern von Code in einer Lieferkette

Über diesen Leitfaden

Dieser Leitfaden beschreibt die wichtigsten Änderungen, mit denen du die Sicherheit deines Codes verbessern kannst. In den einzelnen Abschnitten wird jeweils eine Änderung beschrieben, die du zur Verbesserung der Sicherheit an deinen Prozessen vornehmen kannst. Die Änderungen mit den größten Auswirkungen sind zuerst aufgeführt.

Welches Risiko besteht?

Die wichtigsten Risiken im Entwicklungsprozess sind:

• Verwendung von Abhängigkeiten mit Sicherheitsrisiken, die ein Angreifer ausnutzen könnte.
• Die Authentifizierungsanmeldeinformationen oder ein Token, das ein Angreifer für den Zugriff auf deine Ressourcen verwenden kann.
• Einführung eines Sicherheitsrisikos in deinen eigenen Code, das ein Angreifer ausnutzen könnte.

Diese Risiken machen deine Ressourcen und Projekte angreifbar. Diese Risiken werden direkt an jeden weitergegeben, der ein von dir erstelltes Paket verwendet. In den folgenden Abschnitten wird erklärt, wie du dich selbst und deine Benutzer vor diesen Risiken schützen kannst.

Erstelle ein Programm zur Verwaltung von Sicherheitsrisiken für Abhängigkeiten

Du kannst den von dir abhängigen Code sichern, indem du ein Programm zur Verwaltung von Sicherheitsrisiken für Abhängigkeiten erstellst. Auf hoher Ebene sollte dies Prozesse beinhalten, die sicherstellen, dass du:

1. Einen Bestand deiner Abhängigkeiten erstellst.

2. Weißt, wann es eine Sicherheitslücke in einer Abhängigkeit gibt.

3. Abhängigkeitsüberprüfungen für deine Pull Requests erzwingst.

4. Die Auswirkungen der Sicherheitslücke auf deinen Code abschätzen und entscheiden, welche Maßnahmen du ergreifen musst.

Automatische Bestandsgenerierung

Als erster Schritt möchtest du eine vollständige Bestandsaufnahme deiner Abhängigkeiten vornehmen. Das Abhängigkeitsdiagramm für ein Repository zeigt dir Abhängigkeiten für unterstützte Ökosysteme. Wenn du deine Abhängigkeiten überprüfst oder andere Ökosysteme verwendest, musst du dies durch Daten aus Drittanbietertools oder durch manuelles Auflisten von Abhängigkeiten ergänzen. Wenn du mindestens Lesezugriff auf das Repository hast, kannst du das Abhängigkeitsdiagramm für das Repository als SPDX-kompatible Softwarestückliste (Bill of Materials, SBOM) über die GitHub-Benutzeroberfläche oder die GitHub-REST-API exportieren. Weitere Informationen finden Sie unter Exportieren einer Software-Stückliste (Software Bill of Materials, SBOM) für dein Repository.

Automatische Erkennung von Sicherheitsrisiken in Abhängigkeiten

          Dependabot kann Ihnen helfen, indem Sie Ihre Abhängigkeiten überwachen und Sie benachrichtigen, wenn sie eine bekannte Sicherheitsanfälligkeit enthalten. Sie können sogar Dependabot aktivieren, um automatisch Pull-Anfragen zu erstellen, die die Abhängigkeit auf eine sichere Version aktualisieren. Weitere Informationen findest du unter [AUTOTITLE](/code-security/dependabot/dependabot-alerts/about-dependabot-alerts) und [AUTOTITLE](/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates).

Automatische Erkennung von Sicherheitsrisiken in Pull Requests

Die Abhängigkeitsüberprüfungsaktion erzwingt eine Überprüfung der Abhängigkeiten in Ihren Pull-Anforderungen, damit Sie einfach sehen können, ob eine Pull-Anforderung eine verletzliche Version einer Abhängigkeit in Ihr Repository einführt. Wenn eine Sicherheitsanfälligkeit erkannt wird, kann der Abhängigkeitsüberprüfungsaktion Pull-Request blockiert werden, um das Zusammenführen zu verhindern. Weitere Informationen finden Sie unter Informationen zur Abhängigkeitsüberprüfung.

Bewertung der Risikogefährdung durch eine anfällige Abhängigkeit

Wenn du feststellst, dass du eine anfällige Abhängigkeit verwendest, z. B. eine Bibliothek oder ein Framework, musst du die Belichtungsebene deines Projekts bewerten und entscheiden, welche Maßnahmen ergriffen werden müssen. Sicherheitsrisiken werden in der Regel mit einem Schweregrad angegeben, um zu zeigen, wie schwerwiegend ihre Auswirkungen sein könnten. Der Schweregrad ist ein nützlicher Anhaltspunkt, sagt aber nichts über die vollen Auswirkungen der Sicherheitsrisiken auf deinen Code aus.

Um die Auswirkungen einer Sicherheitsanfälligkeit auf deinen Code zu bewerten, musst du auch berücksichtigen, wie du die Bibliothek verwendest und bestimmst, wie viel Risiko tatsächlich für dein System besteht. Vielleicht ist das Sicherheitsrisiko Teil eines Features, das du nicht nutzt, und du kannst die betroffene Bibliothek aktualisieren und mit deinem normalen Veröffentlichungszyklus fortfahren. Oder vielleicht ist dein Code stark gefährdet und du musst die betroffene Bibliothek aktualisieren und sofort einen aktualisierten Build senden. Diese Entscheidung hängt davon ab, wie du die Bibliothek in deinem System verwendest, und ist eine Entscheidung, die nur du treffen kannst.

Sichere deine Kommunikationstoken

Der Code muss oft mit anderen Systemen über ein Netzwerk kommunizieren und benötigt geheime Schlüssel (wie ein Passwort oder einen API-Schlüssel), um sich zu authentifizieren. Dein System benötigt Zugang zu diesen Geheimnissen, um zu funktionieren. Dabei empfiehlt es sich, sie nicht in deinen Quellcode einzuschließen. Dies ist besonders wichtig für Repositorys, zu denen viele Personen Zugang haben könnten, und entscheidend für öffentliche Repositorys.

Automatische Erkennung von Geheimnissen, die in ein Repository übertragen wurden

          GitHub arbeitet mit vielen Anbietern zusammen, um automatisch zu erkennen, wann Geheimnisse in Ihren öffentlichen Repositories und öffentlichen npm-Paketen, auf die Sie angewiesen sind, hinterlegt oder gespeichert werden, und wird den Anbieter benachrichtigen, damit er geeignete Maßnahmen ergreifen kann, um die Sicherheit Ihres Kontos zu gewährleisten. Weitere Informationen finden Sie unter [AUTOTITLE](/code-security/secret-scanning/managing-alerts-from-secret-scanning/about-alerts##about-partner-alerts).

Sie können zusätzliche Überprüfungen aktivieren und konfigurieren, die Sie darüber informieren, wenn geheime Schlüssel auf GitHub versehentlich verloren gehen, vorausgesetzt, dass Sie im Besitz der erforderlichen Rechte sind.

• Öffentliche Repositorys
• Eine Organisation, die GitHub Team oder GitHub Enterprise Cloud mit einer Lizenz für GitHub Secret Protection or GitHub Advanced Security verwendet. Secret scanning analysiert auch Ihre privaten Repositorys.

Sichere Speicherung von geheimen Schlüsseln, die Sie verwenden GitHub

Neben Ihrem Code müssen Sie wahrscheinlich geheime Schlüssel an anderen Stellen verwenden. Um beispielsweise die Kommunikation von GitHub Actions Workflows, Dependabot oder Ihrer GitHub Codespaces Entwicklungsumgebung mit anderen Systemen zu ermöglichen. Weitere Informationen darüber, wie du Geheimnisse sicher speichern und verwenden kannst, findest du unter Verwenden von Geheimnissen in GitHub-Aktionen, Konfigurieren des Zugriffs auf private Registrierungen für Dependabot und Verwalten Ihrer kontospezifischen geheimen Schlüssel für GitHub Codespaces.

Halte anfällige Codierungsmuster aus deinem Repository fern

Erstelle einen Überprüfungsprozess der Pull-Anforderungen

Du kannst die Qualität und Sicherheit deines Codes verbessern, indem du sicherstellst, dass alle Pull-Anforderungen überprüft und getestet werden, bevor sie zusammengeführt werden. GitHub verfügt über viele Features, die Sie verwenden können, um den Überprüfungs- und Zusammenführungsprozess zu steuern. Weitere Informationen zu den ersten Schritten findest du unter Informationen zu geschützten Branches.

Überprüfe deinen Code auf anfällige Muster

Unsichere Codemuster sind für Prüfer oft nur schwer zu erkennen. Du kannst deinen Code nicht nur auf Geheimnisse prüfen, sondern auch auf Muster, die mit Sicherheitsrisiken verbunden sind. Zum Beispiel kann eine Funktion, die nicht speichersicherfähig ist, oder eine Benutzereingabe, die zu einem Einschleusungsrisiko führen könnte, nicht entschlüsselt werden. GitHub bietet verschiedene Möglichkeiten, wie und wann Sie Ihren Code überprüfen. Weitere Informationen zu den ersten Schritten findest du unter Informationen zu Codescans.

Nächste Schritte

•         [AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/end-to-end-supply-chain-overview)
  

•         [AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/securing-accounts)
  

•         [AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/securing-builds)