**[Git](https://git-scm.com/)** ist ein Program 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 sogennantes 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 aktzeptiert.
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 potentiell 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 funktionert.
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 Aufälligkeit manuell geprüft werden muss. Die Nutzererfahrung bei falsch positiven Ergebnissen sollte nur minimal beinträchtigt werden.
*Das Ziel dieser Arbeit ist nicht praktischer realer Nutzen, denn es existieren bereits ähnliche, weitsaus komplexere Konzepte zum Schutz von Repositories. Commits werden meistens schon von mindestens einer anderen Person analysiert, sodass einfach Aufä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 Software Bibliothek 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.
Die Daten besitzen keine Fehler, müssen allerdings noch interpretiert werden.
**Time** Ist eine Unix Timestamp, also die Zeit in Sekunden seit 1970, da wir für die Analyse aber eher die Tageszeit benötigen müssen die Daten erst umgewandelt werden.
Die vorhergehende Graphik zeigt an, wie viele Commits pro Quartal eines Jahres angefallen sind,
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.
- **Falls die Jahreszahl stark von der Jahreszahl anderer Commits aufweicht ist sie auffällig**
### 3.2 Tageszeit der Commits einer Person
Man kann theoretisch die Tageszeit des Datensatzes analysieren, allerdings gäbe das keine Guten Ergebnisse, da Zeitzohnen existieren und theoretisch von jedem Land aus commited werden kann. Eine Bewertung der muss daher von den anderen Commits der Person abhängen.
```{r warning = FALSE}
times <- aggregate(as.numeric(hm(format(as.POSIXlt(time), "%H %M"))) ~ email, commits, mean)
Das Diagram zeigt das Arithmetische Mittel der Zeiten wann ein Nutzer einen Commit erstellt hat. Aufällig hier ist, dass trotz der Theoretischen Zeitzonenverteilung ein Großteil der Nutzer zu ähnlichen Zeiten Commited.
Dies ist dadurch zu erklären, dass ein Großteil der Nutzer aus den USA bzw. Europa kommt und das somit diese Zeiten besonders häufig vorkommen.
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.
### 3.3 Menge an Commits pro Person
```{r}
```
Die Menge an vorherigen Commits einer Person ist ebenfalls ein Faktor der einberechnet werden kann.
Je weniger commits eine Person besitzt destso aufälliger sollte ein Commit gewertet werden.
Hier zu bedenken ist, dass die Zahl der Commits einer Person bei 0 startet und langsam wächst,
nur weil eine Person wenig Commits hat, heißt das also nicht das ein Commit schädlich ist, es kann lediglich ein Faktor sein.
### 3.4 Dateien die Geändert wurden
Wir können geänderte Dateien in den Zusammenhang miteinander setzen um auffälige Muster zu finden,
wenn Dateien geändert werden die sonst nicht zusammen geändert werden.
### 3.5 Unterzeichnete Commits
```{r}
```
Signierte Commits existieren um den Urheber eines Commits festzustellen zu können, sodass keine Commits unter falschen Namen veröffentlicht werden können, ohne das dass System des Nutzers gehackt wurde. Ein Commit der signiert wurde ist somit vertrauenswürdiger als andere Commits, aber falls ein Nutzer der sonst nie Signiert plötzlich Signiert sollte dies auch einberechnet werden.
## 4 Ausblick
- Diagramme für andere Faktoren fertigstellen
- Datensatz transformieren um besser für die ML nutzbar zu sein
- ML Ansatzum für jeden Commit einen Confidence Score generieren
*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*
