Gutachten & Methodik
Technische Systeme verändern sich fortlaufend. Ohne eindeutige Systemgrenze und Versionszuordnung bleibt offen, worauf ein Befund tatsächlich bezogen ist. Deshalb wird der Untersuchungsgegenstand vor der Analyse so beschrieben, dass ein fachkundiger Dritter denselben technischen Zustand möglichst eindeutig identifizieren kann.
Kurzantwort
Zum Untersuchungsgegenstand gehören nicht nur Produkt- oder Projektnamen. Je nach Frage sind Repository, Commit oder Tag, Build-Artefakt, Release, Laufzeitkonfiguration, Datenbestand, Infrastruktur, Gerät, Browser oder Modellversion festzuhalten. Aussagekraft und Reproduzierbarkeit hängen unmittelbar von dieser Zustandsbindung ab.
Vom Prüfgegenstand zur dokumentierten technischen Schlussfolgerung
1. Der Name eines Systems reicht nicht aus
Bezeichnungen wie „Produktivsystem“, „App Version 4“ oder „aktueller Code“ sind für sich genommen häufig zu ungenau. Parallel existierende Branches, Hotfixes, Umgebungen, Feature Flags, Datenmigrationen und Konfigurationen können technisch unterschiedliche Zustände erzeugen.
Die Beschreibung sollte daher die für die Fragestellung relevanten Identifikatoren enthalten. Bei Software sind dies etwa Repository und Revision, bei ausgelieferten Artefakten Hashwert und Build-Information, bei Websystemen Deployment-Zeitpunkt und Umgebung, bei Datenanalysen Datensatzversion und Transformationsstand.
Welche Merkmale erforderlich sind, hängt von der technischen Frage ab. Es geht nicht um maximale Inventarisierung, sondern um eine eindeutige Bindung der späteren Befunde an den tatsächlich untersuchten Zustand.
2. Systemgrenze und abhängige Komponenten
Viele IT-Sachverhalte entstehen nicht in einer einzelnen Datei oder Anwendung. Frontend, Backend, API, Datenbank, externe Dienste, Identitätsprovider, Betriebssystem und Infrastruktur können gemeinsam das beobachtete Verhalten bestimmen.
Die Systemgrenze sollte deshalb explizit machen, welche Komponenten einbezogen und welche nur als Umgebung dokumentiert werden. Wird beispielsweise nur ein Frontend-Build untersucht, kann daraus keine vollständige Aussage über ein serverseitiges Verhalten abgeleitet werden.
Abhängigkeiten sind besonders relevant, wenn Versionen nicht gemeinsam ausgeliefert werden. Ein Client kann mit mehreren Backendständen interagieren; ein Modell kann über einen Gateway-Dienst ausgetauscht werden; eine WordPress-Seite kann durch Plugin-, Theme- und Core-Versionen geprägt sein.
3. Versionen, Revisionen und Artefakte
Versionsnummern sind nützlich, aber nicht immer eindeutig. Ein Git-Commit bezeichnet einen konkreten Repository-Zustand im Objektgraphen; Tags und Branch-Namen sind dagegen Referenzen, deren Ziel sich je nach Arbeitsweise ändern kann. Für eine reproduzierbare Untersuchung sollten deshalb auflösbare Objekt-IDs und relevante Refs dokumentiert werden.
Bei Build-Artefakten kann zusätzlich ein kryptographischer Hashwert verwendet werden, um die untersuchte Datei später wiederzuerkennen. Build-Provenienz kann Hinweise auf Eingaben und Erstellungsprozess liefern, ersetzt aber nicht die Prüfung, ob entsprechende Nachweise für das konkrete Projekt tatsächlich vorhanden und vertrauenswürdig sind.
Bei SaaS- und Cloud-Systemen kann ein einzelner Versionsstring fehlen. Dann werden Zeitpunkt, Deployment-Metadaten, Konfiguration, beobachtbare API-Versionen und weitere verfügbare Zustandsindikatoren kombiniert.
4. Daten- und Konfigurationsstand
Dasselbe Programm kann mit unterschiedlichen Datenständen oder Konfigurationen ein anderes Verhalten zeigen. Deshalb gehören Testdaten, Datenbankzustand, Feature Flags, Berechtigungen, Umgebungsvariablen und relevante externe Konfigurationen zur Zustandsbeschreibung, soweit sie die Fragestellung beeinflussen können.
Sensible Werte werden dabei nicht unnötig in Gutachten oder Prüfdokumentation übernommen. Für Nachvollziehbarkeit genügt häufig eine dokumentierte Identifikation, ein Hash, ein sicherer Referenzname oder eine Beschreibung der verwendeten Konfigurationsklasse.
Wird der Zustand während der Prüfung verändert, muss er entweder erneut gesichert oder die Veränderung als Grenze der Vergleichbarkeit dokumentiert werden.
5. Aussagegrenze des Systemstands
Ein Befund zu einem definierten Stand darf nicht ohne zusätzliche Prüfung auf frühere oder spätere Versionen übertragen werden. Dies gilt insbesondere bei Fehlern, Sicherheitslücken, Datenzuständen und KI-Modellen.
Auch ein identischer Quellcode garantiert nicht zwingend identisches Laufzeitverhalten, wenn Build, Infrastruktur, Abhängigkeiten oder Konfiguration abweichen. Umgekehrt kann ein gleich bezeichnetes Release technisch unterschiedliche Artefakte enthalten, wenn der Buildprozess nicht deterministisch oder nicht dokumentiert ist.
Der Untersuchungsgegenstand ist deshalb zugleich eine Aussagegrenze: Er benennt, wofür der Befund gilt und wofür keine technische Feststellung getroffen wurde.
6. Zustandsmanifest und reproduzierbare Identifikation
Für komplexe Systeme empfiehlt sich ein Zustandsmanifest. Es kann Repository-Revisionen, Build-Hashes, Paketversionen, Container-Images, Datenbank-Schemata, Konfigurationsstände, Feature Flags und externe Dienste enthalten. Nicht jede Position ist in jedem Fall nötig; entscheidend ist, dass die für die Fragestellung relevanten Zustandsfaktoren erfasst werden.
Menschenlesbare Versionsnamen allein sind oft nicht eindeutig. Ein Release-Label kann neu gesetzt, ein Container-Tag überschrieben oder eine Produktionsinstanz nachträglich verändert worden sein. Wo möglich, sollten deshalb technische Identifikatoren wie Commit-IDs, Artefakt-Hashes, Image-Digests oder exportierte Konfigurationsstände ergänzend dokumentiert werden.
Der Systemstand ist schließlich Teil der Aussagegrenze. Ein Befund zu Version 2.4.7 trägt nicht automatisch eine Aussage über Version 2.4.8 oder über einen später veränderten Produktionszustand. Bei dynamischen Cloud- oder SaaS-Systemen kann zusätzlich ein enger Zeitbezug erforderlich sein.
Warum reicht eine Versionsnummer häufig nicht aus?
Eine Versionsnummer ist zunächst eine Bezeichnung. Ihre technische Aussagekraft hängt davon ab, ob sie eindeutig auf einen konkreten Inhalt verweist.
Repository-Revision, Build-Artefakt und produktiver Laufzeitstand können auseinanderfallen. Ein reproduzierbarer Prüfbezug entsteht erst, wenn diese Ebenen soweit nötig miteinander verknüpft werden.
SLSA behandelt Provenienz deshalb als verifizierbare Information darüber, woher ein Softwareartefakt stammt sowie wann und wie es erzeugt wurde.
Ist die Untersuchung für diesen Themenbereich nachvollziehbar abgegrenzt?
- Sind Systemgrenze und relevante Schnittstellen dokumentiert?
- Ist der untersuchte Quellcode- oder Repository-Stand eindeutig identifiziert?
- Sind Build- und Release-Artefakte dem Quellstand nachvollziehbar zugeordnet?
- Sind Daten-, Schema- und Konfigurationsstände erfasst, soweit sie den Befund beeinflussen?
- Sind externe Dienste und relevante Abhängigkeiten mit Version oder Zeitpunkt dokumentiert?
- Wurde geprüft, ob Bezeichnung und tatsächlicher technischer Inhalt auseinanderfallen können?
- Bezieht sich jede Schlussfolgerung ausdrücklich auf den dokumentierten Zustand?
Konstruiertes Beispiel
Eine App trägt im Store dieselbe sichtbare Versionsnummer wie ein lokal bereitgestelltes APK. Erst der Vergleich von Build-Kennung, Signatur, Hash und Backendbezug zeigt, ob beide Artefakte technisch derselben Prüfbasis entsprechen. Ohne diese Zuordnung wäre eine Fehlerreproduktion nicht sicher auf den streitigen Stand übertragbar.
Das Beispiel ist konstruiert und beschreibt kein reales Mandat.
Quellen und fachliche Grundlage
- Technische Primärquelle Git-Dokumentation zu Revisionen und Objektbezeichnungen. Quelle öffnen.
- Spezifikation SLSA v1.2 beschreibt unter anderem Build-Provenienz und attestierbare Build-Informationen. Quelle öffnen.
- Eigene Methodik Quellen und Methodik. Quelle öffnen.
- W3C Recommendation PROV-DM beschreibt Entitäten, Aktivitäten und ihre Beziehungen als konzeptionelles Datenmodell für Provenienzinformationen. Quelle öffnen.
Weiterführende Beiträge
- Repository, Commit, Branch und Build
- App-Version, Build und Release rekonstruieren
- Alle Beiträge in diesem Themenbereich
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
- Eigenes Fachbuch Von Daten zu Lösungen in Data Science mit Python – Vom Problem zur verantwortbaren Lösung
- Eigenes Fachbuch Von Modellen zu Entscheidungen in Machine Learning mit Python – Vom Modell zur verantwortbaren Entscheidung
- Eigenes Fachbuch Von Code zu Lösungen im Software Engineering mit Java – Vom Problem zur verantwortbaren Lösung
Technische Untersuchung zum Themenbereich Gutachten & Methodik
Die konkrete Aussagekraft hängt vom Untersuchungsgegenstand, der verfügbaren Evidenz und der dokumentierten Prüfmethode ab.
Analyse & Bewertung