2211275
/
dms
1
0
Fork 0
Code Issues 20 Pull Requests Packages Projects 1 Releases Wiki Activity

Merge pull request 'security' (#25) from security into main 

Reviewed-on: #25
pull/26/head
Roman Schöne 2026-06-09 14:50:34 +02:00
parent fc6fb0cd19 1dd75ae541
commit d7598929de
2 changed files with 289 additions and 220 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
DMS_paper15_gitlab.tex
View File

@ -202,8 +202,8 @@
Bei der Wahl von Code-Hosting ist oft GitHub die erste Wahl. GitHub wurde 2008 von Chris Wanstrath, Tom Preston-Werner und Phillip Jeffrey Hyett gegründet. GitHub wurde 2018 für ungefähr 7,5 Milliarden USD an den Software-Giganten Microsoft verkauft \cite{jrHowThis33yearold2018}. Der Code von GitHub selber ist nicht öffentlich zugänglich. Für Github besteht keine Option die Plattform selbst zu hosten. Nutzer sind daran gebunden, unter der Haube, auf Services zuzugreifen, die in Microsoft Azure laufen. \url{github.com} besitzt im Vergleich zu \url{gitlab.com} eine höhere Anzahl an Nutzern für Q4 2025. GitHub hat verdächtige Nutzer und Bots in ihrer Angabe herausgefiltert und kommt auf eine Gesamtanzahl an ca. 179 Millionen Nutzer \cite{GitHubInnovationGraph}. GitLab gibt an, dass von mindestens 50 Millionen Nutzern ausgegangen werden kann \cite{Q4FY2026GitLab}.
Aufgrund der grösseren Nutzerbasis eignet sich GitHub mehr für eine kollaborative Zusammenarbeit an \ac{OSS}. Ein Projekt erreicht mehr Nutzer, die potenziell beitragen können.
GitLab und GitHub teilen sich neben demselben Namenspräfix, ähnliche Mechanismen \cite{gitlab_gitlab_nodate}.\\\\
\ac{CI}/\ac{CD} ist für jeweils beide Plattformen erhältlich. Unter GitHub bieten \textit{GitHub Actions} die Möglichkeit Build-, Test- und Deploymentprozesse zu automatisieren. In GitHub sind diese Abläufe in Form von \textit{Workflows} organisiert. Ein \textit{Workflow} wird durch ein Ereignis ausgelöst. Ein \textit{Workflow} ist in \textit{Jobs} aufgegliedert. \textit{Jobs} beinhalten Anweisungen bspw. in Form von Kommandozeilenskripts, die sequentiell ausgeführt werden. Eine \textit{Action} beschreibt eine Menge an wiederverwendbaren \textit{Jobs}. \textit{Workflows} werden auf einem Server bzw. einem \textit{Runner} ausgeführt. Für GitHub ist auch das eigene Hosten eines \textit{Runners} möglich. Die Verwendung von eigens gehosteten Runnern, sowie der von GitHub bereitgestellten Runnern ist für öffentliche Repositories kostenlos. Für private Repositories existiert ein Zeitbudget.\\\\
Beide Plattformen bieten KI-Assistenten an. Für GitHub existiert \textit{GitHub Copilot} und für GitLab \textit{GitLab Duo Agent}. Aktuell kann \textit{GitHub Copilot} mit einem eingeschränkten Zugriff auf Funktionalitäten, kostenlos verwendet werden. Im Gegensatz ist aktuell eine kostenfreie Nutzung von \textit{GitLab Duo Agent} nicht möglich. Copilot beschränkt sich auf alle Artefakte, die in einem Code-Repository liegen. \textit{GitLab Duo Agent} besitzt einen größeren Kontext, zu dem zusätzlich Dokumentation, Planung und Sicherheit gehören. Aufgrund der Aneignung von \textit{Visual Studio Code} durch Microsoft ist \textit{GitHub Copilot} nativ enthalten. Eine Unterstützung für \textit{GitLab Duo Agent} muss über die offizielle \href{https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow}{Erweiterung} ergänzt werden. Interaktionen mit \textit{GitHub Copilot} werden standardmässig von GitHub zum trainieren und verbessern von KI-Modellen verwendet. UM eine Weiterverarbeitung der Daten zu verhindern muss manuell widersprochen werden. Für beide KI-Assistenten kann das unterliegende Modell variiert werden.\\\\
\ac{CI}/\ac{CD} ist für jeweils beide Plattformen erhältlich. Unter GitHub bieten \textit{GitHub Actions} die Möglichkeit Build-, Test- und Deploymentprozesse zu automatisieren. In GitHub sind diese Abläufe in Form von \textit{Workflows} organisiert. Ein \textit{Workflow} wird durch ein Ereignis ausgelöst. Ein \textit{Workflow} ist in \textit{Jobs} aufgegliedert. \textit{Jobs} beinhalten Anweisungen bspw. in Form von Kommandozeilenskripts, die sequentiell ausgeführt werden. Eine \textit{Action} beschreibt eine Menge an wiederverwendbaren \textit{Jobs}. \textit{Workflows} werden auf einem Server bzw. einem \textit{Runner} ausgeführt. Für GitHub ist auch das eigene Hosten eines \textit{Runners} möglich. Die Verwendung von eigens gehosteten Runnern, sowie der von GitHub bereitgestellten Runnern ist für öffentliche Repositories kostenlos. Für private Repositories existiert ein Zeitbudget. \cite{GitHubcomHelpDocumentation} \cite{gitlab_gitlab_nodate}\\\\
Beide Plattformen bieten KI-Assistenten an. Für GitHub existiert \textit{GitHub Copilot} und für GitLab \textit{GitLab Duo Agent}. Aktuell kann \textit{GitHub Copilot} mit einem eingeschränkten Zugriff auf Funktionalitäten, kostenlos verwendet werden. Im Gegensatz ist aktuell eine kostenfreie Nutzung von \textit{GitLab Duo Agent} nicht möglich. Copilot beschränkt sich auf alle Artefakte, die in einem Code-Repository liegen. \textit{GitLab Duo Agent} besitzt einen größeren Kontext, zu dem zusätzlich Dokumentation, Planung und Sicherheit gehören. Aufgrund der Aneignung von \textit{Visual Studio Code} durch Microsoft ist \textit{GitHub Copilot} nativ enthalten. Eine Unterstützung für \textit{GitLab Duo Agent} muss über die offizielle \href{https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow}{Erweiterung} ergänzt werden. Interaktionen mit \textit{GitHub Copilot} werden standardmässig von GitHub zum trainieren und verbessern von KI-Modellen verwendet. UM eine Weiterverarbeitung der Daten zu verhindern muss manuell widersprochen werden. Für beide KI-Assistenten kann das unterliegende Modell variiert werden. \cite{GitHubcomHelpDocumentation} \cite{gitlab_gitlab_nodate}\\\\
Das Hosten von Code-Schnipseln ist in GitHub als \href{https://gist.github.com/}{Gist} und in GitLab unter \href{https://gitlab.com/dashboard/snippets}{Snippets} möglich. Organisationen können in GitHub ebenfalls abgebildet werden.
\section{CI/CD}
@ -404,6 +404,19 @@ stages:
\subsection{Sicherheit}
Eine eigene GitLab-Instanz kann so konfiguriert werden, dass diese dem US-amerikanischen Sicherheitsstandard \acs{NIST} \acs{SP} 800-53 für Sicherheitskontrolle in Informationssystemen des \acl{NIST} entsprechen \cite{gitlab_gitlab_nodate}. Die Angebote von GitLab, damit die \ac{SaaS}-Version bzw. GitLab.com und GitLab Dedicated sind nach \acs{ISO}/\acs{IEC} 27001:2022 zertifiziert \cite{GitLab16522166}. Diese Norm spezifiziert Anforderungen an Informationssicherheitsmanagement im Kontext von Organisationen. Für dieselben Angebote besitzt GitLab eine Zertifizierung nach Norm \acs{ISO}/\acs{IEC} 27017:2015, welche Richtlinien zur Kontrolle der Informationssicherheit von Cloud-Services festlegt \cite{gitlab_gitlab_nodate}. Es ist zu erwarten, dass diese Norm bald erneuert wird \cite{ISOIEC27017}.
Im folgenden Abschnitt wird darauf eingegangen mit welchen Möglichkeiten wie GitLab vor Angriffen von ausserhalb geschützt werden kann. Die GitLab-Dokumentation unterteilt Schutzmassnahmen in die Kategorien \cite{gitlab_gitlab_nodate}:
\begin{itemize}
\item Anwendungseinstellungen
\item \acs{CI}/\acs{CD} Einstellungen
\item Konfigurationseinstellungen
\item Betriebssystemeinstellungen
\end{itemize}
Innerhalb der Anwendungseinstellungen können Push-Regeln festgelegt werden, sodass unverifizierte Nutzer keinen Code hochladen können. Es kann sichergestellt werden, dass geheime Dateien nicht versehentlich gepusht werden. Ebenso sollen projektspezifische Keys/Schlüssel für Deployment-Prozesse eingerichtet werden. Die Sichtbarkeit von Gruppen, Snippets und Projekten soll als \textit{privat} gesetzt werden. Benutzer können gezwungen werden komplexere Passwörter für ihren GitLab Account zu wählen. Eine 2-Faktor Authentifizierung kann eingerichtet werden. Die Kommunikation mit aussenstehenden Systemen kann konkret festgelegt werden, indem externe Systeme zuerst anhand ihrer IP-Adresse für ausgehende anfragen in GitLab eingetragen werden müssen. Für die GitLab-Instanz kann ein Rate-Limit, mit Ausnahmen für bestimmte Nutzer, eingestellt werden \cite{gitlab_gitlab_nodate}.\\
Für \acs{CI}/\acs{CD}-Pipelines besteht die Möglichkeit sensitive Daten wie bspw. Passwörter oder Tokens in Form von \textit{Secrets} zu speichern. \textit{Secrets} werden durch externe Dienstleister gespeichert. Neben \textit{Secrets} besteht die weniger empfohlene Variante Daten in Form von \textit{CI/CD Variablen} zu speichern. Eine solche Variable kann maskiert werden und wird damit in Logs durch einen definierten Platzhalter ersetzt. Zusätzlich zu einer Maskierung erlaubt GitLab \textit{CI/CD Variablen} verstecken. Die Variable wird nicht mehr auf der Einstellungsseite für \acs{CI}/\acs{CD} angezeigt. Ebenso kann eine Variable geschützt werden, sodass nur auf geschützten Branches Zugriff besteht \cite{gitlab_gitlab_nodate}.\\
Eine GitLab-Instanz kann konfiguriert werden, sodass Nutzer per \ac{SSH} oder über \ac{HTTPS} zugreifen können \cite{gitlab_gitlab_nodate}. Ein Zugang kann auf eine der beiden Protokolle beschränkt werden. \ac{HTTPS} ist meist zugänglicher für Nutzer, da wenig Konfiguration vorgenommen werden muss. Allerdings wird die Authentifizierung per Nutzername und \textit{Access Token} oder Passwort vorgenommen, welche häufig erneut abgefragt werden. \ac{SSH} bietet eine höhere Sicherheit. Es ist sichergestellt, dass keine Daten während der Übertragung unbemerkt verändert werden. Die Konfiguration ist komplexer. \ac{SSH} basiert auf einer \textit{Public-Key}-Infrastruktur, wobei der öffentliche Schlüssel auf GitLab zuvor hinterlegt werden muss \cite{marijanSSHVsHTTPS2025}. GitLab kann ebenso E-Mails versenden und empfangen. Versendete E-mails können mit \ac{S/MIME} versendet signiert werden, um deren Legitimität zu sichern \cite{gitlab_gitlab_nodate}. \ac{S/MIME} ist ein Verschlüsselungsstandard für E-Mails.\\
Die GitLab-Dokumentation bietet zusätzlich Konfigurationen für das unterliegende Betriebssystem, wie \ac{SSH}-Konfiguration, Firewall Einstellungen und Änderungen am Kernel \cite{gitlab_gitlab_nodate}.
\subsection{Kompatibilität}
GitLab als Code-Hosting Plattform ist ausschließlich für Linux-Distributionen erhältlich. Es wird differenziert in die kostenpflichtige Variante \ac{EE} und die kostenlose \ac{CE} erhältlich.
@ -522,6 +535,13 @@ stages:
\acro{TLS}{Transport Layer Security}
\acro{DAG}{Directed Acyclic Graph}
\acro{URL}{Uniform Resource Locator}
\acro{SP}{Special Publication}
\acro{NIST}{National Institute of Standards and Technology}
\acro{ISO}{Internationale Organisation für Normung}
\acro{IEC}{International Electrotechnical Commission}
\acro{HTTPS}{Hypertext Transfer Protocol Secure}
\acro{SSH}{Secure Shell}
\acro{S/MIME}{Secure/Multipurpose Internet Mail Extensions}
\end{acronym}
\printbibliography

485
literatur/dms.bib
View File

File diff suppressed because one or more lines are too long