**[Git](https://git-scm.com/)** ist ein Program zur Versionskontrolle von Software und vereinfacht das Kollaborieren von mehren Leuten an einem Program. Änderungen im Quellcode werden aufgezeichnet, können zurückgesetzt werden und eine Gesamtverlust des Codes wird größtenteils verhindert.
### 1.1 Angriffsvektor
Zwar zeichnet Git Änderungen auf, allerdings wird aber immer noch darauf vertraut das die Änderungen rechtmäßig und
Vertrauenswürdig sind. Dies bedeuet das zum Beispiel durch eine Account Übernahme schädlicher Quellcode in das Repository gelangen kann, welcher dann von mehreren anderen Computern gebaut und verteilt wird.
### 1.2 Hypothese
Da Git viele Daten speichert sollte es möglich sein diese für ein beliebiges generisches Repository zu Downloaden und dann automatisch zu analysieren. Dies erzeugt hilfreiche Informationen über den generellen Status des Repositories, sowie kann es potentiell Auffällige Commits für eine manuelle Untersuchung heraussuchen.
*Der Sicherheitstechnische Ansatz dieser Arbeit ist eher ein imaginärer Ansatz anstatt eine reale Möglichkeit (Praktischer Nutzen ist aber nicht wirklich das Ziel dieser Arbeit, sodass es ignorierbar ist).
Commits in Open Source Programmen werden generell von mindestens einer Person validiert bevor sie eingeführt werden.
Code Platformen bieten starken Schutz gegen Account Übernahmen und Vandalismus in Repositories.
Wenn ein Angreifer wirklich Code in eine Software einschleußen will ist es weitaus **[diskreter](https://nvd.nist.gov/vuln/detail/CVE-2024-3094)** möglich*
<hr />
## 2 Aufbereitung der Daten
### 2.0 Quelle
Das Ziel ist eine generische Datenanalyse bei der jedes Git Repostorie genutzt werden kann für diese Arbeit habe ich mich aber dafür
entschieden das Git Repository von **[SDL](https://www.libsdl.org/)** zu analysieren.
SDL ist eine Software Bibliothek für Software die Platformübergreifend funktionieren soll. Es wird sehr häufig zur Entwicklung von Videospielen benutzt, hat 17000 Commits und ist inzwischen 26 Jahre alt.
Das spezifische Repository welches benutzt wird kann aber im dieser Arbeit mitgelieferten Quellcode geändert werden.
### 2.1 Variablen
Die Variablen die Ausgelesen werden beinhalten zwei Datensets mit einer 1:n Beziehung, da mehrere Datein in einem Commit verändert werden können
#### commits
- Commit Hash *//Representiert die Id des jeweiligen Commits*
- Name *//Name*
- Email *//Email*
- Time *//Zeitcode wann der Commit erstellt wurde*
- Signed *//Ob dieser Comit mit einem Schlüssel "unterschrieben" wurde*
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*
