**[Git](https://git-scm.com/)** ist ein Programm zur Versionskontrolle von Software und ermöglicht das Kollaborieren von mehreren Personen an einem Projekt. Alle Änderungen im Quellcode werden aufgezeichnet und können bei Fehlern zurückgezogen werden um immer stabile Funktionalität zu gewährleisten. Häufig gibt es einen oder mehrere Benutzer oder Organisationen, welche die Kontrolle über ein sogenanntes git *"Repository"* haben in dem sie Änderungen von Mitarbeitern akzeptieren können. Bei Quelloffener Software werden auch Änderungen von anderen, nicht zum Projekt gehörigen Personen akzeptiert.
Git zeichnet zwar Änderungen auf aber von sich aus findet keine automatische Validierung der Änderung statt.
Wenn der Zugang eines Projektmitarbeiters kompromisiert wird, kann es einem Angreifer möglich sein ohne Probleme schädlichen Code in ein Softwareprojekt zu schleußen. Auch kann ein Angreifer einfach eine schädliche Änderung anfragen und falls diese Änderung nicht richtig überprüft wird, könnte sie in das Projekt gelangen.
Der Vorteil von diesem Angriffsvektor gegenüber anderen Methoden ist, dass es eine potenziell größere Gruppe trifft.
Die Ausführbaren Versionen einer Software werden aus dem Quellcode generiert sodass jede Verbreitungsquelle der Software infiziert wird, anstatt nur eine einzige. Auch umgeht diese Methode eine Verteidigungsmethode, bei der der Hash der Software geprüft wird, indem sie vor dem Hashprozess funktioniert.
Git speichert alle Änderungen und Metadaten über jede Änderung im Repository. Somit sollte es also möglich sein anhand von verschiedenen Faktoren eine Wertung für jeden einzelnen Commit zu erstellen der die Auffälligkeit der Änderung im Vergleich zu anderen Änderungen im Repository beschreibt. Dies kann automatisiert passieren und kann auch von Dritten eingesetzt werden, um Repositories zu überwachen, welche man nicht direkt kontrolliert aber mit dem eigenen Projekt zu tun haben.
Wichtig zu erwähnen ist hier, dass es sich dabei nur um eine Auffälligkeit handelt und jede Auffälligkeit manuell geprüft werden muss. Die Nutzererfahrung bei falsch positiven Ergebnissen sollte nur minimal beeinträchtigt werden.
*Das Ziel dieser Arbeit ist nicht praktischer realer Nutzen, denn es existieren bereits ähnliche, weitaus komplexere Konzepte zum Schutz von Repositories. Commits werden meistens schon von mindestens einer anderen Person analysiert, sodass einfach Auffälligkeiten schnell herausgefiltert werden, und echte Angreifer nutzen meist weit **[diskretere](https://nvd.nist.gov/vuln/detail/CVE-2024-3094)** Angriffswege die durch diese Analyse nicht gefunden werden können.*
Solange genug Datenpunkte vorhanden sind, soll das System jedes beliebiges Repository analysieren können, aber um den Anforderungen dieser Arbeit gerecht zu werden und um meine Analysen validieren zu können werde ich ein Beispiel Repository benutzen. Hierbei habe ich mich für das Git Repository von **[SDL](https://www.libsdl.org/)**entschieden.
SDL ist eine Softwarebibliothek für Platformübergreifende Software. Es wird sehr häufig zur Entwicklung von unter anderen Videospielen benutzt, hat 17000 Commits und ist inzwischen 26 Jahre alt.
Zur Extraktion der Daten wird ein Skript über die Roh Ausgabe von Git laufen gelassen und danach noch ein Paar Veränderungen in diesem Dokument vorgenommen,
Interessant ist hier, dass die Commits in Monaten, in welchen eine neue Version der Software veröffentlicht wurde, besonders hoch sind. Auch gibt es einen Commit der angeblich 1970 erstellt wurde. Dies zeigt eine der ersten Möglichkeiten auf, mit der man auffällige Commits erkennen kann.
Man kann theoretisch die Tageszeit des Datensatzes analysieren, allerdings gäbe das keine guten Ergebnisse, da Zeit Zohnen existieren und theoretisch von jedem Land aus commited werden kann. Eine Bewertung der muss daher von den anderen Commits der Person abhängen.
Das Diagramm zeigt das Arithmetische Mittel der Zeiten, wann ein Nutzer einen Commit erstellt hat. Auffällig hier ist, dass trotz der Theoretischen Zeitzonenverteilung ein Großteil der Nutzer zu ähnlichen Zeiten Commited.
Zum bestimmen, von auffälligen Commits sollte die Abweichung von eines Commits von der sonstigen Tageszeit des Nutzers benutzt werden. Hierzu muss ein Nutzer aber schon eine gewisse Menge an Commits haben.
Wenn man die veränderten Dateien visualisiert, ist bemerkbar, dass sehr viele Dateien nur wenig verändert werden.
Im Gegensatz zu der Vorherigen Analyse hat dies hier aber positive Konnotationen, da es aufzeigt das im diesem Datensatz die meisten der ~2000 Dateien nur
wenige Male verändert werden, wodurch jede weitere Veränderung als Auffällig angesehen werden kann.
Signierte Commits existieren, um den Urheber eines Commits festzustellen zu können, sodass keine Commits unter falschen Namen veröffentlicht werden können, Ein Commit der signiert wurde ist somit vertrauenswürdiger als andere Commits. In diesem Datensatz sind die meisten Commits unsigniert, weshalb die Implikationen eines unsignierten Commits eher gering sind.
## 4 Aufstellung eines Prädiktiven Models
Bei der Aufstellung eines Prädiktiven Models ist leider ein Problem aufgetreten, welches ich zeitlich nicht mehr in der Lage war zu korrigieren.
Die Annahme besteht, dass der Datensatz keine schädlichen Einträge enthält und die die einzelnen Einträge ebenfalls nicht gelabeled sind.
Dadurch sind viele ML-Ansätze für diesen Datensatz nicht zu gebrauchen.
Mein gewählter Ansatz wäre ein Isolation Forest gewesen, allerdings hat das Package nicht funktioniert und ich habe zeitlich keine andere Lösung mehr finden können.
## 5 Fazit
Zusammenfassend lässt sich feststellen, dass dieser Datensatz nicht meinen Vorhersagen entsprochen hat.
- Bei der Tageszeit des Commits lässt sich ein deutliches Bias zu Arbeitszeiten in dem Amerikanischen und Europäischen Raum feststellen.
- Wenige Personen nutzen das Signieren von Commits als Sicherheitsfunktion.
- Ein Großteil der Dateien in einem Repository wird nur wenig verändert.
Verbesserte Funktionalität währe durch die Analyse von weiteren Faktoren möglich die nicht in dieser Analyse einbezogen wurden,
da sie zu komplex währen und das Thema dieser Arbeit überschreiten würden.
Zur weiteren Verbesserung wäre eine Änderung der Sprache hilfreich, um eine höhere Geschwindigkeit zu erreichen,
sowie in der Lage zu sein das Programm automatisiert zu nutzen und einzubinden.
Auch sollte die Analyse nicht jedes Mal für das ganze Repository erfolgen, sondern einzeln für neue Commits berechnet werden.
*Ein Dateityp, welcher ein bestimmtes Program zum lesen braucht und nicht in Textform vorhanden ist. Die meisten Bild Dateien sind zum Beispiel Binäre Dateien*
