Ü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:
-
Einen Bestand deiner Abhängigkeiten erstellst.
-
Weißt, wann es eine Sicherheitslücke in einer Abhängigkeit gibt.
-
Abhängigkeitsüberprüfungen für deine Pull Requests erzwingst.
-
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 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
Note
Secret scanning ist für die folgenden Repositorys verfügbar:
-
Organisationeigene Repositorys mit aktiviertem GitHub Advanced Security
-
für ein Unternehmen mit aktiviertem GitHub Advanced Security
Note
Der Siteadministrator muss zum Beispiel secret scanning für die Instanz aktivieren, damit du dieses Feature verwenden kannst. Weitere Informationen findest du unter Konfigurieren der Geheimnisüberprüfung für deine Appliance.
Möglicherweise kannst du secret scanning nicht aktivieren oder deaktivieren, wenn ein Unternehmensbesitzer eine Richtlinie auf Unternehmensebene festgelegt hat. Weitere Informationen findest du unter Erzwingen von Richtlinien für die Codesicherheit und -analyse für Unternehmen.
Du kannst secret scanning so konfigurieren, dass nach Geheimnissen gesucht wird, die von vielen Dienstanbietern ausgegeben werden, und dass du benachrichtigt wirst, wenn welche gefunden werden. Du kannst auch eigene Muster definieren, um zusätzliche Geheimnisse auf Repository-, Organisations- oder Unternehmensebene zu erkennen. Weitere Informationen findest du unter Informationen zur Geheimnisüberprüfung und Unterstützte Scanmuster für geheime Schlüssel.
Sichere Speicherung von Geheimschlüsseln, die du in GitHub Enterprise Server verwendest
Neben deinem Code musst du wahrscheinlich Geheimnisse an anderen Stellen verwenden. zum Beispiel, um GitHub Actions-Workflows oder Dependabot die Kommunikation mit anderen Systemen zu ermöglichen. Weiter Informationen zum sicheren Speichern und Verwenden von Geheimnissen findest du unter Verwenden von Geheimnissen in GitHub-Aktionen und Konfigurieren des Zugriffs auf private Registrierungen für Dependabot.
Halte anfällige Codierungsmuster aus deinem Repository fern
Note
Organisationseigene Repositorys mit aktivierter GitHub Advanced Security
Note
Der Websiteadministrator muss code scanning aktivieren, damit du dieses Feature verwenden kannst. Weitere Informationen findest du unter Konfigurieren der Codeüberprüfung für Ihre Anwendung.
Möglicherweise kannst du code scanning nicht aktivieren oder deaktivieren, wenn eine Unternehmensbesitzerin eine GitHub Advanced Security-Richtlinie (GHAS) auf Unternehmensebene festgelegt hat. Weitere Informationen findest du unter Erzwingen von Richtlinien für die Codesicherheit und -analyse für Unternehmen.
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.