Quellcode als Untersuchungsgegenstand: Repository, Commit, Branch und Build

Software & Quellcode

Soll Quellcode technisch begutachtet werden, muss zunächst geklärt sein, welcher konkrete Codebestand tatsächlich Untersuchungsgegenstand ist. Ein Verzeichnis mit Quelldateien kann hierfür zu wenig Information enthalten: Repository-Historie, Commit-Zuordnung, lokale Änderungen, Submodule, externe Abhängigkeiten und der tatsächliche Build-Prozess können die Aussagekraft der Untersuchung wesentlich beeinflussen.

Untersuchungsobjekt

Vom Repository zum reproduzierbaren Prüfstand

1 Repository Quelle, Refs und erreichbare Git-Objekte erfassen.

2 Commit Konkretes Objekt und Working-Tree-Zustand bestimmen.

3 Abhängigkeiten Submodule, externe Pakete und Build-Voraussetzungen einbeziehen.

4 Artefakt Repository-Zustand mit dem tatsächlich untersuchten Build verbinden.

Ein Quellcodeordner allein genügt nicht, wenn Repository-Kontext, lokale Änderungen oder Build-Abhängigkeiten die Aussage beeinflussen können.

1. Untersuchungsgegenstand und Repository-Kontext abgrenzen

Die Formulierung „der Quellcode wurde untersucht“ ist für sich genommen noch nicht hinreichend präzise. Technisch relevant ist, welche Dateien, welches Repository, welcher Versionsstand und welche ergänzenden Artefakte tatsächlich zur Verfügung standen.

Abhängig von der Fragestellung kann der Prüfgegenstand deshalb beispielsweise umfassen:

• ein vollständiges Git-Repository,
• einen bestimmten Commit,
• einen dokumentierten Repository-Export,
• Working Tree und Index,
• Submodule,
• Abhängigkeits- und Lock-Dateien,
• Build- und CI-Konfiguration,
• das daraus erzeugte Build-Artefakt.

Repository und Quellcodeordner sind nicht gleichbedeutend

Ein exportierter Ordner kann zwar die Quelldateien eines bestimmten Zustands enthalten, muss aber nicht die Informationen enthalten, mit denen dieser Zustand unabhängig einer Repository-Historie oder einem Commit zugeordnet werden kann.

Ein vollständiges Repository ermöglicht demgegenüber abhängig vom vorhandenen Datenbestand die Untersuchung von Git-Objekten, Referenzen und Historie. Für ein Gutachten sollte deshalb dokumentiert werden, ob ein vollständiges Repository, ein Clone, ein Archiv oder lediglich ein Dateiexport übergeben wurde.

2. Commit, Branch und Tag auf konkrete Objekte zurückführen

Git-Revisionsangaben können konkrete Commit-Objekte beziehungsweise andere Git-Objekte adressieren. Für die Untersuchung kann deshalb die vollständige Objekt-ID eines Commits als technischer Bezugspunkt dokumentiert werden.

Mit git rev-parse --verify <rev>^{commit} kann beispielsweise geprüft werden, ob eine Revisionsangabe im vorhandenen Repository auf ein Commit-Objekt beziehungsweise auf ein zu einem Commit auflösbares Objekt verweist.

Damit wird allerdings nur die Zuordnung innerhalb des untersuchten Repositorys geprüft. Ob genau dieser Commit einem ausgelieferten Build oder einem bestimmten Ereignis zuzuordnen ist, benötigt gegebenenfalls weitere Nachweise.

Branch- und Tag-Namen müssen auf konkrete Objekte zurückgeführt werden

Branches und Tags sind Referenzen beziehungsweise Referenznamen innerhalb des Repositorys. Für eine technische Dokumentation ist daher nicht nur der Name der Referenz relevant, sondern auch die zugehörige Objekt-ID.

git show-ref kann vorhandene Referenzen zusammen mit ihren Objekt-IDs ausgeben. Mit einer Dereferenzierung können insbesondere auch die Ziele annotierter Tags zusätzlich sichtbar gemacht werden.

Dadurch kann beispielsweise dokumentiert werden, worauf refs/heads/main oder refs/tags/v3.2 im untersuchten Repository tatsächlich verweist.

Ein Commit beschreibt nicht zwingend den gesamten vorgefundenen Arbeitsstand

In einer ausgecheckten Arbeitskopie können Änderungen vorhanden sein, die noch nicht Bestandteil des bezeichneten Commits sind. Ebenso können Dateien existieren, die von Git nicht verfolgt werden.

Die offizielle Dokumentation von git status unterscheidet insbesondere: Änderungen zwischen aktuellem HEAD und Index, Änderungen zwischen Index und Working Tree sowie nicht versionierte Dateien.

Für eine Quellcodebegutachtung ist dieser Unterschied wesentlich. Wird nur die Commit-ID dokumentiert, obwohl der tatsächlich untersuchte Working Tree lokale Änderungen enthält, beschreibt die Commit-ID nicht vollständig den vorgefundenen Dateibestand.

