Was ein Mensch vor dem Start prüfen muss

Ein Review mit begrenztem Auftrag

Niemand liest vor dem Start noch einmal jede Zeile, die ein Agent in den letzten Wochen geschrieben hat. Das ist auch nicht nötig. Was sich maschinell prüfen lässt, prüft die Maschine, wie das geht, zeigt Quality-Gates gegen KI-Fehler. Wie man einzelne Änderungen im Alltag gegenliest, steht in KI-Code: Fast richtig reicht nicht.

Dieses Review ist etwas anderes: ein einmaliger Durchgang vor dem Start mit festen Prüfpunkten. Sie haben gemeinsam, dass ein Fehler dort lange unbemerkt bleibt und teuer wird, sobald er auffällt. Die Auswahl folgt der Frage, die Birgitta Böckeler für die Arbeit mit Agenten vorschlägt und die wir in Harness Engineering aufgegriffen haben: Würde ich es überhaupt merken, wenn es falsch ist?

Die Arbeit teilt sich in zwei Hälften. Der Agent stellt die Unterlagen zusammen, also Listen, Tests und Messwerte. Ein Mensch sieht sie durch, probiert die kritischen Stellen selbst aus und entscheidet. Diese zweite Hälfte lässt sich nicht delegieren, auch nicht an einen zweiten Agenten.

Die Unterlagen stellt der Agent zusammen

Starte dafür eine frische Sitzung ohne den Verlauf, in dem gebaut wurde. Dahinter steht das Vier-Augen-Prinzip: Wer die eigene Arbeit prüft, übersieht leicht die eigenen Fehler. Eine neue Sitzung sieht nur, was im Repository steht.

Die letzte Zeile ist die wichtigste. Eine Mappe ohne offene Punkte ist verdächtig, denn es gibt immer etwas, das sich aus dem Code allein nicht beantworten lässt.

Zugriff auf fremde Daten

Fehlerhafte Zugriffskontrolle steht auf Platz eins der OWASP Top 10 von 2025. Eine typische Form: Die Anwendung prüft, ob jemand angemeldet ist, aber nicht, ob der Datensatz ihm gehört. Wer in der Adresse eine Kennung ändert, sieht dann die Rechnung eines anderen.

Das probierst du selbst aus. Dafür brauchst du keine Programmierkenntnisse, nur zwei Benutzerkonten und zwei Browserfenster.

1. Melde dich in einem Fenster als Nutzer A an und leg etwas an: eine Bestellung, ein Dokument, ein Profil.
2. Kopiere die Adresse dieser Seite.
3. Öffne sie im zweiten Fenster, in dem Nutzer B angemeldet ist.
4. Wiederhole das mit jeder Art von Datensatz, die die Anwendung kennt, und mit einem Fenster ganz ohne Anmeldung.

Sieht Nutzer B die Daten, ist der Start verschoben. Lass dich nicht davon beruhigen, dass die Kennungen lang und zufällig aussehen. OWASP hält dazu fest, dass die Zugriffsprüfung auch bei solchen Kennungen nötig bleibt, weil Adressen in falsche Hände geraten können.

Der Handtest deckt die Seiten ab, die du siehst. Für die Schnittstellen dahinter schaust du in die Mappe: Steht bei jedem Endpunkt eine Zugriffsprüfung mit Datei und Zeile, und gibt es die Tests mit zwei Nutzern, die im Serienteil Anmeldung und Zahlungen nicht selbst bauen beschrieben sind?

Gleichzeitige Zugriffe

Dieser Punkt lässt sich schlecht ausprobieren, und das macht ihn heikel. Googles Leitfaden für Code-Reviews sagt über Race Conditions, solche Fehler seien durch bloßes Ausführen des Codes sehr schwer zu entdecken und bräuchten jemanden, der sie sorgfältig durchdenkt.

Du verlangst deshalb zwei Dinge. Erstens die Liste aller Stellen, die Geld oder begrenzte Mengen bewegen. Geh sie mit jemandem durch, der das Geschäft kennt, und frag, ob eine fehlt: Gutscheine, Freikontingente, Lagerbestand, Plätze. Zweitens zu jeder Stelle einen Test, der die Aktion mehrfach gleichzeitig auslöst. Lass dir zeigen, dass der Test fehlschlägt, wenn man die Absicherung entfernt. Ein Test, der noch nie rot war, beweist nichts. Wie die Absicherung aussieht, steht in Die Datenbank hinter dem Prototyp absichern.

Last

Die Frage lautet, ob die Lösung die Nutzung aushält, mit der du rechnest. Die Antwort liefert ein Lasttest gegen eine Testumgebung, nie gegen die Produktion. Werkzeuge dafür gibt es frei verfügbar, etwa das Open-Source-Werkzeug k6. Das Skript schreibt der Agent, die Zielgröße kommt von dir.

Die Zahl musst du begründen können. Als Faustregel: die erwartete Nutzung zur Spitzenzeit, verdoppelt. Wer sie nicht kennt, hat damit die erste Aufgabe gefunden.

Geheimnisse

Zugangsdaten, API-Schlüssel und Passwörter gehören nicht ins Repository. OWASP beschreibt als verbreiteten Zustand, dass sie im Klartext im Quellcode und in Konfigurationsdateien stehen. In einem Projekt, das schnell entstanden ist, lohnt der Blick besonders, und zwar in die ganze Historie: Ein Schlüssel, der vor drei Wochen eingecheckt und danach gelöscht wurde, ist weiter auffindbar.

