Git-Historie und Software-Provenienz technisch untersuchen

Software & Quellcode

Eine Git-Historie kann gespeicherte Softwarestände, Objektbeziehungen und Entwicklungsschritte technisch nachvollziehbar machen. Sie ist jedoch kein vollständiges Protokoll sämtlicher tatsächlichen Entwicklungsvorgänge. Für eine sachverständige Untersuchung müssen deshalb Git-Befund, technische Interpretation und weitergehende Schlussfolgerung voneinander getrennt werden.

1. Was bedeutet Software-Provenienz?

Provenienz beschreibt im technischen Kontext die nachvollziehbare Herkunft eines Softwareartefakts. Je nach Fragestellung kann dies verschiedene Ebenen betreffen: den versionierten Quellcode, den Repository-Zustand, den Build-Prozess, verwendete Eingaben und Abhängigkeiten sowie das schließlich erzeugte Artefakt.

Für eine Untersuchung ist deshalb zunächst zu bestimmen, welche Provenienzfrage tatsächlich beantwortet werden soll. Die Frage „Aus welchem Commit wurde dieses Artefakt gebaut?“ ist technisch eine andere als „Woher stammt diese konkrete Implementierung?“ oder „Ist diese Software aus einer anderen Codebasis abgeleitet?“

2. Welche Informationen enthält ein Git-Commit?

Ein Git-Commit referenziert einen Tree, der einen gespeicherten Verzeichniszustand repräsentiert. Zusätzlich enthält ein Commit unter anderem Parent-Beziehungen sowie Autor- und Committer-Metadaten.

Diese Struktur ermöglicht es, gespeicherte Zustände und ihre Beziehungen technisch zu rekonstruieren. Für eine Untersuchung können beispielsweise folgende Größen relevant sein:

• vollständige Commit-Objekt-ID,
• referenzierter Tree und zugehörige Dateiobjekte,
• Parent- beziehungsweise Merge-Beziehungen,
• vorhandene Branch- und Tag-Referenzen,
• Autor- und Committer-Metadaten,
• gespeicherte Commit-Nachricht,
• Unterschiede zu vorangegangenen oder nachfolgenden gespeicherten Zuständen.

Wichtig ist die begriffliche Präzision: Eine Commit-Nachricht ist eine gespeicherte Information. Sie ist nicht allein deshalb eine unabhängig bestätigte Tatsachenbeschreibung ihres Inhalts.

3. Was kann eine Git-Historie technisch belegen?

Innerhalb der tatsächlich verfügbaren Repository-Grundlage können unter anderem gespeicherte Zustände, Objektidentitäten und historische Beziehungen reproduzierbar untersucht werden.

Abhängig vom vorhandenen Material lassen sich etwa folgende technische Fragen beantworten:

• Ist ein bestimmter Dateiinhalt in einem bezeichneten Commit vorhanden?
• Auf welches Git-Objekt zeigt ein bestimmter Tag?
• Welche Commits bilden die gespeicherte Parent- oder Merge-Historie?
• Wann ist eine Datei innerhalb der erreichbaren Historie erstmals feststellbar?
• Welche gespeicherten Änderungen liegen zwischen zwei bestimmten Zuständen?
• Wurde eine Datei verschoben, umbenannt, gelöscht oder später erneut eingebracht?
• Welche Branches, Tags und sonstigen Referenzen sind in der Untersuchungsgrundlage erreichbar?
• Weicht ein vorgefundener Working Tree vom bezeichneten Commit ab?

4. Was beweist eine Git-Historie nicht automatisch?

Git dokumentiert gespeicherte Repository-Zustände. Daraus darf nicht ohne weitere Evidenz geschlossen werden, dass die Historie sämtliche tatsächlichen Arbeitsschritte vollständig abbildet.

Insbesondere können je nach Untersuchungsgrundlage außerhalb des technisch nachweisbaren Bereichs liegen:

