Evidence by Design: Entwicklungsnachweise nicht erst am Projektende erzeugen

Vier Wochen vor dem Audit beginnt in vielen Projekten dieselbe Übung: Testberichte suchen, Freigaben rekonstruieren, Versionsstände zuordnen, Dokumente nachziehen. Der Aufwand ist erheblich, das Ergebnis inhaltlich schwächer als das, was während der Arbeit ohnehin entstanden ist – nur eben nicht aufbewahrt wurde.

1. Das Problem mit nachträglichen Nachweisen

Ein Nachweis, der nachträglich zusammengestellt wird, hat drei Schwächen: Er ist teuer, weil Menschen ihn erzeugen. Er ist lückenhaft, weil Zwischenstände überschrieben wurden. Und er ist schwach, weil er zeigt, dass jemand die Belege suchen musste – ein Prozess, der sie automatisch erzeugt, wirkt in jeder Prüfung überzeugender.

Evidence by Design dreht die Reihenfolge um: Nicht der Nachweis folgt der Arbeit, sondern die Arbeit erzeugt den Nachweis als Nebenprodukt.

2. Was Evidence konkret ist

„Nachweis“ klingt abstrakt, ist aber sehr konkret. Belastbar ist ein Artefakt dann, wenn es vier Eigenschaften erfüllt:

• Automatisch erzeugt – nicht von Hand geschrieben.
• Zugeordnet – zu einem exakten Softwarestand und zu einer handelnden Person oder einem Prozess.
• Unverändert aufbewahrt – über die geforderte Frist, außerhalb flüchtiger Werkzeugoberflächen.
• Auffindbar – über eine Kennung, nicht über die Erinnerung einzelner Personen.

3. Die Artefakte je Stufe

Auffällig ist, wie wenig davon zusätzlich erzeugt werden muss. Fast alles entsteht ohnehin – es wird nur nicht eingesammelt.

4. Erzeugung in der Pipeline

Der entscheidende Schritt ist banal: Berichte nicht nur anzeigen, sondern als Artefakte ablegen und mit dem Build verknüpfen.

# Collect evidence in the same job that produces the build.
# Reports must outlive the CI retention period.

evidence:
  script:
    - ./gradlew test jacocoTestReport
    - syft dir:. -o cyclonedx-json > evidence/sbom.json
    - git log --format='%H %s%n%b' $PREV..$HEAD > evidence/changes.txt
    - sha256sum build/app.jar > evidence/checksums.txt
  artifacts:
    paths: [evidence/, build/reports/]
    expire_in: never          # retention follows the record-keeping policy

Wichtig ist die Aufbewahrungsfrist. Standardeinstellungen von CI-Systemen räumen Artefakte nach Wochen auf – das ist für Nachweise unbrauchbar. Die Frist muss aus der Aufbewahrungspflicht folgen, nicht aus dem Speicherplatzbudget.

5. Das Release-Paket

Am Ende sollte ein Release ein einziges, in sich geschlossenes Paket ergeben, das ohne Rückfragen beantwortet, was ausgeliefert wurde:

• Version, Commit-Stand und Prüfsumme des Artefakts,
• enthaltene Anforderungen mit Kennung,
• Testberichte mit Ergebnis und Anforderungsbezug,
• Berichte der Sicherheits- und Abhängigkeitsprüfungen,
• Software-Stückliste (SBOM),
• Freigaben mit Person und Zeitpunkt,
• Zielumgebung, Zeitpunkt und Ergebnis des Deployments.

Das Paket ist kein Dokument, das jemand schreibt. Es ist ein Verzeichnis, das die Pipeline füllt – und das im Zweifel unverändert an eine prüfende Stelle weitergegeben werden kann.

6. Aufbewahrung und Lesbarkeit

Der zweite Stolperstein nach der Frist ist das Format. Ein Nachweis muss auch dann lesbar sein, wenn das erzeugende Werkzeug abgelöst wurde. Praktische Regeln:

• Offene Formate bevorzugen – Text, JSON, XML, PDF statt proprietärer Exporte.
• Selbsttragend ablegen: Ein Bericht, der auf eine Werkzeug-URL verweist, ist nach der Ablösung wertlos.
• Integrität sichern: Prüfsummen oder Signaturen, damit spätere Veränderung erkennbar wäre.
• Migration einplanen. Wer Systeme wechselt, muss die Nachweise mitnehmen – das gehört in die Ablöseplanung, nicht ans Ende.

7. Grenzen des Ansatzes

• Automatische Nachweise belegen Ausführung, nicht Angemessenheit. Dass 400 Tests grün sind, sagt nichts darüber, ob sie das Richtige prüfen.
• Nicht alles ist automatisierbar. Risikobewertungen, Validierungspläne und Freigabeentscheidungen bleiben menschliche Artefakte – sie sollten aber im selben Paket referenziert sein.
• Speicher und Ordnung. Wer alles aufbewahrt, findet nichts. Die Struktur des Pakets ist Teil des Nutzens.

Typische Fehler

• Retention der CI-Artefakte auf Standardwert lassen.
• Nachweise nur im Werkzeug vorhalten statt als exportierte Artefakte.
• Kein Anforderungsbezug in Testberichten – dann ist keine Abdeckungsaussage möglich.
• Freigaben mündlich oder im Chat.
• Das Paket erst kurz vor dem Audit definieren statt zu Beginn.

Checkliste: Evidence by Design

Fazit

Evidence by Design ist keine neue Methodik, sondern eine Verlagerung: Der Nachweis entsteht dort, wo die Arbeit ohnehin stattfindet. Der technische Aufwand ist gering – ein paar Artefaktpfade, eine ehrliche Aufbewahrungsfrist, ein Anforderungsbezug in Testberichten.

Der Ertrag zeigt sich zweimal: bei der Prüfung, weil die Fragen ohne Suchen beantwortbar sind. Und im Alltag, weil dieselben Artefakte bei jeder Fehleranalyse und jeder Änderungsbewertung gebraucht werden. Wie sich die zugehörige Kette technisch aufbaut, beschreibt der Deep Dive Traceability: Requirement bis Release.