Welche Softwareversion muss ein Sachverständiger untersuchen?

Software & Quellcode

Welche Softwareversion technisch untersucht werden muss, hängt von der konkreten Fragestellung und dem relevanten Zeitpunkt ab. Der aktuellste Stand eines Repositories ist deshalb nicht automatisch der richtige Prüfgegenstand. Entscheidend ist die nachvollziehbare Zuordnung zwischen dem zu untersuchenden Ereignis, dem damaligen Softwarestand, dem erzeugten Build und der tatsächlich verwendeten Umgebung.

1. Ausgangspunkt ist die technische Fragestellung

Die Frage nach der „richtigen Version“ lässt sich nicht unabhängig vom Untersuchungsauftrag beantworten. Zunächst muss geklärt werden, für welchen technischen Zustand eine Aussage benötigt wird.

Mögliche Bezugspunkte können beispielsweise sein:

• der Stand einer Projektabnahme,
• ein ausgeliefertes Release,
• ein zu einem bestimmten Zeitpunkt produktiv eingesetzter Stand,
• der Zustand beim Auftreten eines konkreten Fehlers,
• eine Version vor oder nach einer bestimmten Änderung,
• ein Quellcodestand, der einem Build oder Deployment zugrunde lag.

Erst wenn dieser Bezug feststeht, kann technisch bestimmt werden, welche Artefakte für die Untersuchung relevant sind.

2. Der neueste Stand ist nicht automatisch der relevante Stand

Software verändert sich im Zeitverlauf. Fehler können behoben, Funktionen ergänzt, Abhängigkeiten aktualisiert oder Konfigurationen geändert werden. Eine spätere Fassung kann deshalb technisch andere Eigenschaften besitzen als die Version, auf die sich eine ursprüngliche Beanstandung bezieht.

Wird ausschließlich der aktuelle Repository-Stand untersucht, obwohl sich die Fragestellung auf eine frühere Auslieferung oder Abnahme bezieht, können zeitlich unterschiedliche Systemzustände miteinander vermischt werden.

3. Commit beziehungsweise Objekt-ID als technischer Bezugspunkt

In einem Git-Repository können Revisionsangaben unter anderem konkrete Commit-Objekte bezeichnen. Ein vollständiger Objektname oder eine innerhalb des Repositories eindeutige Kurzform kann dadurch einen bestimmten Repository-Zustand technisch referenzieren.

Die Git-Dokumentation beschreibt außerdem, dass mit git rev-parse --verify geprüft werden kann, ob eine angegebene Revision auf ein vorhandenes Objekt aufgelöst werden kann. Mit dem Zusatz ^{commit} lässt sich zusätzlich verlangen, dass die Angabe auf ein Commit-Objekt beziehungsweise ein auf einen Commit auflösbares Objekt verweist.

Eine dokumentierte Commit-ID ist deshalb regelmäßig aussagekräftiger als eine bloße Beschreibung wie „Stand aus dem Frühjahr“.

4. Warum ein Branch-Name allein nicht genügt

Ein Branch-Name ist in Git eine Referenz. Er bezeichnet typischerweise das Commit, auf das die entsprechende Referenz aktuell zeigt. Wird auf dem Branch weitergearbeitet, kann sich dieser Bezug verändern.

Die Aussage „untersucht wurde der Branch main“ dokumentiert deshalb für sich genommen keinen dauerhaft bestimmten historischen Softwarestand.

Für eine reproduzierbare Untersuchung sollte zusätzlich festgehalten werden, auf welches konkrete Commit sich der Branch zum relevanten Untersuchungszeitpunkt bezog.

5. Ist ein Tag automatisch unveränderlich?

Auch ein Git-Tag ist zunächst eine Referenz beziehungsweise, bei annotierten Tags, ein eigenes Tag-Objekt mit Bezug zu einem anderen Objekt. Git unterscheidet insbesondere zwischen Lightweight Tags und annotierten Tags.

Die offizielle Git-Dokumentation sieht mit git tag -f ausdrücklich die Möglichkeit vor, einen bereits vorhandenen Tag-Namen zu ersetzen. Ein Tag-Name sollte deshalb nicht allein deshalb als unveränderlicher Nachweis behandelt werden, weil er wie eine Versionsnummer aussieht.

Für eine technische Dokumentation ist es sinnvoll, zusätzlich festzuhalten, auf welches konkrete Objekt der verwendete Tag verweist.

6. Release-Bezeichnung und Repository-Stand sind zu unterscheiden

Eine Bezeichnung wie Version 2.4.1 oder Release 2026-09 ist zunächst eine organisatorische oder technische Versionsbezeichnung. Entscheidend ist, wie diese Bezeichnung dem tatsächlichen Quellcode, einem Commit, einem Tag oder einem erzeugten Softwareartefakt zugeordnet wurde.

Eine Release-Bezeichnung kann ein wichtiger Identifikator sein. Für die technische Nachvollziehbarkeit sollte jedoch dokumentiert werden, wodurch die Zuordnung zum konkreten Untersuchungsgegenstand belegt wird.

7. Quellcodestand und Build-Artefakt sind nicht dasselbe