• nie eingecheckte lokale Entwicklungsstände,
• nie bereitgestellte oder nie gepushte Repository-Inhalte,
• bereits nicht mehr erreichbare oder entfernte Git-Objekte,
• externe Dateien, Dokumente oder Quelltexte,
• persönliche Kommunikation und nicht versionierte Arbeitsunterlagen,
• ausschließlich im Wissen oder in der Erinnerung einer Person vorhandene Einflüsse,
• die tatsächliche Person, die einen unter einem bestimmten Namen gespeicherten Inhalt erstellt hat.

5. Repository-Historie und Inhaltsvergleich sind unterschiedliche Evidenzebenen

Eine Provenienzprüfung sollte historische und inhaltliche Evidenz nicht vermischen. Zwei Dateien können technisch identisch sein, ohne dass aus der Identität allein hervorgeht, auf welchem Weg dieser Zustand entstanden ist.

Umgekehrt kann eine Repository-Historie eine nachvollziehbare Entwicklung zeigen, obwohl einzelne Implementierungen fachlich ähnliche Strukturen besitzen, weil beide Systeme dieselben Standards, Frameworks oder fachlichen Anforderungen umsetzen.

Deshalb können – abhängig von der Fragestellung – mehrere Untersuchungsverfahren kombiniert werden:

• exakte Inhalts- und Hashvergleiche,
• normalisierte Textvergleiche,
• token- oder cloneorientierte Verfahren,
• Vergleich charakteristischer Kommentare, Strings und Bezeichner,
• API-, Datenmodell- und Konfigurationsvergleich,
• Architektur- und Modulvergleich,
• historische Einordnung der Fundstellen in der erreichbaren Git-Historie.

6. Befund, Interpretation und Bewertung müssen getrennt bleiben

Für nachvollziehbare technische Begutachtung ist es zweckmäßig, unterschiedliche Erkenntnisebenen ausdrücklich auseinanderzuhalten.

Eine solche Trennung verhindert, dass aus einem technisch korrekten Einzelbefund eine weitergehende Behauptung entsteht, die durch den Befund selbst nicht getragen wird.

7. Mit konkurrierenden Erklärungen arbeiten

Bei komplexen Herkunftsfragen sollte nicht nur nach Belegen für eine zunächst naheliegende Hypothese gesucht werden. Ebenso wichtig sind alternative Erklärungen und mögliche Gegenbefunde.

Bei einer auffälligen Codeähnlichkeit können beispielsweise konkurrierende Erklärungen sein:

• unmittelbare Übernahme oder Ableitung,
• unabhängige Entwicklung aufgrund identischer Fachanforderungen,
• gemeinsame Nutzung desselben Frameworks oder Standards,
• Dritt- oder Vendor-Code,
• generierte Artefakte,
• allgemein verbreitete Implementierungsmuster,
• gemeinsame externe Informationsquellen.

Eine belastbare technische Einordnung sollte deshalb auch untersuchen, welche Beobachtungen eine Arbeitshypothese schwächen oder widerlegen würden.

8. Reproduzierbarkeit der Provenienzprüfung

Eine technische Schlussfolgerung gewinnt an Nachvollziehbarkeit, wenn zentrale Untersuchungsschritte bei derselben Untersuchungsgrundlage durch fachkundige Dritte überprüft werden können.

Dokumentiert werden können insbesondere:

• vollständige Repository- und Commit-IDs,
• untersuchte Branches, Tags und sonstige Refs,
• Working-Tree-Status,
• relevante Hashwerte,
• Werkzeugversionen,
• Filter- und Ausschlussregeln,
• Parameter und Schwellwerte automatisierter Verfahren,
• technische Fundstellen und Ergebnisartefakte.

Reproduzierbarkeit bedeutet dabei nicht, dass jede fachliche Bewertung automatisiert werden kann. Sie bedeutet zunächst, dass die technische Grundlage und die wesentlichen Untersuchungsschritte transparent nachvollzogen werden können.

