CGS IT Solutions GmbH — Claude Code Training · Modul 9 · Testing & AI Security im Workflow · v0.11.5

Modul 9

Testing & AI Security im Workflow

Tag 3 · ca. 75 Minuten

Inhalt

1Testing als Orakel — Closing the Loop, AI-assisted Testing, Teststrategie und Tooling, Tests als Gate 2Der Agent als Security-Werkzeug — riskante Muster, Validierung, AuthN/AuthZ, Abhängigkeiten, Abuse Cases, Review-Loops und Red-Team 3Der Agent als Risiko — Blast Radius, Verbote, Prompt Injection, wiederkehrende Prüfungen und CI Übung 9 — Security-Review-Loop auf dem legacy-playground

Lernziel Modul 9

Der Teilnehmer kann Tests und Security-Checks als Gates in den Workflow und die CI einbauen und agentische Review-Loops aufsetzen.

  1. Test als Gate — nicht „wir testen auch", sondern: ohne grün geht es nicht weiter.
  2. Security-Check als Gate — Abuse Cases laufen im selben Lauf wie die normalen Tests, nur mit umgekehrter Erwartung.
  3. In der CI verankert — was nur lokal läuft, läuft irgendwann nicht mehr.
  4. Review-Loop — ein Agent prüft, was ein anderer gebaut hat.
Gate heißt: etwas ist objektiv grün oder rot, und der Agent kommt nicht daran vorbei, weil er sich sicher fühlt.

Testing als Orakel für den Agenten

Die einzige Instanz im Raum, die nicht höflich ist

Ohne Signal rät der Agent

Das Modell klingt bei „weiß ich sicher" genauso souverän wie bei „klingt plausibel" (Modul 1).
Ohne äußeres Signal ist sein Abbruchkriterium sein eigenes Urteil — also genau das, was ihr nicht prüfen könnt.

Auftrag
Ändern
Test
ausführen
Rot?
Ziel!
Grün? Fertig!
  1. Offener Loop — nach jeder Runde urteilt der Mensch. Teuer, langsam, und der direkte Weg in die Approval Fatigue (Modul 4).
  2. Geschlossener Loop — das Urteil kommt vom Werkzeug, der Agent iteriert selbst, bis das Werkzeug schweigt.
Ein roter Test ist ein Geschenk. Er verwandelt „mach das gut" in eine Aufgabe mit Abbruchbedingung — und er ist die einzige Instanz im Setup, die nicht darauf trainiert ist, hilfreich zu wirken.

Der Test, der den Fehler festschreibt

Der Agent ist stark im Ausformulieren von Tests — Gerüst, Randfälle, Parametrisierung, Nachrüsten für Altcode.
Schwach ist er bei der einen Frage, auf die es ankommt: was fachlich richtig ist.

so trägt er
die Fachlichkeit
was gelten soll
Soll
Test
grün
die Erwartung ist erfüllt
so ist er ein
Screenshot
der Code, wie er ist
was gerade passiert
Ist
Test
grün
sagt nur, dass sich nichts geändert hat
beide Tests sind grün — nur einer prüft etwas
Version 0.65.0 — cgsit-finance Ein Berechner las nur die Spalte price_eur. Bei EUR-Listings ist genau diese Spalte null — der Wert steht in price. Ergebnis: leere Kurve in Produktion. Der Unit-Test war grün, weil das Mock getPriceEur() stubte. Ein Mock bildet die Form der Datenbankzeile nicht ab. Grün auf Unit-Ebene heißt „die Rechnung stimmt" — nicht „die Daten sehen so aus".

Teststrategie ins Repo, Tests ans Gate

Damit der Agent nicht rät, welche Sorte Test er schreiben soll, steht die Strategie im Repo — und damit sie zählt, hängt sie an Gates.

EbeneDatenbankfängt nicht
L1 Unitkeine (Mock)Zeilenform, SQL, Auth
L2 IntegrationTestcontainerNaht zum Frontend, JWT
L3 E2Eechte InstanzRechen-Korrektheit

Dazu eine Entscheidungstabelle für Testdaten: Fällt ein Test nur in CI um, hängt er an lokalem Zustand — und umgekehrt. Flaky Tests zerstören das Orakel.

1In der Schleife — ein einzelner Test, nicht die Suite. Ausgabe eindampfen oder im Subagenten laufen lassen, sonst frisst das Protokoll den Kontext.
Gate Vor dem Commit — betroffene Suite grün. Hook oder Skill, nicht Disziplin.
Mensch Im Review — ist der Test fachlich richtig, oder zementiert er das Ist?
Gate In der CI — die Instanz, die niemand lokal überstimmt.
checked am 2026-07-21 gegen cgsit-finance/docs/testing.md

Der Agent als Security-Werkzeug

Und warum das nur die halbe Frage ist

Zwei Bedeutungen, bitte nicht vermischen

„AI Security" meint zwei entgegengesetzte Richtungen — einmal schaut der Agent auf den Code, einmal wirkt er auf die Umgebung.