Ein Commit beschreibt den versionierten Zustand des Repositories. Das tatsächlich ausgeführte Programm kann zusätzlich von Build-Prozess, Compiler oder Laufzeit, Abhängigkeiten, Build-Parametern und eingebundenen Artefakten beeinflusst werden.

Deshalb sollte bei einer Untersuchung, die das tatsächlich ausgelieferte oder ausgeführte System betrifft, soweit möglich auch das konkrete Build-Artefakt beziehungsweise dessen dokumentierte Herkunft berücksichtigt werden.

Ein Quellcode-Commit allein beweist nicht, dass genau aus diesem Stand das untersuchte Binär- oder Deployment-Artefakt erzeugt wurde. Diese Zuordnung benötigt zusätzliche technische Nachweise.

8. Hashwerte können ein Artefakt identifizieren

Für Dateien, Archive, Container-Images oder andere übergebene Artefakte können kryptografische Hashwerte dokumentiert werden. Ein kryptografischer Hashwert kann dabei als technischer Identifikator für das konkret übernommene Artefakt festgehalten werden. Seine Aussagekraft hängt vom verwendeten Hashverfahren und von der gesicherten Zuordnung zum untersuchten Artefakt ab.

Ein Hashwert dokumentiert jedoch nicht automatisch, aus welchem Quellcode ein Artefakt erzeugt wurde oder zu welchem fachlichen Ereignis es gehört. Provenienz und zeitliche Zuordnung müssen gesondert nachvollzogen werden.

9. Der produktive Systemzustand kann über die Softwareversion hinausgehen

Das beobachtete Verhalten einer Anwendung wird nicht ausschließlich vom Quellcode bestimmt. Je nach System können beispielsweise relevant sein:

• Konfigurationsdateien und Umgebungsvariablen,
• Feature Flags,
• Datenbank- und Migrationsstand,
• installierte Bibliotheken und Laufzeitversionen,
• Container-Images,
• Infrastruktur- und Deployment-Konfiguration,
• angebundene Fremdsysteme und Schnittstellen.

Soll ein konkretes Laufzeitverhalten untersucht werden, kann deshalb die bloße Angabe einer Softwareversionsnummer unzureichend sein.

10. Wie lässt sich der relevante Stand dokumentieren?

Abhängig von der Fragestellung kann eine belastbare technische Dokumentation beispielsweise enthalten:

• relevanter Zeitpunkt oder Ereignisbezug,
• Repository und Repository-Quelle,
• vollständige Commit- beziehungsweise Objekt-ID,
• Branch- und Tag-Zuordnung,
• Release-Bezeichnung,
• Build-Nummer oder Build-Protokoll,
• Hashwert des untersuchten Artefakts,
• verwendete Abhängigkeiten,
• Konfigurations- und Umgebungsstand,
• Quelle und Zeitpunkt der Übernahme des Untersuchungsmaterials.

11. Was tun, wenn der ursprüngliche Stand fehlt?

Nicht immer ist der tatsächlich ausgelieferte oder produktiv eingesetzte Softwarestand noch vorhanden. Dann kann geprüft werden, ob sich der relevante Zustand aus Repository-Historie, Tags, Releases, CI/CD-Protokollen, Deployment-Daten, Backups oder anderen technischen Nachweisen rekonstruieren lässt.

Eine solche Rekonstruktion ist vom unmittelbar überlieferten Originalzustand zu unterscheiden. Verbleibende Unsicherheiten, Annahmen und fehlende Artefakte müssen im Untersuchungsergebnis ausdrücklich dokumentiert werden.

12. Befund und rechtliche Würdigung bleiben getrennt

Ein technischer Befund kann beispielsweise lauten, dass ein bestimmtes Build-Artefakt einem dokumentierten Commit nicht eindeutig zugeordnet werden konnte oder dass der untersuchte Commit zeitlich nach einer relevanten Abnahme liegt.

Daraus lässt sich fachlich ableiten, welche technische Aussage mit dem vorhandenen Untersuchungsmaterial möglich ist und wo Unsicherheiten verbleiben.

Weiterführende Beiträge

Welche Unterlagen zur Bestimmung eines konkreten Softwarestands benötigt werden können, erläutert der Beitrag Welche Unterlagen benötigt ein IT-Sachverständiger bei Streit über Individualsoftware? .

Wie ein identifizierter Softwarestand anschließend mit dokumentierten Anforderungen verglichen werden kann, erläutert Softwaremängel technisch untersuchen: Soll-Ist-Vergleich .

Wie Repository, Commit, Working Tree, Submodule und Build für eine konkrete Quellcodeuntersuchung dokumentiert werden können, erläutert der Beitrag Quellcode als Untersuchungsgegenstand: Repository, Commit, Branch und Build .

Der allgemeine methodische Rahmen ist unter Quellen und Methodik dokumentiert.

Software- und Quellcode-Gutachten

Wenn unklar ist, welcher Softwarestand für eine technische Untersuchung relevant ist, können Versionshistorie, Releases, Build-Artefakte und vorhandene Nachweise zunächst eingegrenzt werden.

Software-Gutachten ansehen