Vorherige

Nächste

Verwalten eines sicheren GitHub-Repositorys

Abgeschlossen

In dieser Lerneinheit sollen einige der wichtigen Sicherheitstools und -methoden erläutert werden, die für Administratoren von GitHub-Repositorys zur Verfügung stehen.

Hinweis

Der folgende Inhalt behandelt nicht die Grundlagen des Schreibens von sicherem Code, sondern wichtige Sicherheitsüberlegungen, Tools und Features für das Verwenden innerhalb eines GitHub-Repositorys.

Die Relevanz einer sicheren Entwicklungsstrategie

Anwendungssicherheit ist wichtig. Bei neuen Diensten gibt es oft Erzählungen von Sicherheitsverletzungen bei Systemen eines Unternehmens, durch die private Unternehmens- und Kundendaten gestohlen wurden.

Welche Probleme sollten also bedacht werden, wenn eine sichere Entwicklungsstrategie geplant wird? Klar, wir müssen die Informationen vor der Weitergabe an Personen schützen, die keinen Zugriff darauf haben sollten, aber wichtiger ist, dass wir sicherstellen müssen, dass Informationen nur geändert oder zerstört werden, wenn sie angemessen sind.

Personen, die auf die Daten zugreifen, müssen sich ordnungsgemäß authentifizieren und auch über die erforderlichen Berechtigungen für den Zugriff verfügen. Es muss möglich sein, über Verlaufs- oder Archivdaten oder Protokolle Beweise zu finden, wenn ein Fehler auftritt.

Beim Erstellen und Bereitstellen sicherer Anwendungen gibt es viele Aspekte zu berücksichtigen. Sehen Sie sich hierzu insbesondere diese drei Punkte an:

• Es gibt ein allgemeines Wissensproblem: Viele Entwickler und weitere Mitarbeiter gehen davon aus, sie wissen über das Thema „Sicherheit“ Bescheid. Oft ist dies jedoch nicht der Fall. Die Cybersicherheit ist ein sich ständig weiterentwickelndes Gebiet. Deshalb ist es wichtig, sich ständig dazu weiterzubilden und Trainings durchzuführen.

• Code muss ordnungsgemäß und sicher erstellt werden: Sie müssen sicherstellen, dass der Code ordnungsgemäß erstellt wird und die erforderlichen Features sicher implementiert. Außerdem muss sichergestellt werden, dass beim Entwerfen der Features die Sicherheit immer an erster Stelle stand.

• Anwendungen müssen Regeln und Bestimmungen erfüllen: Sie müssen dafür sorgen, dass der Code den erforderlichen Regeln und Vorschriften entspricht. Die Compliance muss beim Erstellen des Codes überprüft und auch nach der Bereitstellung müssen regelmäßig weitere Tests durchgeführt werden.

Sicherheit bei jedem Schritt

Sicherheit kann einer Anwendung oder einem System nicht nachträglich hinzugefügt werden. Eine sichere Entwicklung muss deshalb integraler Bestandteil jeder Lebenszyklusphase der Softwareentwicklung sein. Dieses Konzept ist für essenzielle Anwendungen und diejenigen, die vertrauliche und streng geheime Informationen verarbeiten, noch wichtiger.

Damit Entwicklerteams für ihre Arbeit verantwortlich gemacht werden können, müssen Prozesse im Entwicklungslebenszyklus nach links verschoben oder schon früher abgeschlossen werden. Wenn bestimmte Schritte nicht erst während der Bereitstellung am letzten Gate erfolgen, sondern früher, werden weniger Fehler gemacht und die Entwickler kommen schneller voran.

In der Vergangenheit standen Sicherheitskonzepte für Anwendungen bei Entwickler*innen nicht im Fokus. Abgesehen von den Problemen bei Fortbildungen und Trainings lag dies insbesondere daran, dass Organisationen oftmals eine schnelle Featureentwicklung priorisierten.

Seit der Einführung von DevOps-Methoden können Sicherheitstests jedoch einfacher mit der Pipeline integriert werden. Sicherheitstests sollten nicht als Aufgabe angesehen werden, die von Sicherheitsexperten ausgeführt wird, sondern sollten Teil des alltäglichen Lieferungsprozesses sein.

Wenn auch die Zeit für Nachbesserungen berücksichtigt wird, können die Entwicklungsteams durch das Implementieren von Sicherheitstests in ihre DevOps-Methoden in einer früheren Phase des Entwicklungslebenszyklus Probleme schneller finden. Das frühere Erkennen von Problemen kann die Gesamtzeit für das Entwickeln hochwertiger Software reduzieren.

