10 Best Practices für die GitHub-Sicherheit
5. Februar 2024
0 Min. LesezeitAnmerkung der Redaktion: 5. Februar 2024
Die Sicherheitslandschaft verändert sich ständig. Daher wurde dieser Blog aktualisiert, um die Risiken widerzuspiegeln, denen Entwickler und Sicherheitsteams heute gegenüberstehen, und zu zeigen, wie sie diese bewältigen können.
In unserer schnelllebigen, von Code geprägten digitalen Welt steht der Schutz Ihrer Codebasis an erster Stelle. GitHub ist die bevorzugte Plattform für den Austausch von Code und die Versionsverwaltung in der Entwickler-Community. Aufgrund seiner weiten Verbreitung ist GitHub jedoch nicht vor den vielen Sicherheitsherausforderungen gefeit, mit denen Entwickler täglich konfrontiert sind. Von unbefugtem Zugriff bis hin zum Risiko des Verlusts sensibler Daten: Entwickler sollten sich unbedingt mit Best Practices für die GitHub-Sicherheit befassen, um ihren Code und ihre Entwicklungs-Workflows abzusichern.
In diesem Cheat Sheet stellen wir zehn Best Practices vor, mit denen Sie die Sicherheit Ihres GitHub-Kontos verbessern können. Laden Sie das einseitige Dokument herunter und lesen Sie weiter, um eine ausführlichere Erklärung aller zehn ausgewählten Maßnahmen zu erhalten.
2FA für GitHub aktivieren und durchsetzen
Die Zwei-Faktor-Authentifizierung, häufig als 2FA abgekürzt, ist ein Sicherheitsprotokoll, bei dem Benutzer zwei verschiedene Authentifizierungsfaktoren angeben müssen, um ihre Identität zu bestätigen. In der Regel handelt es sich dabei um etwas, das Sie wissen (z. B. ein Passwort), und etwas, das Sie besitzen (z. B. ein Smartphone). Dieser mehrschichtige Ansatz erschwert es Unbefugten erheblich, auf Ihre Daten zuzugreifen – ein wichtiges Instrument für AppSec und Codesicherheit.
GitHub ist eine wahre Fundgrube an geistigem Eigentum und sensiblem Code. Für Entwickler und DevOps-Fachkräfte sind die Sicherheit unserer Code-Repositories und die Integrität der Open-Source-Projekte, an denen wir arbeiten, von größter Bedeutung. 2FA bietet eine zusätzliche Sicherheitsebene und erschwert potenziellen Angreifern den unbefugten Zugriff – selbst wenn sie an Ihr Passwort gelangen.
So aktivieren Sie 2FA auf GitHub:
Melden Sie sich bei Ihrem GitHub-Konto an.
Klicken Sie oben rechts auf Ihr Profilbild und anschließend auf Einstellungen.
Klicken Sie in der Seitenleiste auf Sicherheit.
Klicken Sie auf die Schaltfläche Zwei-Faktor-Authentifizierung aktivieren.
Wählen Sie aus, ob Sie für 2FA eine Authentifizierungs-App verwenden oder Textnachrichten erhalten möchten, und folgen Sie den Anweisungen zur Einrichtung.
Zum Schluss erhalten Sie Wiederherstellungscodes. Diese sind wichtig, falls Sie keinen Zugriff mehr auf Ihre 2FA-Methode haben. Speichern Sie sie daher an einem sicheren Ort.
Die Zwei-Faktor-Authentifizierung (2FA) für die GitHub-Repositories Ihrer Organisation verpflichtend zu machen, ist ein wichtiger Schritt zur Verbesserung der Sicherheit. Mit der 2FA-Pflicht muss jedes Teammitglied, das auf ein Repository zugreift, eine zusätzliche Verifizierung durchführen, beispielsweise über einen temporären Code aus einer Authentifizierungs-App oder per SMS. Diese zusätzliche Sicherheitsmaßnahme verringert das Risiko eines unbefugten Zugriffs erheblich, insbesondere bei kompromittierten Passwörtern. Eine verpflichtende 2FA schützt Ihre Codebasis und zeigt, dass Sie sich aktiv für eine sichere Entwicklungsumgebung einsetzen – im Einklang mit Best Practices für eine robuste Zugriffskontrolle.
Zugriff auf Repositories beschränken
In der Anwendungs- und Codesicherheit ist es unerlässlich, den Zugriff auf Ihre GitHub-Repositories zu beschränken. So lässt sich effizient verwalten, wer Ihren Quellcode ansehen, bearbeiten oder administrieren darf. Diese Maßnahme trägt nicht nur zur Integrität des Codes bei, sondern schützt ihn auch vor potenziellen Sicherheitsbedrohungen.
Das Prinzip der geringsten Berechtigungen (PoLP) ist ein Konzept der Computersicherheit, nach dem Benutzer nur die Mindestzugriffsrechte erhalten, die sie zur Erfüllung ihrer Aufgaben benötigen. Dieses Prinzip sollte auch für Ihre GitHub-Repositories gelten.
Die Anwendung von PoLP auf Ihre Repositories trägt dazu bei, folgende Risiken zu mindern:
Versehentliche Offenlegung sensibler Daten: Durch eingeschränkten Zugriff sinkt die Wahrscheinlichkeit, dass sensible Daten versehentlich in ein Repository übertragen werden, da weniger Personen Schreibzugriff haben.
Böswillige Angriffe: Wenn Sie den Zugriff auf Ihre Codebasis beschränken, verringern Sie die Zahl möglicher Einstiegspunkte für Angreifer.
Unbeabsichtigte Änderungen: Je weniger Personen Schreib- oder Admin-Zugriff haben, desto geringer ist die Wahrscheinlichkeit unbeabsichtigter Codeänderungen, die zu Fehlern oder fehlerhaften Builds führen können.
GitHub bietet für Repositories verschiedene Zugriffsstufen: Read, Triage, Write, Maintain und Admin. Jede dieser Stufen ermöglicht unterschiedliche Aktionen. Benutzer mit Read-Berechtigungen können das Repository beispielsweise nur ansehen und forken, während Benutzer mit Admin-Berechtigungen die Einstellungen, Teams und Integrationen des Repositorys verwalten können.