3. Working Tree und Git-Objekte dokumentieren

Vor einer inhaltlichen Codeanalyse kann deshalb der Zustand der Arbeitskopie dokumentiert werden. Ein maschinenlesbares Statusformat kann dabei helfen, lokale Änderungen und nicht versionierte Dateien reproduzierbar festzuhalten.

Ein solcher Status ersetzt keine Sicherung der tatsächlich untersuchten Dateien. Er ergänzt vielmehr die Dokumentation, ob der Arbeitsbestand vom bezeichneten Repository-Zustand abweicht.

Git-Objekte können unabhängig von Dateinamen geprüft werden

Mit git cat-file können Eigenschaften und Inhalte von Git-Objekten untersucht werden. Die Git-Dokumentation sieht unter anderem Optionen zur Prüfung der Existenz, zur Ausgabe des Objekttyps und zur Darstellung des Objektinhalts vor.

Für eine technische Untersuchung kann dies beispielsweise verwendet werden, um zu prüfen, ob eine übergebene Objekt-ID im Repository existiert und welchem Objekttyp sie entspricht.

Entscheidend ist dabei nicht, möglichst viele Git-Kommandos auszuführen, sondern die für die konkrete Beweis- oder Prüfungsfrage relevanten Identifikatoren nachvollziehbar zu dokumentieren.

4. Submodule und externe Abhängigkeiten einbeziehen

Ein Softwareprojekt kann Quellcode aus weiteren Git-Repositories als Submodule einbinden. In diesem Fall genügt die Commit-ID des übergeordneten Repositorys allein nicht, um den gesamten tatsächlich benötigten Quellcodebestand als eigenständige Dateien bereitzustellen.

Git dokumentiert für Submodule einen im Superprojekt aufgezeichneten Commit-Bezug. Der tatsächlich ausgecheckte Zustand des Submoduls kann mit diesem aufgezeichneten Zustand verglichen werden.

Für eine vollständige Untersuchung ist deshalb gegebenenfalls auch zu dokumentieren, welche Submodule existieren, auf welche Commit-IDs sie verweisen und ob deren Inhalte tatsächlich vorliegen.

Externe Abhängigkeiten gehören zur Reproduzierbarkeit des Builds

Nicht jeder Bestandteil eines Builds befindet sich als Quellcode im Hauptrepository. Bibliotheken, Pakete, Plugins, Generatoren oder andere Werkzeuge können während des Build-Prozesses zusätzlich eingebunden werden.

Für eine reproduzierbare Untersuchung können deshalb beispielsweise relevant sein:

• Manifest- und Abhängigkeitsdateien,
• Lock-Dateien,
• verwendete Paketquellen,
• Compiler- und Laufzeitversionen,
• Build-Parameter,
• Container- oder Build-Images,
• CI/CD-Konfigurationen.

Welche dieser Informationen tatsächlich erforderlich sind, hängt von der konkreten Fragestellung und vom verwendeten Build-System ab.

5. Repository-Zustand mit dem Build-Artefakt verbinden

Ein Repository-Commit identifiziert einen versionierten Quellcodezustand. Daraus folgt jedoch nicht automatisch, dass ein vorliegendes Binärpaket, Container-Image oder Deployment-Artefakt genau aus diesem Commit erzeugt wurde.

Diese Zuordnung kann je nach Projekt beispielsweise durch Build-Protokolle, CI/CD-Metadaten, Versionsinformationen, Artefakt-Metadaten oder andere dokumentierte Build-Nachweise unterstützt werden.

Fehlt eine solche Verbindung, sollte nicht allein aus identischen Versionsbezeichnungen geschlossen werden, dass Repository-Stand und Build technisch identisch zugeordnet sind.

Welche Informationen sollte die Übernahme dokumentieren?

Für die Untersuchung eines Quellcodebestands kann eine technische Übernahmedokumentation insbesondere folgende Angaben enthalten:

• Herkunft des Repositorys oder Datenbestands,
• Zeitpunkt und Art der Übernahme,
• vollständige Commit- beziehungsweise Objekt-ID,
• vorhandene Branches und Tags,
• Status von Working Tree und Index,
• nicht versionierte Dateien,
• Submodule und deren Commit-Bezüge,
• relevante Abhängigkeits- und Lock-Dateien,
• Build-Konfiguration,
• Hashwerte übernommener Archive oder anderer Untersuchungsartefakte.

Nicht jede Untersuchung benötigt jeden dieser Punkte. Die Dokumentation sollte auf die technische Fragestellung und die mögliche Aussagewirkung abgestimmt werden.

Warum ein ZIP-Export kein vollständiger Ersatz für ein Repository sein muss

Ein Dateiexport kann den Inhalt eines bestimmten Verzeichnisstands dokumentieren. Repository-Objekte, Ref-Beziehungen, Commit-Metadaten, Submodule oder lokale Abweichungen können darin jedoch fehlen.

