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.

1. Was ist bei einer Quellcodeprüfung der Untersuchungsgegenstand?

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.

2. 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.

3. Der Commit als reproduzierbarer Bezugspunkt

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.

4. 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.

5. 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.

6. Der Working Tree sollte vor der Analyse dokumentiert werden

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.

7. 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.

8. Submodule sind eigenständige Untersuchungsbestandteile

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.

9. 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.

10. Repository-Zustand und Build-Artefakt müssen technisch verbunden werden

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.

11. 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.

12. Was ist bei einem ZIP- oder Dateiexport zu beachten?

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.

13. 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.

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.

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