Denken Sie daran: Gewähren Sie Mitwirkenden immer nur die geringsten Zugriffsrechte, die sie für ihre Aufgaben benötigen. Bei Bedarf können Sie die Zugriffsstufe später jederzeit erhöhen.
Anmeldedaten nicht als Code oder Konfiguration in GitHub speichern
Wenn Anmeldedaten direkt in GitHub-Repositories gespeichert werden, besteht ein erhebliches Sicherheitsrisiko, da sensible Informationen potenziell unbefugten Zugriffen ausgesetzt sind. Um dieses Risiko zu mindern, sollten Entwickler sichere Alternativen zur Speicherung sensibler Informationen nutzen, etwa Umgebungsvariablen oder Konfigurationsdateien außerhalb des versionskontrollierten Repositorys. Wenn im Code auf diese externen Variablen oder Dateien verwiesen wird, statt Anmeldedaten fest zu codieren, bleiben sensible Daten klar von der öffentlich zugänglichen Codebasis getrennt und das Risiko einer versehentlichen Offenlegung sinkt.
Während der Entwicklung kann Snyk Code fest codierte Anmeldedaten und Geheimnisse im Code erkennen. Das Snyk Code IDE-Plugin ist ein hervorragendes Werkzeug, um potenzielle Sicherheitsprobleme zu finden, bevor der Code committet wird.