Das Verschieben nach links ist eine Prozessänderung, aber es handelt sich nicht um ein einzelnes Steuerelement oder ein bestimmtes Tool. Es geht darum, alle Ihre Sicherheitsmaßnahmen entwicklerorientierter zu machen und Entwickler*innen Sicherheitsfeedback zu geben, wo sie sich befinden.

Features der Registerkarte „Sicherheit“

GitHub bietet Sicherheitsfeatures, mit denen Daten in Repositorys und organisationsübergreifend geschützt werden können. So finden Sie die Registerkarte „Sicherheit“:

1. Navigieren Sie auf GitHub.com zur Hauptseite des Repositorys.

2. Wählen Sie unter dem Repositorynamen Sicherheit aus.

Auf der Registerkarte „Sicherheit“ können Sie Ihrem GitHub-Workflow Features hinzufügen, um Sicherheitsrisiken in Ihrem Repository und Ihrer Codebasis zu vermeiden. Zu diesen Features zählen:

• Sicherheitsrichtlinien, mit denen Sie angeben können, wie eine Sicherheitslücke in Ihrem Projekt gemeldet wird. Dazu fügen Sie ihrem Repository eine Datei SECURITY.md hinzu.
• Dependabot-Warnungen, die Sie benachrichtigen, wenn GitHub erkennt, dass Ihr Repository eine anfällige Abhängigkeit oder Schadsoftware verwendet.
• Sicherheitsempfehlungen, die Sie verwenden können, um Sicherheitsrisiken in Ihrem Repository privat zu diskutieren, zu beheben und Informationen dazu zu veröffentlichen.
• Codeüberprüfung, mit der Sie Sicherheitsrisiken und Fehler in Ihrem Code finden, selektieren und beheben können.

Weitere Informationen finden Sie unter GitHub-Sicherheitsfeatures.

Hinweis

Die Dependabot-Warnungsempfehlungen für Schadsoftware befinden sich derzeit in der Betaversion und können sich noch ändern. Nur Empfehlungen, die von GitHub überprüft wurden, lösen Dependabot-Warnungen aus.

Als Nächstes geht es um einige dieser Features und die Möglichkeiten zum Verteilen sicherheitsbezogener und betrieblicher Aufgaben auf alle Lebenszyklusphasen der Softwareentwicklung.

Kommunizieren einer Sicherheitsrichtlinie mit SECURITY.md

Das Prinzip einer Community bei GitHub hat erhebliche Vorteile, kann jedoch auch risikobehaftet sein. Die Tatsache, dass jeder Fehlerbehebungen öffentlich vorschlagen kann, führt auch zu einer erhöhten Verantwortung. Die wichtigste Verantwortlichkeit besteht darin, verantwortungsvoll mit Informationen umzugehen, die zu Sicherheitslücken führen könnten, noch bevor zugrunde liegende Fehler behoben werden können. Entwickler, die Sicherheitsprobleme melden oder beheben möchten, können im Stamm eines Repositorys nach einer SECURITY.md-Datei suchen, wo sie ihre Bedenken verantwortungsbewusst offenlegen können. Wenn diese Datei einen Leitfaden enthält, beschleunigt dies das Lösen essenzieller Probleme.

Weitere Informationen zu SECURITY.md finden Sie unter Hinzufügen einer Sicherheitsrichtlinie für Ihr Repository.

GitHub-Sicherheitsempfehlungen

Mithilfe von GitHub-Sicherheitsempfehlungen können Repositoryverwalter ein Sicherheitsrisiko in einem Projekt privat besprechen und beheben. Nach der Zusammenarbeit an einem Fix können Repositoryverwalter*innen die Sicherheitsempfehlung veröffentlichen, um das Sicherheitsrisiko für die Community des Projekts offenzulegen. Durch das Veröffentlichen von Sicherheitsempfehlungen erleichtern Repositoryverwalter*innen ihrer Community das Aktualisieren von Paketabhängigkeiten und das Untersuchen der Auswirkungen von Sicherheitsrisiken. GitHub speichert die veröffentlichten Empfehlungen in der Liste „Common Vulnerabilities and Exposures“ (CVE, allgemeine Sicherheitsrisiken und Schwachstellen). Diese Liste wird zum automatischen Benachrichtigen betroffener Repositorys genutzt, die Software mit einem der aufgelisteten Sicherheitsrisiken verwenden. Weitere Informationen finden Sie unter Informationen zu Sicherheitsempfehlungen für Repositorys.

Speichern vertraulicher Dateien aus Ihrem Repository mit .gitignore

