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 findest du unter Exportieren einer Software-Stückliste (Software Bill of Materials, SBOM) für dein Repository.

Automatische Erkennung von Sicherheitsrisiken in Abhängigkeiten

Dependabot können dich dabei unterstützen, deine Abhängigkeiten zu überwachen und dich zu benachrichtigen, wenn sie eine bekannte Sicherheitsanfälligkeit enthalten. Sie können sogar Dependabot aktivieren, um Pull Requests, die die Abhängigkeit auf eine sichere Version aktualisieren, automatisch auszulösen. Weitere Informationen findest du unter Informationen zu Dependabot-Warnungen und Informationen zu Dependabot-Sicherheitsupdates.

Automatische Erkennung von Sicherheitsrisiken in Pull Requests

Die Abhängigkeitsüberprüfungsaktion erzwingt eine Abhängigkeitsprüfung für deine Pull Requests, sodass du leicht erkennen kannst, ob ein Pull Request eine für Sicherheitsrisiken anfällige Version einer Abhängigkeit in dein Repository einführt. Wenn ein Sicherheitsrisiko erkannt wird, kann die Abhängigkeitsüberprüfungsaktion das Zusammenführen des Pull Requests blockieren. Weitere Informationen findest du 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 ist Partner vieler Anbieter, um automatisch zu erkennen, wenn Geheimnisse in deine öffentlichen Repositorys oder öffentlichen npm-Pakete, von denen du abhängig bist, übertragen oder dort gespeichert werden, und benachrichtigt den Anbieter, damit er geeignete Maßnahmen ergreifen kann, um die Sicherheit deines Kontos zu gewährleisten. Weitere Informationen findest du unter Informationen zu Warnungen zur Geheimnisüberprüfung.

Sie können zusätzliche Überprüfungen aktivieren und konfigurieren, die Sie über versehentlich kompromittierte Geheimnisse für GitHub benachrichtigen, wenn Sie Folgendes besitzen:

• Öffentliche Repositorys auf GitHub.
• Eine Organisation, die GitHub Enterprise Cloud mit einer Lizenz für GitHub Advanced Security verwendet. Secret scanning analysiert auch deine privaten Repositorys.

Sichere Speicherung von Geheimschlüsseln, die du in GitHub verwendest

Neben deinem Code musst du wahrscheinlich Geheimnisse an anderen Stellen verwenden. Zum Beispiel, um GitHub Actions-Workflows, Dependabot oder deine GitHub Codespaces-Entwicklungsumgebung mit anderen Systemen kommunizieren zu lassen. Weitere Informationen zum sicheren Speichern und Verwenden von Geheimnissen findest du unter Verwenden von Geheimnissen in GitHub-Aktionen, Konfigurieren des Zugriffs auf private Registrierungen für Dependabot und Verwalten deiner kontospezifischen Geheimnisse 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, mit denen du den Überprüfungs- und Zusammenführungsprozess steuern kannst. 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 du deinen Code überprüfen kannst. Weitere Informationen zu den ersten Schritten findest du unter Informationen zu Codescans.

Nächste Schritte

• Sichern einer End-to-End-Lieferkette

• Bewährte Methoden zum Schützen von Konten

• Bewährte Methoden zum Schützen deines Buildsystems