Darüber hinaus sind spezielle Tools wie GitLeaks und Git-secrets wichtig, um die Sicherheit zu erhöhen. GitLeaks durchsucht Repositories nach Geheimnissen und API-Schlüsseln und warnt sofort, wenn kompromittierende Informationen erkannt werden. Durch die Integration von GitLeaks in CI/CD-Pipelines oder Pre-Commit-Hooks können Probleme schnell behoben werden. Git-secrets, ein weiteres hilfreiches Tool, verhindert das versehentliche Einfügen von Geheimnissen, indem Commits, Branches und bereitgestellte Dateien nach vordefinierten Mustern sensibler Daten durchsucht werden. Git-secrets ist so konfiguriert, dass Commits mit erkannten Mustern abgelehnt werden, und schützt Git- und GitHub-Repositories dadurch zuverlässig vor versehentlichen Datenlecks.
Wenn Sie diese Tools in Ihren Entwicklungs-Workflow integrieren, können Sie Sicherheitsrisiken im Zusammenhang mit der Speicherung von Anmeldedaten in Git- und GitHub-Repositories proaktiv erkennen und mindern. Mit regelmäßigen Scans und automatisierten Prüfungen können Teams die Wahrscheinlichkeit einer Offenlegung sensibler Informationen deutlich verringern und ihre Codebasis vor potenziellen Sicherheitsbedrohungen schützen.
Wird ein Geheimnis erkannt, sollten Sie die betroffenen Bereiche im Repository umgehend prüfen und ermitteln. Entfernen oder ersetzen Sie kompromittierte Anmeldedaten, ändern Sie zugehörige Schlüssel oder Passwörter und informieren Sie die Teammitglieder über den Vorfall. Reicht es nicht aus, die sensiblen Daten für ungültig zu erklären oder zu ersetzen, können Sie sie außerdem mithilfe eines Tools wie BFG Repo-Cleaner aus dem Git-Verlauf entfernen. Denken Sie daran, dass dieser Verlauf auf lokale Rechner oder Forks Ihres Repositorys kopiert worden sein kann.
Repositories mit Snyk verbinden und auf Schwachstellen prüfen
Eine der wichtigsten Best Practices für AppSec und Codesicherheit ist, Ihre GitHub-Repositories mit Snyk zu verbinden – einem führenden Tool für Entwicklersicherheit. Durch diese Integration können Sie Ihre Codebasis, Container-Images, Open-Source-Abhängigkeiten und Infrastructure-as-Code-Konfigurationen automatisch auf Schwachstellen prüfen.
Ihr GitHub-Repository mit Ihrem Snyk-Konto zu verbinden, ist ganz einfach. Melden Sie sich zunächst bei Ihrem Snyk-Konto an und rufen Sie die Seite Integrationen auf. Klicken Sie auf die GitHub-Integration und folgen Sie den Schritten, um Snyk den Zugriff auf Ihre GitHub-Repositories zu erlauben.
Snyk bietet standardmäßig vier Arten von Scans für Ihre GitHub-Repositories:
Snyk Open Source: Dieser Scan prüft Ihre Open-Source-Abhängigkeiten auf bekannte Schwachstellen. Er ist ein unverzichtbares Tool für die Open-Source-Sicherheit, denn er hilft Ihnen, Probleme in Paketen von Drittanbietern zu finden und zu beheben. Snyk kann außerdem die Lizenzen der verwendeten Abhängigkeiten prüfen und Ihnen so dabei helfen, die richtigen Entscheidungen zur Lizenz-Compliance zu treffen.
Snyk Code: Dieser Scan prüft Ihre Codebasis auf Sicherheitslücken und Probleme mit der Codequalität. Er unterstützt die Anwendungssicherheit, indem er potenzielle Schwachstellen in Ihrem Code erkennt.
Snyk Container: Dieser Scan prüft Ihre Docker-Container-Images auf Schwachstellen. Das ist ein wichtiger Bestandteil der Container-Sicherheit, denn so wird sichergestellt, dass Ihre Docker-Images sicher bereitgestellt werden können.
Snyk IaC: Dieser Scan prüft Ihre Infrastructure-as-Code-Konfigurationen. Er bietet kontinuierliche Überwachung und Behebung, um Schwachstellen in Cloud-Infrastrukturkonfigurationen wie Kubernetes, Terraform und CloudFormation zu erkennen und zu beheben.