Es passiert schnell einmal, dass Entwickler Dateien übersehen, die in einem Commitvorgang eingeschlossen sind. Manchmal sind diese übersehenen Dateien harmlos, z. B. intermediäre Builddateien. Es besteht jedoch immer das Risiko, dass Personen versehentlich vertrauliche Daten committen. Beispielsweise könnte eine Person einen API-Schlüssel oder private Konfigurationsdaten committen, die ein böswilliger Akteur verwenden kann. Das Erstellen und Verwalten von .gitignore-Dateien ist eine Methode, dieses Risiko zu vermeiden. Diese Dateien weisen Clienttools wie das git-Befehlszeilenhilfsprogramm an, Pfade und Muster beim Aggregieren von Dateien für einen Commitvorgang zu ignorieren.

Im folgenden Beispiel sehen Sie einige der häufigsten Anwendungsfälle für das Ignorieren von Dateien:

# User-specific files - Ignore all files ending in ".suo"
*.suo

# Mono auto generated files - Ignore all files starting with "mono_crash."
mono_crash.*

# Build results - Ignore all files in these folders found at any folder depth
[Dd]ebug/
[Rr]elease/
x64/
x86/

# Root config folder - Ignore this directory at the root due to leading slash
# Removing the slash would ignore "config" directories at all depths 
/config

# Ignore intermediate JS build files produced during TypeScript build at any 
# folder depth under /Web/TypeScript. This won't ignore JS files elsewhere. 
/Web/TypeScript/**/*.js

Ihr Repository könnte mehrere .gitignore-Dateien enthalten. Einstellungen werden von übergeordneten Verzeichnissen geerbt. Überschreibende Dateien in neuen .gitignore-Dateien haben dabei Vorrang vor übergeordneten Einstellungen für die dazugehörigen Ordner und Unterordner. Es ist sehr aufwändig, die .gitignore-Stammdatei zu verwalten, obwohl das Hinzufügen einer .gitignore-Datei in ein Projektverzeichnis hilfreich sein kann, wenn es für dieses Projekt bestimmte Anforderungen gibt, die sich einfacher unabhängig von der übergeordneten Datei verwalten lassen, z. B. Dateien, die nicht ignoriert werden sollten.

In diesem Artikel erfahren Sie mehr zu .gitignore und über das Ignorieren von Dateien. Sehen Sie sich auch die Sammlung mit .gitignore-Startdateien an, die für verschiedene Plattformen im GITIGNORE-Repository verfügbar sind.

Entfernen vertraulicher Daten aus einem Repository

Obwohl .gitignore-Dateien helfen können, Mitwirkende zu unterstützen, ein Committen vertraulicher Daten zu vermeiden, handelt es sich nur um eine Empfehlung. Entwickler*innen können diese Methode trotzdem umgehen, wenn sie Dateien hinzufügen möchten. Manchmal werden Dateien auch übersehen, weil sie nicht der .gitignore-Dateikonfiguration entsprechen. Projektteilnehmer*innen sollten immer Ausschau nach Commitvorgänge halten, die Daten enthalten, die nicht im Repository oder im Verlauf vorhanden sein sollten.

Wichtig

Sie müssen davon ausgehen, dass alle Daten, die in GitHub committet wurden, jederzeit gefährdet sein könnten. Ein einfaches Überschreiben eines Commitvorgangs reicht nicht zum Sicherstellen, dass auf die Daten zukünftig nicht zugegriffen werden kann. Eine vollständige Anleitung zum Entfernen vertraulicher Daten von GitHub finden Sie unter Entfernen vertraulicher Daten aus einem Repository.

Regeln für den Schutz von Branches

Sie können eine Branchschutzregel erstellen, um bestimmte Workflows für eine oder mehrere Branches zu erzwingen. Sie können z. B. eine Überprüfung für die Genehmigung anfordern oder Statusüberprüfungen für alle Pull Requests übergeben, die im geschützten Branch zusammengeführt werden.

Sie können die Workflows, die den Branch schützen, für Folgendes nutzen:

• Ausführen eines Build, um zu überprüfen, ob die Codeänderungen bereitgestellt werden können
• Ausführen eines Linters zur Überprüfung auf Tippfehler und ob interne Programmierkonventionen eingehalten werden
• Ausführen automatisierter Tests zur Überprüfung auf Behavior Changes des Codes
• weitere Operatoren

Hinzufügen einer CODEOWNERS-Datei

Indem Sie Ihrem Repository eine CODEOWNERS-Datei hinzufügen, können Sie einzelne Teammitglieder oder ganze Teams in Ihrem Repository als Codebesitzer zu Pfaden zuweisen. Diese Codebesitzer sind dann für Pull Request-Überprüfungen von Änderungen an Dateien in einem Pfad erforderlich, für den sie konfiguriert sind.

# Changes to files with the js extensions need to be reviewed by the js-owner user/group:
*.js    @js-owner

# Changes to files in the builds folder need to be reviewed by the octocat user/group:
/build/ @octocat

Sie können die CODEOWNERS-Datei im Stammverzeichnis des Repositorys oder im Ordner docs oder .github erstellen.

Weiter