Websites & Web-Anwendungen
Bei Websystemen ist der für eine Begutachtung relevante Zustand häufig nicht allein im Repository zu finden. Zwischen Quellcode und Browserantwort liegen Build, Deployment, Laufzeitumgebung, Konfiguration, Server- und Cache-Schichten. Für historische Aussagen muss diese Kette soweit wie möglich rekonstruiert werden.
Kurzantwort
Ein Git-Commit bezeichnet einen versionierten Quellcodezustand. Er beweist für sich allein nicht, dass genau dieser Stand zu einem bestimmten Zeitpunkt produktiv ausgeliefert wurde.
Für die Rekonstruktion des Produktivstands können Build-Artefakte, Deployment-Protokolle, Provenienzangaben, Serverzustand, Konfigurationen und beobachtete HTTP-Responses miteinander verbunden werden.
Vom Repository zum tatsächlich ausgelieferten Webzustand
1. Relevanten Produktivstand und Zeitpunkt bestimmen
Zunächst muss feststehen, welcher historische oder aktuelle Betriebszustand für die technische Frage maßgeblich ist.
Der neueste Quellcode ist nicht automatisch der relevante Stand
Eine spätere Änderung kann einen früheren produktiven Zustand nicht ohne Weiteres repräsentieren. Zeitpunkt und Bezug zur konkreten Fragestellung sind deshalb zuerst festzulegen.
Produktiver Zustand umfasst mehr als Anwendungscode
Runtime, Umgebungsvariablen, Serverkonfiguration und ausgelieferte statische Ressourcen können das Verhalten beeinflussen.
2. Quellcode und Build-Artefakt technisch verbinden
Zwischen Repository und produktivem System liegt häufig ein eigenständiger Build-Prozess.
Commit-ID identifiziert nicht automatisch das Build-Artefakt
Der Build kann zusätzliche Abhängigkeiten, Generatoren oder Konfigurationen einbeziehen. Die Verbindung muss durch geeignete Build- oder Provenienznachweise gestützt werden.
Build-Provenienz kann die Nachvollziehbarkeit erhöhen
Provenienzangaben können Informationen über Build-Inputs und Erzeugung enthalten. Ihre Aussagekraft richtet sich nach dem tatsächlich vorhandenen und überprüfbaren Nachweis.
3. Deployment-Ziel und Ausbringungszeitpunkt rekonstruieren
Ein erzeugtes Artefakt ist erst dann Teil des Produktivstands, wenn seine Ausbringung zum Zielsystem nachvollzogen werden kann.
Deployment-Protokolle brauchen System- und Zeitbezug
Ein Zeitstempel ist nur dann aussagekräftig, wenn er einem konkreten Zielsystem, Artefakt und Prozess technisch zugeordnet werden kann.
Teilrollouts können mehrere Produktivstände erzeugen
Parallele Instanzen oder gestufte Rollouts können dazu führen, dass nicht jeder Request zur gleichen Zeit denselben Anwendungsstand erreicht.
4. Hosting-, Runtime- und Cache-Zustand einbeziehen
Der produktive Webzustand kann von Infrastrukturkomponenten außerhalb des eigentlichen Anwendungscodes abhängen.
Webserver und Runtime gehören zur Betriebsumgebung
Versionen und Konfigurationen können Einfluss auf Routing, Fehlerverhalten oder Ausführung haben. Welche Details relevant sind, bestimmt die konkrete Frage.
Caches können ältere oder abweichende Responses ausliefern
HTTP-Caches und vorgeschaltete Systeme können gespeicherte Repräsentationen verwenden. Deshalb muss zwischen Anwendungsstand und tatsächlich ausgelieferter Response unterschieden werden.
| Ebene | Typischer Nachweis | Aussage |
|---|---|---|
| Repository | Commit-ID, Refs, Status | versionierter Quellcodezustand |
| Build | Artefakt, Build-Protokoll, Provenienz | erzeugter Softwarestand |
| Deployment | Zeitpunkt, Ziel, Deployment-Log | Ausbringung eines Artefakts |
| Runtime | Versionen und Konfiguration | Betriebsbedingungen |
| HTTP-Auslieferung | Response, Header, Cacheinformationen | beobachteter Produktivzustand |
5. Historische Nachweise zu einer Evidenzkette verbinden
Kein einzelnes Artefakt muss den vollständigen Produktivstand belegen.
Mehrere unabhängige Nachweise können sich gegenseitig stützen
Repository-Daten, Build-Informationen, Deployment-Logs und gesicherte Live-Befunde können gemeinsam eine stärkere Rekonstruktion ergeben als ein einzelner Nachweis.
Warum ein Git-Commit allein den Produktivstand nicht beweist
Ein Commit dokumentiert einen Git-Objektzustand. Er enthält nicht automatisch den Nachweis, dass daraus ein bestimmtes Artefakt erzeugt und auf ein konkretes Produktivsystem ausgebracht wurde.
Die Verbindung zum Produktivstand benötigt zusätzliche Build-, Deployment- oder Betriebsnachweise.
6. Fehlende historische Zustände als Aussagegrenze behandeln
Historische Webzustände lassen sich nicht immer vollständig wiederherstellen.
Rekonstruktion ist von direkter Beobachtung zu unterscheiden
Wird ein früherer Zustand aus mehreren Nachweisen abgeleitet, muss kenntlich bleiben, welche Teile unmittelbar belegt und welche fachlich rekonstruiert sind.
Ist der Produktivstand technisch nachvollziehbar rekonstruiert?
- Ist der maßgebliche Zeitpunkt bestimmt?
- Ist der relevante Repository-Stand identifiziert?
- Ist ein konkretes Build-Artefakt zuordenbar?
- Existiert ein nachvollziehbarer Build-Bezug?
- Ist das Deployment-Ziel bestimmt?
- Sind Runtime und relevante Konfigurationen berücksichtigt?
- Sind Cache- oder Teilrollout-Einflüsse geprüft?
- Sind rekonstruierte und direkt beobachtete Tatsachen getrennt?
Konstruiertes Beispiel
Ein Commit wurde am Vormittag erstellt, ein Build am Nachmittag und ein Deployment am Abend protokolliert. Erst wenn Build-Artefakt, Deployment-Ziel und produktive Response technisch zusammenpassen, kann der Commit belastbar mit dem Produktivstand verbunden werden.
Das Beispiel dient ausschließlich der methodischen Erläuterung und beschreibt kein reales Mandat oder Kundenprojekt.
Quellen und fachliche Grundlage
- Technische Primärquelle SLSA Specification v1.2 – Provenance . Provenienz von Build-Artefakten und nachvollziehbare Informationen über ihre Erzeugung. Geprüft am 20.10.2026.
- Technische Primärquelle Git – gitrevisions . Revisionen, Objekt-IDs und Referenzbezeichnungen. Geprüft am 20.10.2026.
- Technische Primärquelle Git – git-status . HEAD, Index, Working Tree und nicht versionierte Änderungen. Geprüft am 20.10.2026.
- Technische Primärquelle RFC 9110 – HTTP Semantics . HTTP-Methoden, Statuscodes, Headerfelder, Repräsentationen und Semantik von HTTP-Nachrichten. Geprüft am 20.10.2026.
- Technische Primärquelle RFC 9111 – HTTP Caching . Technische Regeln für HTTP-Caches, Frische, Validierung und gespeicherte Responses. Geprüft am 20.10.2026.
- Eigene Fachliteratur Mathias Ellmann: Von Code zu Lösungen im Software Engineering mit Java . Eigene Fachliteratur als fachlicher Hintergrund im Software Engineering; kein unabhängiger Primärnachweis für die jeweils herangezogene externe Webspezifikation.
- Eigene fachliche Einordnung Die konkrete Untersuchungsstruktur, Auswahl der Belege, Gegenhypothesen und Aussagegrenzen wird aus der jeweiligen technischen Fragestellung und der tatsächlich verfügbaren Untersuchungsgrundlage abgeleitet.
Weiterführende Beiträge
Welche Softwareversion muss ein Sachverständiger untersuchen?
Repository, Commit, Branch und Build
Technischen Webzustand sichern und dokumentieren
Technische Untersuchung von Websites und Web-Anwendungen
Wenn der technische Zustand oder das Verhalten einer Website beziehungsweise Webanwendung untersucht werden soll, können Untersuchungsgegenstand, Prüfstand und relevante Nachweise zunächst sachverständig eingegrenzt werden.
Software-Gutachten ansehen