QUELLENVERGLEICH / Agentische Programmierung · Tests & Verifikation
Mit Agenten entwickelte
Software testen.
Agenten können Tests erzeugen und ausführen. Dieser Artikel untersucht, wie aktuelle Empfehlungen Erfolg definieren, Testqualität bewerten und eingrenzen, was ein bestandenes Testergebnis belegen kann.
- Artikeldatum
Aktualisiert- Stand der Ausgangsnotizen
- Letzte Quellenprüfung
KURZFASSUNG
Kerngedanken.
- Erfolg definieren, bevor Tests erzeugt werden, damit die Prüfungen erwartetes Verhalten und unzulässige Ergebnisse abdecken.
- Neben der Software auch die Tests auf falsche Annahmen und wichtige fehlende Ausführungspfade prüfen.
- Testergebnisse im jeweiligen Geltungsbereich beurteilen. Softwaretests, Sicherheitsanalysen und Agentenevaluationen beantworten unterschiedliche Fragen.
01QUELLENVERGLEICH
Vor den Tests festlegen, was als Erfolg gilt
Im Testmanagement wird festgelegt, welche Fragen die Testläufe beantworten sollen. Dazu gehören erwartetes Verhalten, unzulässige Ergebnisse, Umgebungen, Abdeckung, Abbruchbedingungen und die Entscheidung darüber, wer verbleibende Unsicherheit akzeptiert. Der einzelne Testlauf beantwortet eine zuvor definierte Frage.
Bei einer beispielhaften Anforderung an die Zugriffskontrolle darf eine Person ihren eigenen Datensatz bearbeiten, aber den einer anderen Person nicht lesen. Das gilt auch für einen direkten API-Aufruf. Dieses erwartete Ergebnis ist das Testorakel. Wird es allein aus der Implementierung abgeleitet, besteht das Risiko, dieselbe falsche Annahme zu übernehmen.
NIST SSDF 1.1 unterscheidet die Auswahl von Tests für ausführbaren Code (PW.8.1) von der Festlegung ihres Umfangs, ihrem Entwurf, ihrer Ausführung, den dokumentierten Ergebnissen und dem Umgang mit Befunden (PW.8.2). Testdateien zu erzeugen, deckt nur einen Teil dieser Aufgaben ab. [03]
GRAFISCH ERLÄUTERT
Erwartetes und tatsächliches Testergebnis vergleichen
Eine Person darf einen Datensatz nicht lesen, wenn sie dafür keine Zugriffsberechtigung hat.
Die Zugriffsgrenze mit der Datensatzkennung einer anderen Person prüfen.
Identität, Schnittstelle, Umgebung und beobachtetes Ergebnis festhalten.
Die Grenze korrigieren oder klären. Die Prüfaussage nicht bloß ändern, damit der Test besteht.
Ein bestandenes Ergebnis deckt nicht alle Personen, Routen, Umgebungen oder Zugriffsregeln ab.
Ein veranschaulichendes Beispiel für Zugriffskontrolle, kein für diesen Artikel durchgeführter Test. Das erwartete Ergebnis muss aus der Anforderung stammen und darf nicht allein aus der Implementierung abgeleitet werden.
02QUELLENVERGLEICH
Was die Engineering-Quellen hervorheben
Die beschriebenen Praktiken ergänzen sich. Der Vergleich bewertet keine Agenten anhand eines Benchmarks. Welche Funktionen dokumentiert sind und welche tatsächlich ausgeführt wurden, muss unterschieden werden.
OpenAI empfiehlt, Erfolg vor dem Schreiben eines Skills zu definieren
Kundel und Chua empfehlen, vor dem Schreiben eines Agent Skills zwingend zu erfüllende Kriterien für Ergebnis, Vorgehen, Stil und Effizienz festzulegen. In ihrer Evaluation werden Prompts den dokumentierten Läufen, Traces und Artefakten zugeordnet. Darauf folgen Prüfungen und vergleichbare Bewertungen. Deterministische Prüfungen erfüllen dabei einen anderen Zweck als Bewertungen anhand eines Kriterienrasters. [05]
Übertragbar ist das Vorgehen, Erfolg zu definieren und geeignete Nachweise zu sammeln. Die Evaluation eines Skills beantwortet jedoch andere Fragen als Tests der Anwendung, die der Skill verändert.
OpenAI empfiehlt, das Schreiben von Tests zu delegieren und die Spezifikation zu verantworten
OpenAI empfiehlt, das Schreiben erster Testfälle zu delegieren. Entwickler sollen dabei auf Abkürzungen und Stubs achten und prüfen, ob Funktionen und Benutzererfahrung ausreichend abgedeckt sind. Die Tests sollten getrennt von der Implementierung erzeugt werden und fehlschlagen, bevor die Funktion existiert. Zur Einrichtung gehören ausführbare Tests, passende Berechtigungen und die Kenntnis vorhandener Testsuiten. [04]
Auch die Codex-Empfehlungen verlangen relevante Prüfungen und Erfolgskriterien in Prompts oder Projektanweisungen. Sie versprechen dabei keine automatische Ausführung der vollständigen Testsuite eines Projekts. [06]
Anthropic empfiehlt, das Ergebnis beobachtbar zu machen
Anthropic empfiehlt ausführbare und überprüfbare Prüfungen, etwa Tests, Builds, Skripte oder visuelle Vergleiche. Die Dokumentation unterscheidet eine Verifikationsanfrage, ein über mehrere Gesprächsschritte hinweg bewertetes Ziel, eine konfigurierte Skriptprüfung als Freigabebedingung und einen getrennten Verifikationsagenten. Befehle, Ausgaben und Screenshots liefern die Nachweise. [07]
Die standardmäßig aktivierte Verifikation in der Desktop-Vorschau nutzt Screenshots und Fehlerprüfungen. Daraus lässt sich weder eine dauerhaft vorgehaltene Browser-Regressionssuite noch eine Abdeckung der Datenbank oder vollständige Tests auf Barrierefreiheit und Sicherheit ableiten. [08]
Google empfiehlt, neben der Implementierung auch die Tests zu prüfen
Google empfiehlt zu prüfen, ob Tests korrekt, nützlich und wartbar sind und bei fehlerhaften Implementierungen fehlschlagen können. Unit-, Integrations- und Ende-zu-Ende-Tests sollten zur jeweiligen Änderung passen. [09]
Das Jules-Update vom Juni 2025 berichtet von einer gestiegenen Wahrscheinlichkeit, Tests zu schreiben und auszuführen. Der Beitrag von Korevec, Hassen und Zhang vom August beschreibt eine integrierte „Critic“-Funktion. Diese Kritik liefert andere Nachweise als ausgeführte Tests. Die historischen Berichte belegen keine allgemeingültige aktuelle Testsuite. [10] [11]
03QUELLENVERGLEICH
Auch die Tests müssen geprüft werden
Tests können zu wenig prüfen, die entscheidende Komponente durch einen Mock ersetzen oder Annahmen der Implementierung übernehmen. Bei der Prüfung sollte deshalb gefragt werden, welchen plausiblen Fehler der jeweilige Test erkennen würde. Ein Regressionstest sollte den Fehler reproduzieren, gegen den er gerichtet ist. Wird eine Assertion lediglich an das fehlerhafte Verhalten angepasst, bleibt der Fehler bestehen.
Bei TDD wird zunächst ein aussagekräftiger Test geschrieben, der fehlschlägt. Danach folgen Implementierung und Refactoring, bei dem das Verhalten erhalten bleibt. BSI und ANSSI nennen die KI-gestützte Erzeugung von Testfällen einschließlich Randfällen als Möglichkeit, den Aufwand für TDD zu senken. Sie behandeln funktionale Tests, Sicherheitsreviews und Schwachstellenscans getrennt. TDD ist keine vollständige Sicherheitsmethode. [12]
Arbeiten nach dem Test-first-Prinzip braucht klare Erwartungen und eine Prüfung der Tests. Zusätzliche Testfälle und Zeilenabdeckung helfen, wenn sie relevante Fehler sichtbar machen. Ob die Anforderungen und Assertions richtig sind, wird dadurch nicht validiert.
04QUELLENVERGLEICH
Zweck, Umfang und Methode trennen
Testbezeichnungen beschreiben unterschiedliche Eigenschaften. Funktionalität, Sicherheit und Leistung bezeichnen den Zweck, positiv und negativ die Art der Testfälle. Unit-, Integrations- und Ende-zu-Ende-Tests unterscheiden sich durch ihre Abgrenzung. Statische und dynamische Analyse bezeichnen Methoden. Ein negativer Sicherheitstest kann deshalb zugleich ein Integrationstest sein. Diese Beispiele erläutern die Unterscheidungen in diesem Artikel.
Regeln und Schnittstellenverträge
Unit-Tests prüfen kleine Verhaltenseinheiten. Contract-Tests prüfen vereinbarte Eingaben, Ausgaben und Fehler zwischen Komponenten. Mit Mocks lassen sich Tests schnell und wiederholbar ausführen. Das Verhalten des echten Anbieters bleibt dabei ungeprüft. Die Ergebnisse beziehen sich auf den modellierten Vertrag und die tatsächlich ausgeführten Fälle.
Tatsächliches Zusammenspiel
Eine API, Berechtigungsprüfungen und eine temporäre Testdatenbank können gemeinsam auf Transaktionen, Constraints, gleichzeitige Schreibzugriffe und Zugriffsregeln auf Zeilenebene geprüft werden. Mocks können die tatsächliche Durchsetzung durch die Datenbank nicht belegen. Unterschiede zwischen der Testumgebung und der bereitgestellten Umgebung bleiben relevant.
Nutzungsabläufe
Ein Browsertest könnte eine Anmeldung, eine Bearbeitung und den anschließend gespeicherten Zustand prüfen. Seine Abdeckung hängt von den untersuchten Abläufen, Rollen, Browsern und ersetzten Diensten ab. Screenshots des Layouts prüfen weder Tastaturinteraktionen noch Zugriffsregeln oder Auswirkungen im Backend. Dafür sind geeignete Assertions nötig.
Die bereitgestellte Umgebung
Smoke-Tests prüfen wesentliche Verhaltensweisen nach der Bereitstellung. Canary-Rollouts führen Änderungen schrittweise ein und überwachen dabei mögliche Probleme. Sie ergänzen Tests vor der Veröffentlichung. CISA, das FBI und ASD’s ACSC verbinden Tests mit schrittweiser Einführung, Überwachung und Wiederherstellung. [22]
05QUELLENVERGLEICH
Was Prüfbezeichnungen aussagen
Bezeichnungen wie CI-Prüfung, manuelle visuelle Prüfung unter Linux oder Produktionsprüfung reichen allein nicht aus. Eine aussagekräftige Dokumentation würde die ausgeführte Handlung, die Umgebung, das erwartete Ergebnis und das beobachtete Resultat benennen.
CI-Prüfungen
CI führt konfigurierte Tests, statische Prüfungen, Builds oder andere Befehle aus. Zu den relevanten Nachweisen gehören Jobs, Befehle, Revision, Runner-Umgebung, Ergebnisse und übersprungene Schritte. Ein grüner Status stützt Aussagen über die tatsächlich ausgeführten Prüfungen. [01]
Manuelle visuelle Prüfung unter Linux
Eine aussagekräftige Dokumentation würde angeben, ob ein Mensch oder ein Agent geprüft hat und wer dies war. Sie würde außerdem die Linux-Umgebung, die verwendete Anwendung oder den Browser sowie die untersuchten Ansichten und Interaktionen benennen. Screenshots zeigen diese Bedingungen. Da die Darstellung von Betriebssystem, Browser und Einstellungen abhängt, bleibt nach einer einzelnen Prüfung offen, ob auch andere Plattformen abgedeckt sind. [02]
Prüfungen in der Produktionsumgebung
Mit Produktionsprüfungen könnten die Bereitstellungskonfiguration, Smoke-Tests der laufenden Anwendung oder die betriebliche Überwachung gemeint sein. Dokumentiert werden sollten die jeweilige Kontrolle, die Umgebung, die bereitgestellte Revision und das Ergebnis. Ein Produktionsbuild oder eine funktionierende Vorschau allein verifiziert die tatsächlich bereitgestellte Anwendung nicht.
06QUELLENVERGLEICH
Welche Fehler Sicherheitsprüfungen untersuchen
Die Aussage „KI hat es geprüft“ lässt offen, welche Fehlerklassen untersucht wurden und welche Nachweise vorliegen. Die eingesetzten Sicherheitsmethoden sollten zu den untersuchten Fehlern passen. Die folgende Übersicht erläutert ihre Zwecke und legt kein allgemeingültiges Scannerpaket fest.
Code, Komponenten und Zugangsdaten
SAST analysiert Code, ohne die Anwendung auszuführen. SCA untersucht Abhängigkeitsversionen auf bekannte Risiken. Secret Scanning sucht nach offengelegten Zugangsdaten. Diese Verfahren zielen auf unterschiedliche Fehler. Ein unauffälliger Bericht zu Abhängigkeiten sagt wenig über eine fehlerhafte Zugriffskontrolle der Anwendung aus. [13]
Eine SBOM verzeichnet die Softwarekomponenten. FOSS bezeichnet freie und quelloffene Software. Weder das Inventar noch die Bezeichnung FOSS sind ein Schwachstellentest. Um Komponenten und Lizenzen zu prüfen, werden das tatsächliche Inventar und aktuelle Nachweise benötigt. [14]
Die laufende Anwendung
DAST sendet Anfragen an eine laufende Anwendung und untersucht deren Verhalten. Eine Quellcodeprüfung ersetzt diese Prüfung nicht. Allgemeine Scanner erkennen möglicherweise nicht, welcher Person ein Datensatz zugeordnet ist oder welche Freigaben im Arbeitsablauf erforderlich sind. ASVS unterscheidet deshalb automatisierte Werkzeuge von anwendungsspezifischer Verifikation. [13] [28]
Verbotene Handlungen und ungewöhnliche Eingaben
Ein Autorisierungstest könnte die Kennung des Datensatzes einer anderen Person verwenden. Ein Missbrauchsfall könnte darin bestehen, Schritte im Arbeitsablauf zu umgehen. Fuzzing untersucht Eingaben, während eigenschaftsbasierte Tests Invarianten anhand generierter Fälle prüfen. Auch jenseits des vorgesehenen Erfolgsfalls müssen passende Erwartungen und Beobachtungspunkte festgelegt werden. [29] [13]
KI-gestützte Sicherheitsanalyse
OpenAI positioniert Codex Security Cloud neben SAST. Anthropic ergänzt Scanner für statische Analyse und Abhängigkeiten und unterscheidet die Quellcodeprüfung von Tests laufender Dienste. Google Cloud verbindet Basisscans mit vertiefter KI-Analyse, deren Prioritäten sich nach dem Risiko richten. Die Empfehlungen sehen somit weiterhin mehrere Methoden vor. [15] [16] [18]
Anthropic unterscheidet den bei Bedarf aufgerufenen Befehl /security-review von einer GitHub Action, die installiert und konfiguriert werden muss. Beide ergänzen bestehende Sicherheitspraktiken und manuelle Reviews. Ob sie automatisch ausgeführt werden, hängt von der Integration ab. [17]
07QUELLENVERGLEICH
Geltungsbereiche institutioneller Empfehlungen
Diese Veröffentlichungen unterscheiden sich in Zweck, Detaillierungsgrad und Verbindlichkeit. Ihre Empfehlungen ergeben kein allgemeingültiges Mindestniveau.
NIST
SSDF 1.1 ordnet Testauswahl, Ausführung und den Umgang mit Befunden in den Lebenszyklus ein. IR 8397 wurde 2021 als Reaktion auf Executive Order 14028 veröffentlicht und legt Verfahren wie Fuzzing und strukturelle Abdeckung fest. Die Verfahren sind im Geltungsbereich und zeitlichen Kontext dieses Dokuments zu verstehen. [03] [13]
BSI und ANSSI
Der Leitfaden behandelt neben generierten Tests und TDD auch das Verständnis der Entwickler, zusätzliche Tests und Sicherheitsreviews. Daraus wird hier abgeleitet, die Verifikation zu verbessern und die Qualität und Sicherheit generierter Ergebnisse gesondert zu prüfen. [12]
ENISA
Abschnitt 4.9 legt SAST und Abhängigkeitsscans in Pull Requests, gezielte negative Tests, geeignetes Fuzzing oder eigenschaftsbasierte Tests sowie Reviews sensibler Änderungen fest. Für KI-generierten und von Menschen geschriebenen Code gelten dieselben Prüfungen im Kontext des Produkts, der Bedrohungen und der anwendbaren Anforderungen. [19]
CIS und SAFECode
Der Beitrag von CIS zu seinem aktualisierten SAFECode-Bewertungsleitfaden betont beobachtbare Nachweise aus Tests und Analysen. KI-generierter Code soll dabei derselben Prüfung, denselben Tests und derselben Validierung unterliegen wie von Menschen geschriebene Software. [20]
NSA und CISA sowie CISA, FBI und ASD’s ACSC
Die CI/CD-Empfehlungen von NSA und CISA betrachten die Pipeline selbst als Angriffsfläche. Sie behandeln unter anderem die Analyse eingecheckten Codes, Zugangsdaten und Informationen über Komponenten. Der davon getrennte Leitfaden zur sicheren Bereitstellung von CISA, dem FBI und ASD’s ACSC ergänzt schrittweise Einführung, Überwachung und Wiederherstellung. Daraus wird hier abgeleitet, dass Tests der Anwendung und der Schutz ihres Bereitstellungsprozesses unterschiedliche Fragen beantworten. [21] [22]
ISACA zur Bewertung der Risiken KI-gestützter Programmierung
Carmichaels Artikel von 2025 erläutert Tests und Aufsicht anhand der wahrscheinlichen Fehler eines Anwendungsfalls, ihrer Auswirkungen und der verantwortlichen Person. Nairs Beitrag von 2026 betrachtet die Programmierassistenten selbst. Dabei geht es um Erfassung, Risikoeinstufung, gestaffelte Kontrollen und fortlaufende Überwachung. Die Aussagen stammen aus Praxisartikeln der genannten Personen. Sie sind keine formalen COBIT-Anforderungen und weisen nicht unabhängig nach, dass ein bestimmtes Testpaket ausreicht. [23] [24]
ISO/IEC 27001 und VDA ISA
ISO/IEC 27001 behandelt ein Informationssicherheitsmanagementsystem. VDA ISA ist ein Fragebogen für TISAX-Assessments. Beide liefern einen Management- und Bewertungskontext für den Geltungsbereich, die anwendbaren Anforderungen und die zugehörigen Nachweise. Bei jeder Bewertung muss die anwendbare Ausgabe berücksichtigt werden. Eine allgemeingültige Scanner-Checkliste liefert keine der beiden Referenzen. [25] [26]
08QUELLENVERGLEICH
Drei OWASP-Veröffentlichungen mit unterschiedlichen Aufgaben
Auch innerhalb einer Organisation können Veröffentlichungen unterschiedliche Aufgaben erfüllen. Bei OWASP sollten deshalb ASVS, WSTG und AISVS voneinander unterschieden werden.
ASVS 5.0.0
ASVS definiert Anforderungen an die Anwendungssicherheit und Verifikationsstufen. Der Bewertungsumfang, die Methoden und begründete Ausnahmen müssen ausdrücklich angegeben werden. Gewöhnliche Scanner können komplexe Zugriffskontrolle oder Geschäftslogik nicht vollständig verifizieren. Anwendungsspezifische automatisierte Tests können dazu beitragen. [27] [28]
WSTG 4.2
WSTG ordnet Sicherheitsfragen und Prüfmethoden den Anforderungen, dem Entwurf, der Entwicklung, der Bereitstellung und dem Betrieb zu. Das Framework lässt sich an organisatorische Prozesse anpassen. Es legt weder eine Stufe nach dem Muster von ASVS noch einen einheitlichen Scanplan fest. [30]
AISVS 1.0, Anhang C
Anhang C behandelt KI-gestützte Codegenerierung. AC.4.2 schreibt auf Stufe 2 automatisierte SAST-, IAST-, DAST-, Secret-, Infrastructure-as-Code- und Composition-Scans für Pull Requests mit KI-generiertem Code vor. AC.4.3 behandelt kritische Befunde und das Blockieren von Merges. Diese expliziten Anforderungen für eine bestimmte Stufe sollten weder stillschweigend zu allgemeinen Empfehlungen abgeschwächt noch als allgemeingültiges Minimum auf jede Anwendung übertragen werden. AISVS-Stufen sind keine ASVS-Stufen. [31]
09QUELLENVERGLEICH
Mit KI entwickelte Software ist nicht immer ein KI-System
Von KI geschriebene Software muss zur Laufzeit kein Modell enthalten. Ihre Autorisierung, Berechnungen und Datenverarbeitung müssen mit Softwaretests geprüft werden. Ruft eine Anwendung Modelle auf, sind zusätzlich Nachweise zum Verhalten der modellgestützten Funktionen bei realistischen Aufgaben nötig.
Das AI RMF von NIST betrachtet Zuverlässigkeit, Validität, Safety, Security und weitere Merkmale der Vertrauenswürdigkeit im jeweiligen Kontext. Bei der Wahl von Metriken und Schwellenwerten ist Urteilsvermögen nötig. Eine mögliche Anwendung wäre, vor Änderungen an Prompts, Modellen oder Retrieval repräsentative Aufgaben, erwartete Nachweise und unzulässige Ergebnisse festzulegen. Anschließend würde das betroffene Verhalten erneut bewertet. Dieses Beispiel veranschaulicht das allgemeine Prinzip. Die zitierte Erörterung schreibt weder diese Reihenfolge noch eine bestimmte Testsuite vor. Unit-Tests allein können die Qualität von Antworten nicht belegen. [32]
10QUELLENVERGLEICH
Was die Empfehlungen gemeinsam haben
Der Vergleich ordnet beabsichtigten Ergebnissen relevante Fehler, geeignete Prüfungen und beobachtete Resultate zu. Hinzu kommen Entscheidungen über die verbleibende Unsicherheit. Diese Zusammenfassung erleichtert die Einordnung der Empfehlungen und ist kein validiertes Testframework.
Die Nachweise sollten zu den Auswirkungen einer Änderung passen. Bei Datengrenzen kommen etwa negative Zugriffs- und Integrationstests infrage, bei visuellen Änderungen Layout- und Interaktionsprüfungen. Für Abhängigkeiten eignen sich Versions- und Schwachstellenprüfungen sowie Tests des betroffenen Verhaltens. Wie viel zusätzliche Prüftiefe nötig ist, hängt vom Risiko ab.
Dokumentiert werden sollten Befehle, Version, Umgebung, ersetzte Komponenten und Ergebnisse sowie übersprungene Schritte, Fehler und erneute Versuche. Mit reproduzierbaren Befehlen und erforderlichen Prüfungen lassen sich Prüfschranken durchsetzen. Die Abschlussmeldung eines Agenten ersetzt keine Ergebnisse. Auch wenn eine Prüfung deterministisch ausgelöst wird, ist das Urteil des LLM deshalb nicht deterministisch.
Aussagekräftige Nachweise zeigen, welche wichtigen Verhaltensweisen durch die Prüfungen gestützt werden, welche Fehler die Prüfungen erkennen könnten und was außerhalb ihres Geltungsbereichs bleibt. Aus der Zahl der Tests allein lässt sich das nicht ablesen.
QUELLEN / 32
Quellen.
Dieser Artikel vergleicht einzelne Veröffentlichungen. Daraus werden keine allgemeingültigen Positionen ihrer Herausgeber abgeleitet. Die Quellenhinweise nennen die jeweiligen Prüfzeitpunkte und machen kenntlich, wo frühere Lektüren übernommen wurden oder vollständige Dokumente nicht verfügbar waren. Beispiele und eine abschließende Zusammenfassung erläutern die Empfehlungen und ihre Grenzen.
- GitHub — Continuous integration (öffnet in einem neuen Tab)
Abschnitte „About continuous integration“ und „About continuous integration using GitHub Actions“. Konfigurierte Workflows für Builds, Tests und benutzerdefinierte Prüfungen sowie ihre Runner-Umgebungen.
- Playwright — Visual comparisons (öffnet in einem neuen Tab)
„Introduction“ zu Darstellungsunterschieden durch Betriebssystem des Hosts, Version, Einstellungen und andere Bedingungen. „Generating screenshots“ zu browser- und plattformspezifischen Vergleichsständen. Verwendet für den Geltungsbereich visueller Nachweise und nicht als Beleg dafür, dass eine bestimmte Prüfung Playwright verwendet hat.
- NIST — Secure Software Development Framework 1.1 (öffnet in einem neuen Tab)
PW.8.1 und PW.8.2, gedruckte S. 15 / PDF-S. 24. Dieser Artikel zitiert ausdrücklich Version 1.1.
- OpenAI — Building an AI-Native Engineering Team (öffnet in einem neuen Tab)
Abschnitte „Testing: What engineers do instead“, „Delegate / Review / Own“ und „Getting started checklist“.
- Dominik Kundel and Gabriel Chua — Testing Agent Skills Systematically with Evals (öffnet in einem neuen Tab)
OpenAI-Entwicklerartikel. Abschnitte 1 und 4 zur Definition von Erfolg sowie zu deterministischen Prüfungen und Bewertungen anhand eines Kriterienrasters. Bezieht sich auf Agent-Skill-Evaluationen und ist keine allgemeingültige Vorgabe für Anwendungstests.
- OpenAI — Best practices (öffnet in einem neuen Tab)
Abschnitt „Improve reliability with testing and review“. Laufend gepflegte Dokumentation.
- Anthropic — Best practices for Claude Code (öffnet in einem neuen Tab)
Abschnitt „Give Claude a way to verify its work“. Laufend gepflegte Dokumentation. Konfiguration und Ausführungsumgebung sind relevant.
- Anthropic — Desktop application (öffnet in einem neuen Tab)
Abschnitt „Auto-verify changes“. Desktop-spezifische Fähigkeit und keine Garantie vollständiger Regressionstests.
- Google — What to look for in a code review (öffnet in einem neuen Tab)
Abschnitt „Tests“. Allgemeine Engineering-Empfehlungen und keine Evaluation eines bestimmten KI-Produkts.
- Google — Jules Agent Update: Faster, Smarter, More Reliable (öffnet in einem neuen Tab)
Abschnitt „Better test habits“. Historische Produktankündigung mit Wahrscheinlichkeitsaussagen.
- Kathy Korevec, Mehadi Hassen and Yiguang (Amanda) Zhang — Meet Jules’ sharpest critic and most valuable ally (öffnet in einem neuen Tab)
Abschnitte „Critic augmented generation“, „What the critic does“ und „Here’s how it works“. Historische Funktionsbeschreibung.
- BSI and ANSSI — AI Coding Assistants (öffnet in einem neuen Tab)
Abschnitte 2.3 und 3.3, PDF-S. 6 und 9. Detaillierte Lektüre vom 1. August 2026 beibehalten. Die Herausgeberseite wurde am 14. Oktober erneut geprüft, das vollständige PDF konnte bei dieser Aktualisierung jedoch nicht abgerufen werden.
- NIST — IR 8397: Guidelines on Minimum Standards for Developer Verification of Software (öffnet in einem neuen Tab)
Abschnitte 1.1–1.3 und 2.1–2.11. Zeitlich eingeordnete Empfehlungen als Reaktion auf Executive Order 14028. Die Verfahren haben einen bestimmten Geltungsbereich und sind keine allgemeingültige heutige Vorgabe.
- OWASP — Developer Guide: Dependencies (öffnet in einem neuen Tab)
Abhängigkeitsmanagement, Komponenteninventar, Softwarestücklisten und Software Composition Analysis.
- OpenAI — Codex Security Cloud FAQ (öffnet in einem neuen Tab)
Abschnitt „Does it replace SAST?“. Bezieht sich auf das dokumentierte Sicherheitsangebot.
- Anthropic — Catch security issues as Claude writes code (öffnet in einem neuen Tab)
Abschnitt „How this fits with other security tools“. Quellcodeprüfung im Vergleich zur Prüfung einer laufenden Website.
- Anthropic — Automated Security Reviews in Claude Code (öffnet in einem neuen Tab)
Prüfungen bei Bedarf und die konfigurierte GitHub Action. Die Seite zeigt den 16. März 2026 an, ohne dies als Erstveröffentlichung oder letzte Aktualisierung zu kennzeichnen.
- Google Cloud — Vulnerability management with AI (öffnet in einem neuen Tab)
Abschnitt „Phase 2: Scan and prioritize“. Basisscans, vertiefte KI-Scans und risikobasierte Priorisierung.
- ENISA — Secure by Design and Default Playbook v1.0 (öffnet in einem neuen Tab)
Abschnitte 4.9 und 4.23. Veröffentlichte Version 1.0, getrennt vom Konsultationsentwurf.
- CIS — Turning Secure Software Development into a Measurable Practice (öffnet in einem neuen Tab)
Abschnitte „Expanded Guidance on Artificial Intelligence“ und „A Continued Focus on Evidence“. Beschreibt die Aktualisierung des CIS/SAFECode-Bewertungsleitfadens.
- NSA and CISA — Defending CI/CD Environments (öffnet in einem neuen Tab)
Codeanalyse, Zugangsdaten und SBOM/SCA, S. 11–15. Frühere Lektüre des vollständigen Dokuments beibehalten. Indexierte Auszüge waren am 14. Oktober 2026 verfügbar, das vollständige PDF konnte jedoch nicht abgerufen werden.
- CISA, FBI and ASD’s ACSC — Safe Software Deployment (öffnet in einem neuen Tab)
Abschnitte „Introduction“, „Objectives“ und „Key phases“. Der vollständige Text wird von einem Mitherausgeber bereitgestellt. Die australische Seite trägt das Datum 25. Oktober 2024.
- Mary Carmichael — Is Vibe Coding Ready for Prime Time? (öffnet in einem neuen Tab)
Abschnitt „Adopting a Risk-Based Approach“. Namentlich verfasster, von ISACA veröffentlichter Praxisartikel und kein formaler Standard.
- Anjali Gopinadhan Nair — Securing the AI Frontier (öffnet in einem neuen Tab)
Abschnitt „A Four-Phase Framework“. Namentlich verfasster Praxisartikel. Seine berichteten Leistungszahlen werden hier nicht übernommen.
- ISO — ISO/IEC 27001:2022 (öffnet in einem neuen Tab)
Nur die öffentliche Beschreibung des Managementsystemstandards. Keine Behauptung einer vollständigen normativen Bewertung.
- ENX — VDA ISA and TISAX Download Center (öffnet in einem neuen Tab)
Angaben zu Version und Bewertungsumfang. Anwendbare Ausgaben werden gesondert bestimmt. Dieser Artikel ist keine Zuordnung zu ISA-Kontrollen.
- OWASP ASVS 5.0.0 — What is the ASVS? (öffnet in einem neuen Tab)
Abschnitte „Scope of the ASVS“ und „Application Security Verification Levels“. Quelle mit festgelegter Version.
- OWASP ASVS 5.0.0 — Assessment and Certification (öffnet in einem neuen Tab)
Abschnitte „Verification reporting“, „Scope of Verification“, „Verification Mechanisms“ und „The Role of Automated Security Testing Tools“.
- OWASP WSTG 4.2 — Introduction (öffnet in einem neuen Tab)
Abschnitte „Risk-Driven Security Requirements“, „The Need for a Balanced Approach“ und „Test Automation“. Quelle mit festgelegter Version.
- OWASP WSTG 4.2 — The Web Security Testing Framework (öffnet in einem neuen Tab)
Übersicht und Lebenszyklusphasen. Flexibles Framework, getrennt von einer Verifikationsstufe.
- OWASP AISVS 1.0 — Appendix C: AI for Code Generation (öffnet in einem neuen Tab)
AC.4.2 und AC.4.3, Stufe 2. Veränderlicher main-Branch im Verzeichnis 1.0. Dieser Artikel bezieht sich auf den abgerufenen Wortlaut.
- NIST AI RMF 1.0 — AI Risks and Trustworthiness (öffnet in einem neuen Tab)
Abschnitte 3 und 3.1 zu Kontext, Metriken, Schwellenwerten, Validität und Zuverlässigkeit. Bezieht sich auf das Verhalten von KI-Systemen und nicht lediglich auf KI-geschriebenen Code.