Eingehende Pull Requests scannen
Neben der umfassenden Prüfung Ihrer GitHub-Repositories auf Schwachstellen mit Snyk sollten Sie auch die Möglichkeit nutzen, neue Pull Requests (PRs) in Echtzeit zu scannen. Mit der Pull-Request-Prüfung von Snyk können Sie Sicherheitslücken, die während der Entwicklungsphase eingeführt werden, proaktiv erkennen und beheben. Wenn Entwickler Änderungen in ihren PRs vorschlagen, scannt Snyk automatisch die geänderte Codebasis, Open-Source-Abhängigkeiten und Container-Images und weist auf potenzielle Schwachstellen hin, bevor der Code in den Standard-Branch übernommen wird.
Mit diesem proaktiven Ansatz können Entwicklungsteams Sicherheitsprobleme bereits in frühen Phasen des Entwicklungszyklus beheben und so das Risiko senken, Schwachstellen in die Produktionsumgebung einzuführen.
Durch die nahtlose Integration von Snyk in Ihren GitHub-Workflow erhöhen Sie die Sicherheit Ihrer Codebasis und fördern eine DevSecOps-Kultur, in der kontinuierliche Sicherheit während des gesamten Softwareentwicklungsprozesses im Mittelpunkt steht. Wenn Sie Ihre Repositories mit Snyk verbinden und Pull-Request-Scans aktivieren, schaffen Sie eine zusätzliche Schutzebene und stellen sicher, dass nur sicherer Code in Ihren Standard-Branch übernommen wird.
Eine SECURITY.md-Datei hinzufügen
Neben der unverzichtbaren README.md-Datei ist auch eine SECURITY.md-Datei ein wichtiger Schritt, um die Sicherheitslage Ihres Projekts zu verbessern. Diese spezielle Datei dient als zentrale Anlaufstelle für wichtige Sicherheitsinformationen, schafft Transparenz und enthält klare Anweisungen für Mitwirkende und Stakeholder.
Richtlinie zur Offenlegung von Schwachstellen
Legen Sie ein klares Verfahren für Personen fest, die Sicherheitsprobleme entdecken, und benennen Sie eine Anlaufstelle, häufig in Form einer E-Mail-Adresse wie „security@“. Diese Richtlinie fördert eine verantwortungsvolle Offenlegung: Externe können Sicherheitsbedenken sicher melden und werden dazu ermutigt, bei der Verwaltung von Schwachstellen mit Ihnen zusammenzuarbeiten.
Richtlinie für Sicherheitsupdates
Beschreiben Sie, wie das Projekt Informationen über neu entdeckte Sicherheitslücken verbreiten wird. Dazu gehören die Kanäle, über die Benutzer benachrichtigt werden, sowie die Schritte, die sie unternehmen sollten, um diese Probleme zeitnah zu beheben. Eine klar definierte Update-Richtlinie stellt sicher, dass Benutzer informiert bleiben und die nötigen Maßnahmen ergreifen können, um ihre Bereitstellungen abzusichern.
Sicherheitsrelevante Konfiguration
Weisen Sie auf Einstellungen hin, die Benutzer bei der Bereitstellung des Projekts berücksichtigen sollten, um die Sicherheitslage zu beeinflussen. Dieser Abschnitt dient als praktische Anleitung zur Konfiguration von Sicherheitsmaßnahmen und hilft Benutzern, sich über die verfügbaren Möglichkeiten zur Verbesserung der Sicherheit ihrer Bereitstellungen zu informieren.
Bekannte Sicherheitslücken und geplante Verbesserungen
Informieren Sie transparent über bekannte Sicherheitslücken, die noch nicht behoben wurden. Teilen Sie außerdem geplante Sicherheitsverbesserungen mit, die noch nicht umgesetzt wurden. Das fördert eine Kultur der Transparenz und Zusammenarbeit und ermutigt Mitwirkende, sich aktiv an der Verbesserung der Projektsicherheit zu beteiligen.
Die Datei SECURITY.md spielt eine entscheidende Rolle dabei, eine sichere und offene Umgebung für Ihr Projekt zu schaffen. Sie bildet nicht nur die Grundlage für verantwortungsvolle Sicherheitspraktiken, sondern ist auch eine wertvolle Ressource für Beitragende und Nutzer und trägt letztlich zu einem widerstandsfähigeren und sichereren Projektökosystem bei.
Branch-Protection-Regeln verwenden
Branch-Protection-Regeln bieten eine wichtige zusätzliche Sicherheitsebene in einem DevSecOps-Workflow. Sie verhindern unbefugte oder versehentliche Änderungen an sensiblen Teilen Ihrer Codebasis. In diesem Abschnitt erfahren Sie, was Branch-Protection-Regeln sind und wie Sie sie in GitHub einrichten, um die Sicherheit Ihrer Codebasis zu verbessern.
Branch-Protection-Regeln in GitHub umfassen eine Reihe von Kontrollen, mit denen Repository-Admins die Codequalität sicherstellen und die Zusammenarbeit verwalten können. Damit lässt sich genau festlegen und durchsetzen, wie Codeänderungen in einen Branch übernommen werden. Dies ist ein entscheidender Aspekt der Anwendungs- und Codesicherheit, da so das Prinzip der geringsten Berechtigungen umgesetzt wird: Nur autorisierte Nutzer können Änderungen an der Codebasis vornehmen.
Zu den Kontrollen, die Sie mit Branch-Protection-Regeln durchsetzen können, gehören:
Pull-Request-Reviews vor dem Mergen verlangen: So wird sichergestellt, dass mindestens eine weitere Person die Änderungen prüft und genehmigt, bevor sie in einen geschützten Branch gemergt werden.
Erfolgreiche Statusprüfungen vor dem Mergen verlangen: Damit können Sie sicherstellen, dass alle erforderlichen CI-Tests erfolgreich durchlaufen wurden, bevor der Code gemergt werden kann.
Festlegen, wer in passende Branches pushen darf: Damit bestimmen Sie, welche Nutzer oder Teams in einen geschützten Branch pushen dürfen, und
Eine lineare Commit-Historie erzwingen: So bleibt die Commit-Historie übersichtlich und leicht verständlich.
Branch-Protection-Regeln einrichten
Gehen Sie wie folgt vor, um Branch-Protection-Regeln in GitHub einzurichten:
Rufen Sie Ihr GitHub-Repository auf und wechseln Sie zum Tab Settings.
Klicken Sie in der linken Seitenleiste auf Branches.
Klicken Sie unter Branch protection rules auf Add rule.
Geben Sie im Feld Branch name pattern den Namen des Branches ein, den Sie schützen möchten.
Wählen Sie unter Protect matching branches die Anforderungen aus, die Sie durchsetzen möchten. Sie können aus den oben genannten Optionen wählen.
Klicken Sie auf Create, um Ihre neue Branch-Protection-Regel zu speichern.
Der gezielte Einsatz von Branch-Protection-Regeln kann die Sicherheit und Zuverlässigkeit Ihrer Codebasis deutlich verbessern. Aus Sicherheitsgründen können Sie in den meisten bei Snyk verwendeten Repositories nicht direkt in den Main-Branch pushen, sondern müssen einen PR verwenden. Dies wird durch Branch-Protection-Regeln durchgesetzt.
SSH-Tokens und persönliche Schlüssel regelmäßig erneuern
Das regelmäßige Erneuern von SSH-Tokens und persönlichen Schlüsseln ist eine wichtige Maßnahme, um die Codesicherheit in Ihren GitHub-Repositories zu erhöhen. In diesem Abschnitt erfahren Sie, wie Sie dabei vorgehen und warum das für Anwendungs- und Container-Sicherheit sowie DevSecOps wichtig ist.
Das Erneuern von SSH-Tokens und persönlichen Schlüsseln ist eine proaktive Sicherheitsmaßnahme, die unbefugten Zugriff auf Ihre GitHub-Repositories verhindert. Sollten sich Angreifer Zugang zu Ihrem SSH-Token oder Ihren persönlichen Schlüsseln verschaffen, können sie in Ihrer Codebasis erheblichen Schaden anrichten. Durch regelmäßiges Erneuern dieser Zugangsdaten erschweren Sie es Angreifern, dauerhaft auf Ihre Repositories zuzugreifen, und verbessern so die Open-Source-Sicherheit.
SSH-Tokens und persönliche Schlüssel erneuern
GitHub bietet ein einfaches Verfahren, um SSH-Tokens und persönliche Schlüssel zu erneuern. Gehen Sie dazu wie folgt vor:
Melden Sie sich bei Ihrem GitHub-Konto an.
Gehen Sie zu Settings, dann zu Developer settings und anschließend zu Personal access tokens.
Klicken Sie auf Generate new token.
Geben Sie Ihrem Token eine Beschreibung und wählen Sie die Bereiche (oder Berechtigungen) aus, die Sie diesem Token gewähren möchten.
Klicken Sie auf Generate token.
Ersetzen Sie nach dem Erstellen eines neuen Tokens unbedingt das alte Token an allen Stellen, an denen es verwendet wird.
Token- und Schlüsselrotation automatisieren
Für Teams mit zahlreichen Repositories oder umfangreichen DevOps-Umgebungen kann das manuelle Erneuern von SSH-Tokens und Schlüsseln eine große Herausforderung sein. Durch die Automatisierung dieses Prozesses sichern Sie eine einheitliche Vorgehensweise und sparen Zeit. Sie können GitHub Actions oder CI/CD-Pipeline-Tools wie Jenkins verwenden, um die Rotation zu automatisieren.
Zusammenfassend lässt sich sagen: Das regelmäßige Erneuern von SSH-Tokens und persönlichen Schlüsseln ist entscheidend für die Sicherheit Ihrer GitHub-Repositories. Dabei geht es nicht darum, Ihnen das Leben schwer zu machen, sondern darum, Ihren Code vor unbefugtem Zugriff zu schützen.
Abhängigkeiten automatisch aktualisieren
Eine aktuelle und sichere Codebasis ist für Anwendungs- und Codesicherheit, Container-Sicherheit sowie DevSecOps von zentraler Bedeutung. Dazu gehört vor allem, Abhängigkeiten regelmäßig zu aktualisieren. In veralteten Drittanbieter-Bibliotheken werden häufig Sicherheitslücken entdeckt. Daher benötigen Sie eine Strategie, mit der Sie Abhängigkeiten automatisch aktualisieren und das Risiko von Sicherheitsverletzungen minimieren können. In diesem Abschnitt erfahren Sie, warum die Aktualisierung von Drittanbieter-Bibliotheken wichtig ist und wie Sie diesen Prozess mit Tools wie Snyk automatisieren können.
Drittanbieter-Bibliotheken sind ein wichtiger Bestandteil der Softwareentwicklung. Sie ersparen Entwicklerinnen und Entwicklern, das Rad neu zu erfinden, indem sie bereits von anderen geschriebenen Code wiederverwenden können. Werden diese Bibliotheken jedoch nicht richtig verwaltet, können sie zu einem Schwachpunkt in Ihrer Sicherheitskette werden. Sie können veralten und erhebliche Sicherheitsrisiken bergen, wenn sie Schwachstellen enthalten, die in neueren Versionen behoben wurden.
Abhängigkeiten manuell zu aktualisieren, kann eine schwierige und zeitaufwendige Aufgabe sein – besonders bei großen Projekten. Hier kommt die Automatisierung ins Spiel.
Abhängigkeits-Updates mit Snyk automatisieren
Snyk ist ein leistungsstarkes Tool, das Schwachstellen in Ihren Abhängigkeiten erkennt und behebt. Neben dem Scannen auf Schwachstellen kann Snyk auch die Aktualisierung Ihrer Abhängigkeiten automatisieren.
Nach der Integration mit GitHub scannt Snyk Ihre Repositories nach veralteten Abhängigkeiten und verwundbaren Bibliotheksversionen. Anschließend erstellt Snyk Pull Requests (PRs) mit Updates für diese Abhängigkeiten, die Sie einfach prüfen und mergen können.
Nachdem Sie GitHub mit Ihrem Snyk-Konto verbunden haben, vergewissern Sie sich, dass die Option Automatic dependency upgrade pull requests unter Integration Settings auf Organisationsebene oder in den Project Settings aktiviert ist.