der Agent als Werkzeug
eure Codebasis
Agent
er sucht Muster: fehlende Validierung,
löchrige Rechteprüfung, alte Abhängigkeiten
Wie mache ich mein System härter?
der Agent als Risiko
fremder Text
Agent
Befehle · Repo
Secrets
was er liest, kann Anweisung werden —
und er hat Rechte
Was passiert im schlimmsten Fall?
rot: was der Agent auslöst, ohne dass jemand es getippt hat
Dieses Modul behandelt die linke Spalte. Die rechte ist ein eigenes Deck: Erweiterung 6 — KI-Entwicklung absichern.
Wer nur links arbeitet, hat einen fleißigen Sicherheitsprüfer mit Produktionszugang.

Was der Agent über die ganze Codebasis findet

Sicherheitsprobleme sind Muster über viele Dateien — und genau darin ist der Agent stark.
Die Kunst ist nicht die Frage, sondern das Suchraster: „schau mal, ob was unsicher ist" liefert Prosa, eine benannte Liste liefert Fundstellen mit Datei und Zeile.

Im Code

  1. Riskante Muster — SQL aus "…" + variable, leerer catch-Block, Secrets als Literal, magische Grenzwerte, ungeprüfte Dateinamen aus Nutzereingabe.
  2. Eingänge — alle Eintrittspunkte fremder Eingabe aufzählen lassen: Parameter, Body, Header, Upload, Import, Webhook. Pro Eingang: Typ, Bereich, Länge — und ob serverseitig geprüft wird.

An den Rändern

  1. Rechte — wird die Identität aus dem Token gezogen oder aus dem Pfad? Filtert die Query wirklich? Gibt es Endpunkte ohne Prüfung, weil sie „intern" sind?
  2. Abhängigkeiten und Konfiguration — bekannte Lücken in Bibliotheken und Basis-Images, Secrets in der Git-Historie, Debug-Schalter, die in Produktion aktiv sind.
Die Musterliste gehört ins Repo, nicht in den Chat — dann ist sie beim nächsten Mal noch da und wird zum wiederkehrenden Check.

Invarianten, die der Agent nicht erfinden kann

Die Checkliste davor kennt jedes Modell.
Was es nicht kennt, sind die Entscheidungen eures Hauses — und ohne sie korrigiert der nächste Agent sie weg, weil seine Variante „sauberer" aussieht.

Invariante — Review-Katalog cgsit-finance Jeder Endpunkt zieht die Mandanten-ID aus dem Token, niemals aus dem Pfadparameter. Zugriff auf fremde Ressourcen antwortet mit 404, nicht 403. Warum 404: Ein 403 bestätigt, dass die Ressource existiert — damit lässt sich ihr Bestand durchprobieren.
Konfiguration — cgsit-finance Ein Schalter aktiviert Test-Endpunkte für E2E-Läufe. Er ist per Default aus, wird in CI gesetzt, ist in Produktion verboten — und ein eigener Test prüft genau das. Konfiguration ist die erste Verteidigungslinie — und ohne Test ist sie nur eine Absichtserklärung.

Abuse Cases — Security wird zum Gate

Use Case

„Als Nutzer möchte ich meine Buchung stornieren."

Testet, dass das System das Erlaubte kann.

Abuse Case

„Als Nutzer storniere ich die Buchung eines anderen, indem ich die ID in der URL hochzähle."

Testet, dass das System das Verbotene verweigert.

Ein Abuse Case ist ein ganz normaler Test — nur mit umgekehrter Erwartung: nicht 200, sondern 403 oder 404.

Sammelfragen an den Agenten: fremde ID? negative Menge? doppeltes Absenden? abgelaufenes Token? 0 Byte und 500 MB?

Review-Loops

Ein Reviewer findet nur, wonach er sucht.
Deshalb bringen drei Anläufe mit derselben Frage fast nichts — und ein zweiter Blickwinkel sehr viel.

  1. Auslöser — Geld, Rechte, Mandantengrenze, Migration. Nicht jede Änderung braucht ein Review; diese schon.
  2. Messlatte — die Invarianten des Bereichs plus die zu lesenden Dokumente. Ohne Messlatte misst der Agent gegen sein Bauchgefühl.
  3. Ausgabeformat — je Befund konform / Warnung / Verstoß mit datei:zeile. Erzwungenes Format macht Befunde zählbar statt wohlwollend.
  4. Rolle umdrehen — „greife unser eigenes System an", nur Befunde, keine Fixes. Sonst kommt ein großer Diff und niemand weiß mehr, was das Problem war.

Es gibt Fertiges — erst prüfen, dann bauen:

/code-review # Branch + Working Tree
/code-review --fix # gleich anwenden

# Plugin aus dem Marktplatz
/plugin install security-guidance@…

# REVIEW.md kalibriert das Review:
was „wichtig" heißt, wie viele
Kleinigkeiten, was gar nicht kommt.
Ein Agent, der seinen eigenen Code reviewt, findet systematisch weniger — er kennt seine Begründung noch.
checked am 2026-07-26 gegen code.claude.com/docs/code-review

Der Agent als Risiko

Wirkungs- und Schadensradius begrenzen