Dafür gibt es Werkzeuge. GitHub durchsucht mit Secret Scanning nach eigener Angabe die gesamte Git-Historie aller Branches. Das Open-Source-Werkzeug Gitleaks macht dasselbe lokal und lässt sich als Prüfung vor jedem Commit einhängen. Den Lauf kann der Agent starten.

Was dann folgt, machst du selbst. Jeder gefundene Schlüssel gilt als bekannt, egal wie kurz er im Repository stand. Du erzeugst beim jeweiligen Anbieter einen neuen, trägst ihn dort ein, wo die Anwendung ausgeliefert wird, und sperrst den alten. Den Schlüssel nur aus der Datei zu löschen reicht nicht.

Fehlermeldungen und Standardeinstellungen

Was im Prototyp praktisch ist, verrät im Betrieb zu viel. OWASP führt unter fehlerhafter Konfiguration zwei Dinge, die sich schnell prüfen lassen: Fehlermeldungen, die Nutzern interne Details wie einen Stack Trace zeigen, und Standardkonten, deren Passwort nie geändert wurde.

Beides probierst du aus. Ruf eine Adresse auf, die es nicht gibt, schick ein Formular mit unsinnigen Werten ab und sieh dir an, was erscheint. Eine freundliche Meldung ist richtig, ein Bildschirm voller Dateipfade nicht. Geh dann die Liste der Konten durch: Gibt es einen Admin-Zugang aus der Entwicklungszeit, Testnutzer mit einfachem Passwort oder eine Verwaltungsoberfläche, die ohne Anmeldung erreichbar ist?

Abhängigkeiten

Ein Agent bindet Bibliotheken ein, wenn sie ihm helfen. Jede davon ist fremder Code, der in deiner Anwendung läuft. OWASP nennt als Risiko, die Versionen der eingesetzten Komponenten nicht nachzuhalten und veraltete oder verwundbare Software zu betreiben.

In der Mappe steht die Liste mit dem Ergebnis der Schwachstellenprüfung. Du siehst dir zwei Dinge an. Gibt es Einträge mit bekannter Schwachstelle, und was ist der Plan dafür? Und gibt es Pakete, die niemand kennt oder die nur für eine Kleinigkeit eingebunden wurden? Bei jedem unbekannten Namen lohnt die Frage an den Agenten, wofür er gebraucht wird und ob es ohne geht.

Wenn niemand im Team das beurteilen kann

Den Zugriff auf fremde Daten, die Geheimnisse und die Fehlermeldungen prüfst du ohne technischen Hintergrund. Bei Gleichzeitigkeit, Last und Abhängigkeiten braucht es jemanden, der einschätzen kann, ob die Unterlagen stimmen. Hol dir diese Person gezielt, für genau diesen Auftrag. Mit der Prüfmappe hat sie einen Einstieg und muss sich nicht erst durch das Projekt arbeiten, das hält den Aufwand klein.

Wo mehr auf dem Spiel steht, etwa bei Gesundheitsdaten, Zahlungsdaten oder vielen Nutzern, reicht das nicht. Dann ist ein Sicherheitstest durch Spezialisten angebracht. Als Grundlage dafür gibt es den Application Security Verification Standard von OWASP, der Anforderungen auflistet, gegen die sich eine Anwendung prüfen lässt. Er eignet sich auch, um im Angebot festzulegen, was geprüft wird.

Beim Kundenauftrag ist das die Abnahme

Lieferst du im Auftrag, hat der Moment der Übergabe einen Namen und rechtliche Folgen. Für Werkverträge regelt § 640 BGB die Abnahme. Dort steht unter anderem, dass der Besteller ein vertragsgemäß hergestelltes Werk abnehmen muss, die Abnahme wegen unwesentlicher Mängel nicht verweigern kann und sich bei bekannten Mängeln seine Rechte vorbehalten muss. Ob dein Vertrag ein Werkvertrag ist und was daraus im Einzelnen folgt, klärt eine Rechtsberatung, kein Artikel.

Praktisch hilft beiden Seiten dasselbe: Die sechs Prüfpunkte stehen vorher im Vertrag oder im Angebot, und das Ergebnis steht im Abnahmeprotokoll. Der Kunde kann den Zugriff auf fremde Daten und die Fehlermeldungen selbst durchspielen und sich die übrigen Punkte zeigen lassen. Der Dienstleister hat schriftlich, was geprüft wurde und in welchem Zustand er übergeben hat.

Auf Kundenseite gilt: Frag nach der Prüfmappe und nach den Tests mit zwei Nutzern, bevor du abnimmst. Wer sie nicht vorlegen kann, hat sie nicht gemacht.

Aufschreiben, was nicht geprüft wurde

Am Ende steht ein kurzes Protokoll im Repository: Datum, wer geprüft hat, Ergebnis je Punkt und, ausdrücklich, was nicht geprüft wurde. Diese letzte Rubrik fällt am schwersten und nützt am meisten. Sie sagt dem Nächsten, wo er nicht auf dich bauen kann. Dieselbe Idee im Kleinen, für einzelne Änderungen, beschreibt Die 79-Prozent-Falle.

Das Review gilt für den Stand, der geprüft wurde. Nach größeren Änderungen an Anmeldung, Zahlung oder Datenmodell wiederholst du die betroffenen Punkte. Die Tests zu fremden Daten und zu gleichzeitigen Zugriffen laufen ohnehin bei jeder Änderung mit.

Womit du heute anfängst

Mit den zwei Browserfenstern aus dem Abschnitt zu fremden Daten. Das dauert eine halbe Stunde, braucht keinen Agenten und prüft das Risiko, das OWASP an erster Stelle führt. Danach lässt du die Prüfmappe erstellen und liest zuerst die Liste der offenen Punkte.