9. Build-Provenienz erweitert die Betrachtung

Zwischen versioniertem Quellcode und ausgelieferter Software können Build-Prozess, Abhängigkeiten, Konfigurationen und externe Werkzeuge liegen. Deshalb kann die Repository-Historie allein für bestimmte Fragestellungen zu kurz greifen.

Moderne Software-Supply-Chain-Ansätze behandeln Provenienz daher auch als Information darüber, aus welchen Eingaben, durch welchen Build-Prozess und auf welcher Build-Plattform ein Softwareartefakt erzeugt wurde.

Für eine konkrete technische Prüfung ist zu unterscheiden, ob eine solche Build-Provenienz tatsächlich vorliegt und welche Vertrauensaussage ihr Format, ihre Signierung und ihre technische Entstehung tragen.

10. Besondere Grenzen bei KI-unterstützter Softwareentwicklung

Die Nutzung generativer Entwicklungswerkzeuge ändert die Grundanforderung an technische Evidenz nicht. Ein finaler Quellcodebestand zeigt zunächst, welcher Inhalt untersucht wird.

Aus dem finalen Code allein lässt sich regelmäßig nicht zuverlässig rekonstruieren, welcher einzelne Teil durch einen KI-Assistenten, durch manuelle Entwicklung, durch eine Vorlage oder durch eine andere Quelle entstanden ist.

Soll der Einsatz solcher Werkzeuge untersucht werden, können deshalb zusätzliche Informationsquellen erforderlich sein, beispielsweise dokumentierte Entwicklungsrichtlinien, Werkzeugkonfigurationen, gespeicherte Nutzungsspuren oder andere tatsächlich verfügbare Projektartefakte.

11. Technische Fragestellungen präzise formulieren

Für Gerichte, Rechtsanwälte und Auftraggeber ist es hilfreich, eine technische Frage so zu formulieren, dass Untersuchungsgegenstand und mögliche Nachweise erkennbar werden.

Technisch untersuchbar können beispielsweise Fragen sein wie:

• Welche Softwarestände sind in den bereitgestellten Repository-Daten nachweisbar?
• In welchem erreichbaren Git-Zustand erscheint ein bestimmtes technisches Artefakt?
• Welche inhaltlichen Übereinstimmungen bestehen zwischen zwei bezeichneten Codebeständen?
• Welche alternative technische Erklärung kommt für eine festgestellte Übereinstimmung in Betracht?
• Welche Nachweisgrenzen ergeben sich aus fehlenden oder nicht erreichbaren Datenbeständen?

12. Fazit

Git-Historie und Software-Provenienz können eine leistungsfähige technische Grundlage für die Rekonstruktion von Softwareständen und Entwicklungsbeziehungen bilden. Entscheidend ist jedoch, die Reichweite der vorhandenen Evidenz nicht zu überschätzen.

Eine nachvollziehbare Begutachtung bestimmt deshalb zunächst die konkrete Untersuchungsgrundlage, trennt objektiven Befund von Interpretation und Bewertung, prüft alternative Erklärungen und dokumentiert verbleibende Aussagegrenzen.

Weiterführende Beiträge

Wie ein konkreter Quellcodebestand für eine Untersuchung festgelegt wird, erläutert Quellcode als Untersuchungsgegenstand: Repository, Commit, Branch und Build .

Zur Eingrenzung einer technischen Beweisfrage siehe Technische Fragestellung für ein IT-Gutachten .

Der allgemeine Quellen- und Dokumentationsstandard ist unter Quellen und Methodik beschrieben.

Software- und Quellcode-Gutachten

Wenn Repository-Stände, Git-Historien oder technische Herkunftsfragen untersucht werden sollen, können Untersuchungsgrundlage, technische Befunde und Aussagegrenzen zunächst nachvollziehbar eingegrenzt werden.

Software-Gutachten ansehen