„Blast Radius" begrenzen — gezielte deny-Regeln

Blast Radius = alles, was kaputtgehen kann, wenn ein Schritt falsch ist — nicht „wie wahrscheinlich", sondern „wie weit reicht es".
Daraus die Faustregel: Umkehrbares darf der Agent, Unumkehrbares nicht.

  1. Was kann der Agent erreichen? Repo, Dateisystem, Netz, Datenbanken, Cloud-Konten, Deploy-Ziele.
  2. Was davon ist nicht rückholbar? Gelöschtes Volume, Force-Push, gedroppte Tabelle, veröffentlichtes Paket.
  3. Was davon merkt niemand? Daten, die den Rechner verlassen — kein Rückgängig, kein Log.
2026-07-01 — warum pauschal nicht funktioniert docker compose down ist lokal harmlos, auf Produktion ein Vorfall. Der Hook blockt nur, wenn alle drei Bedingungen zutreffen: wirklich ausgeführt, wirklich compose down, wirklich Produktion. Die erste Fassung blockte einen Commit, dessen Text die Wörter enthielt. Zu grob heißt Fehlalarme — und Fehlalarme heißen abgeschaltete Wächter.

Wiederkehrendes Prüfen bei fremdem Text

Ein Agent verarbeitet Inhalte, die niemand aus eurem Team geschrieben hat: Issues, Kommentare, abgerufene Webseiten, fremde Repositories, Logs von Dritten.
Für das Modell ist all das erst einmal Text im Kontext — also potenziell Anweisung.

Prompt Injection — die Denkfalle

„Ich habe dem Agenten nichts Gefährliches gesagt." Stimmt. Gesagt hat es der Inhalt, den er auf eure Anweisung hin gelesen hat.

  1. Fremdinhalte als Daten behandeln, nicht als Auftrag.
  2. Engere Rechte für Aufgaben, bei denen der Agent fremde Inhalte liest — der direkteste Hebel im Alltag.
  3. Hinsehen, was er ausführen will, nicht nur dass er etwas will.
WannWas läuft
Beim Schreiben (Hook)Guardrails auf geänderte Dateien
Vor dem Commitbetroffene Tests, Review sensibler Bereiche
Bei jedem PushBuild, Unit, Integration, E2E
Beim Image-BauSchwachstellen-Scan, Abbruch bei kritischen Funden
WöchentlichSecret-Scan über die volle Historie

Ein Review vom März sagt nichts über den Code vom Juli.

Der Schritt von einmalig zu wiederkehrend ist der eigentliche Wertschritt: Ein Fund wird zur Regel, eine Regel zum Gate, ein Gate zur Selbstverständlichkeit.

Modul 9 in fünf Sätzen

1Ohne objektives Signal rät der Agent — ein Test ist sein Orakel, ein roter Test sein Ziel.
2Das Soll kommt vom Menschen, die Ausformulierung vom Agenten. Sonst schreibt der Test den Fehler fest.
3Security-Anforderungen werden erst zu Gates, wenn sie Tests sind — Abuse Cases sind der Hebel.
4Mehrere Blickwinkel schlagen mehrere Anläufe — und jeder Befund wird am Code verifiziert.
5Der Agent ist auch ein Risiko: Blast Radius begrenzen — gezielt verbieten, nicht pauschal lähmen.
Testing und Security sind hier kein Qualitätsthema, sondern ein Steuerungsthema: Sie sind die einzigen Instanzen im Setup, die dem Agenten widersprechen können.

Übung 9 — Security-Review-Loop

Aufgabe

Setzt einen Review-Loop auf examples/legacy-playground an — unaufgeräumter, testfreier Java-Code mit SQL-String-Konkatenation, verschluckten Exceptions, hartkodierten Zugangsdaten und magischen Zahlen.

  1. Erster Durchlauf: Befunde sammeln, keine Fixes. Festes Ausgabeformat verlangen: datei:zeile, Kategorie, Begründung, Schweregrad.
  2. Zweiter Durchlauf mit anderem Blickwinkel und frischer Session (z. B. Red-Team statt Review). Befunde zusammenführen.
  3. Jeden Befund einzeln am Code nachprüfen — öffnen, Zeile lesen, bestätigen oder verwerfen.
Verifizierbares Ergebnis: eine Befundliste, in der jeder Eintrag am Code verifiziert ist — mit Fundstelle und Urteil bestätigt / nicht zutreffend / unklar. Kein ungeprüfter Agenten-Report zählt. Nennt außerdem mindestens einen Befund, den nur einer der beiden Durchläufe gefunden hat.

Dauer ca. 30 Minuten · Paararbeit · nur eigener Kurs-Code

© 2026 CGS IT Solutions GmbH

Alle Rechte vorbehalten

Diese Schulungsunterlagen sind urheberrechtlich geschützt. Vervielfältigung, Weitergabe oder kommerzielle Nutzung — auch in Auszügen — nur mit ausdrücklicher schriftlicher Genehmigung der CGS IT Solutions GmbH.

cgsit-claude-training · Modul 9 · v0.11.5