Snyk überwacht nun Ihre Repositories und erstellt PRs für veraltete Abhängigkeiten. So können Sie Ihre Codebasis einfacher sicher und aktuell halten.

Zusammenfassend lässt sich sagen: Die Automatisierung von Abhängigkeits-Updates ist eine Best Practice, die alle Entwicklerinnen und Entwickler sowie DevOps-Fachkräfte übernehmen sollten. Sie verbessert nicht nur die Sicherheit Ihrer Anwendungen, sondern spart langfristig auch Zeit und Aufwand. Mit Tools wie Snyk können Sie Sicherheitslücken in Drittanbieter-Bibliotheken frühzeitig erkennen und Ihre Codebasis sicher und in gutem Zustand halten.
Sensible Daten in privaten Repositories speichern
Es ist wichtig zu wissen, wie Sie sensible Daten auf Plattformen wie GitHub verwalten. Eine der einfachsten Möglichkeiten, sie zu schützen, ist die Nutzung privater Repositories. In diesem Abschnitt erfahren Sie, worin sich öffentliche und private Repositories unterscheiden und wann sich private Repositories am besten eignen.
GitHub bietet zwei Arten von Repositories: öffentliche und private.
Öffentliche Repositories: Wie der Name schon sagt, sind diese Repositories für alle sichtbar. Jeder GitHub-Nutzer kann ein öffentliches Repository ansehen, klonen und forken. Änderungen pushen können jedoch nur die Mitwirkenden des Repositorys. Diese Offenheit fördert die Zusammenarbeit und die Open-Source-Entwicklung.
Private Repositories: Private Repositories sind nur für den Repository-Inhaber und die von ihm ausdrücklich hinzugefügten Mitwirkenden sichtbar. Selbst wer die URL eines privaten Repositorys kennt, kann dessen Inhalte ohne die erforderlichen Berechtigungen nicht sehen.
Wann Sie private Repositories verwenden sollten
Öffentliche Repositories eignen sich hervorragend für Open-Source-Projekte und die gemeinsame Entwicklung, sind aber nicht für sensible Daten geeignet. In folgenden Fällen sollten Sie private Repositories in Betracht ziehen:
Sensible Daten schützen: Enthält Ihre Codebasis sensible Daten wie API-Schlüssel, Passwörter oder vertrauliche Informationen, sollten Sie diese in einem privaten Repository speichern. So stellen Sie sicher, dass nur autorisierte Mitwirkende darauf zugreifen können.
Proprietärer Code: Wenn Ihre Codebasis proprietär ist und nicht öffentlich zugänglich sein soll, ist ein privates Repository die richtige Wahl. Das ist häufig bei Geschäftsanwendungen und Premium-Softwareprodukten der Fall.
Entwicklungsphase: Wenn sich Ihr Projekt noch in einer frühen Entwicklungsphase befindet und noch nicht für die Öffentlichkeit bereit ist, sollten Sie es in einem privaten Repository speichern. So können Sie während der Entwicklung kontrollieren, wer Zugriff auf das Projekt hat.
Die Erstellung öffentlicher Repositories deaktivieren
Um die Sicherheit zu erhöhen und sensible Informationen zu schützen, sollten Organisationen, die keine öffentlichen Repositories benötigen, den öffentlichen Zugriff vollständig deaktivieren. Diese proaktive Maßnahme verhindert, dass versehentlich öffentlich zugängliche Repositories erstellt werden, und verringert so das Risiko, dass Daten offengelegt werden. Wenn Organisationen über den Navigationspfad Your Organizations, Settings und anschließend Member Privileges private Repository-Einstellungen durchsetzen, stellen sie sicher, dass ausschließlich autorisierte Nutzer auf die Repositories zugreifen können. Das entspricht nicht nur den Best Practices für den Datenschutz, sondern vereinfacht auch die Repository-Verwaltung und sorgt für eine sicherere und besser kontrollierte Umgebung für den Code der Organisation.
Zusammenfassend lässt sich sagen: Die Nutzung privater Repositories für sensible Daten ist eine entscheidende Best Practice für die GitHub-Sicherheit. Sie schützt sensible Daten und proprietären Code und stärkt damit Ihre Codesicherheit und DevSecOps-Praktiken.
GitHub-Apps mit Bedacht auswählen
Bei GitHub-Apps ist eine sorgfältige Auswahl wichtig. Diese von verschiedenen Anbietern entwickelten Anwendungen bieten viele nützliche Funktionen. Bevor Sie sie nutzen, sollten Sie jedoch einige wichtige Punkte beachten:
Berechtigungen prüfen: Geben Sie Berechtigungen nicht leichtfertig frei. Erteilen Sie nur die unbedingt erforderlichen. Ein möglichst eingeschränkter Zugriff minimiert unnötige Risiken.
Zugriffsrechte hinterfragen: Prüfen Sie bei weitreichenden Zugriffsrechten genau, ob diese notwendig sind. Bewerten Sie, welche Folgen es hätte, wenn sich die Umstände ungünstig entwickeln. Es geht darum, Risiken mit Augenmaß einzugehen.
Herkunft prüfen: Prüfen Sie sorgfältig, wer hinter einer App steht, bevor Sie sie in Ihre Entwicklungsumgebung integrieren. Untersuchen Sie, ob die Entwickler vertrauenswürdig sind. Gehen Sie dabei vor wie bei der Auswahl eines neuen Teammitglieds – Vertrauen ist entscheidend.
Sicherheit überprüfen: Betrachten Sie die Sicherheit einer App als erste Verteidigungslinie für Ihren Code. Jede Schwachstelle kann Ihren Code verwundbar machen. Prüfen Sie die Sicherheitsmaßnahmen sorgfältig, um für einen robusten Schutz zu sorgen.
Regelmäßig überprüfen: Regelmäßige Kontrollen sind unverzichtbar. Prüfen Sie in regelmäßigen Abständen, ob Ihre Apps weiterhin benötigt werden und vertrauenswürdig sind. So halten Sie Ordnung in Ihrer Codeumgebung.
Die Sicherheit Ihres Codes ist eine ernste Angelegenheit. Bleiben Sie wachsam, treffen Sie wohlüberlegte Entscheidungen und sorgen Sie dafür, dass Ihre Anwendungen stabil und sicher bleiben.
Fazit
Zusammenfassend haben wir die entscheidende Rolle beleuchtet, die GitHub in der modernen Softwareentwicklung spielt, und erklärt, wie wichtig robuste Best Practices für die Sicherheit sind. Die zehn Richtlinien, die wir besprochen haben, bilden eine solide Grundlage, um Ihre GitHub-Repositories und -Projekte zu schützen. Jede dieser Maßnahmen ergänzt die anderen und schafft so einen zuverlässigen Schutz vor verschiedensten Bedrohungen und Schwachstellen.
Allen Entwicklerinnen und Entwicklern sowie DevOps-Fachkräften empfehlen wir, diese Best Practices für die Sicherheit ernst zu nehmen. Sicherheit ist nicht nur die Verantwortung eines einzelnen Teams oder einer Person, sondern eine gemeinsame Verpflichtung, die alle Bereiche der Softwareentwicklung und des Betriebs durchdringt.
Wie wir in DevSecOps oft sagen: „Für Sicherheit sind alle verantwortlich.“ Lassen Sie uns alle unseren Beitrag dazu leisten, unsere Anwendungen, Daten und Nutzer bestmöglich zu schützen.
Bleiben Sie im Sinne des kontinuierlichen Lernens stets offen für neue Methoden, Tools und Prozesse, mit denen Sie die Sicherheit Ihrer GitHub-Umgebung weiter verbessern können.
Viel Spaß beim Programmieren und bleiben Sie sicher!