Für eine reine Inhaltsprüfung kann ein sauber dokumentierter Export ausreichen. Für historische oder provenienzbezogene Aussagen muss dagegen geprüft werden, welche Repository-Informationen für die konkrete Fragestellung benötigt werden.

6. Übergabe, Exporte und Aussagegrenzen

Wird nur ein ZIP-Archiv oder ein kopierter Quellcodeordner übergeben, kann der enthaltene Dateibestand durchaus technisch analysiert werden. Die fehlende Repository-Metainformation kann jedoch bestimmte weitergehende Aussagen begrenzen.

Ohne zusätzliche Nachweise lässt sich aus einem reinen Dateiexport beispielsweise nicht automatisch ableiten, welcher Branch oder Tag zugrunde lag, ob lokale Änderungen vorhanden waren oder welche Historie zu diesem Stand führte.

Diese Einschränkung betrifft nicht zwingend die Möglichkeit einer Codeanalyse, wohl aber die Nachvollziehbarkeit von Herkunft, Version und Entwicklungshistorie.

Technischer Befund und rechtliche Würdigung

Ein technischer Befund kann beispielsweise lauten, dass der übergebene Working Tree Änderungen gegenüber dem dokumentierten Commit enthält, dass ein Submodul auf einen anderen Commit zeigt als im Superprojekt aufgezeichnet oder dass die Herkunft eines Build-Artefakts aus dem bezeichneten Repository-Stand nicht nachgewiesen werden konnte.

Daraus kann fachlich eingeordnet werden, welche Codebasis tatsächlich untersucht wurde und welche Unsicherheiten hinsichtlich Reproduzierbarkeit oder Herkunft bestehen.

Prüffragen

Ist der Quellcode-Prüfstand hinreichend bestimmt?

• Ist das Ursprungs-Repository eindeutig bezeichnet?
• Ist der konkrete Commit beziehungsweise das Git-Objekt dokumentiert?
• Sind relevante Branches, Tags und Refs auf konkrete Objekte zurückgeführt?
• Wurden Index und Working Tree auf lokale Abweichungen geprüft?
• Sind Submodule und externe Abhängigkeiten erfasst?
• Ist die Build-Umgebung soweit erforderlich dokumentiert?
• Kann das untersuchte Artefakt mit dem bezeichneten Quellcodestand verbunden werden?
• Sind Export-, Herkunfts- und Reproduzierbarkeitsgrenzen ausgewiesen?

Weiterführende Beiträge

Welche Unterlagen für eine erste Softwareuntersuchung benötigt werden können, erläutert Welche Unterlagen benötigt ein IT-Sachverständiger bei Streit über Individualsoftware? .

Wie der relevante Versionsstand eines Systems bestimmt werden kann, erläutert Welche Softwareversion muss ein Sachverständiger untersuchen? .

Für den Vergleich eines bestimmten Softwarestands mit dokumentierten Anforderungen siehe Softwaremängel technisch untersuchen: Soll-Ist-Vergleich .

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

Kritische Gegenprüfung und methodische Aussagegrenze

Commit, Branch, Build und tatsächlich ausgeführtes Artefakt sind verschiedene technische Zustände. Eine belastbare Zuordnung muss diese Ebenen über reproduzierbare Referenzen miteinander verbinden.

• Commit ist nicht automatisch Build: Dependencies, Build-Flags, Generatoren, CI-Konfiguration und externe Artefakte können bei gleichem Quellstand unterschiedliche Ergebnisse erzeugen.
• Branchname ist kein unveränderlicher Zustand: Ein Branch kann weiterwandern; für einen Befund ist eine konkrete Commit-ID oder ein anderer unveränderlicher Referenzpunkt erforderlich.
• Build ist nicht automatisch Deployment: Ein erzeugtes Artefakt belegt nicht, dass genau dieses Artefakt in der untersuchten Umgebung produktiv eingesetzt wurde.

Prüfregel: Eine fachliche Schlussfolgerung wird nicht stärker formuliert als die dokumentierte Untersuchungsgrundlage. Plausible Alternativerklärungen, widersprechende Evidenz, nicht untersuchte Bereiche und technische Detection Limits bleiben sichtbar Bestandteil der Aussagegrenze.

Eigene Fachliteratur und Veröffentlichungen

Die folgenden eigenen Arbeiten dienen der fachlichen Vertiefung und methodischen Einordnung. Sie ersetzen keine erforderlichen Primär-, Norm-, Hersteller- oder sonstigen unabhängigen Fachquellen. Unveröffentlichte Manuskripte, Entwürfe und Lehrunterlagen werden hier bewusst nicht als öffentliche Quellen ausgewiesen.

• Eigenes Fachbuch Kritisches Denken in Data Science mit Python – Vom Beobachten zur verantwortbaren Entscheidung

Software- und Quellcode-Gutachten

Wenn ein konkreter Quellcodebestand untersucht werden soll, können Repository, Commit, lokale Änderungen, Submodule, Abhängigkeiten und Build-Nachweise zunächst technisch eingegrenzt werden.

Software-Gutachten ansehen