Praxisanleitung zu den 18 Einträgen
Alle im Bericht genannten relativen Dateipfade beziehen sich auf das Artefaktpaket. Es enthält keine eingerichtete Laufzeit. Praxisanleitung und Testbericht erklären erwartete Ausgaben und tatsächlich beobachtete Resultate getrennt.
Praxisanleitung: Auftrag, Ausführung und Ergebnis
Stand: 29. Oktober 2026. Alle 18 konkret im Whitepaper genannten Einträge sind hier adressiert. Nicht alle wurden vollständig getestet. Zwölf wurden im bezeichneten Umfang ausgeführt, drei teilweise, zwei waren blockiert und einer scheiterte technisch. Agentenmethoden, native Werkzeugläufe und Offline-Tests sind jeweils benannt. Ein ausgeführter Test mit beobachtetem Fehler ist kein bestandenes Produkt.
Arbeiten Sie mit einer eigenen entbehrlichen Kopie und einem frischen Ordner eigener-lauf/. Überschreiben Sie die aufgezeichneten Originale nicht. Die Shell-Beispiele setzen Bash/WSL und das Hauptverzeichnis der Testablage voraus, sofern ein Abschnitt keine andere Umgebung nennt. SkillSpector verwendet ausdrücklich den getesteten Windows-Python-Einstieg. Werkzeuge müssen separat eingerichtet und aufgerufen werden können. Die Installation aller nativen Codex-/Claude-Plugins ist nicht Bestandteil der Nachweise. Textbasierte Skills werden durch einen ausdrücklichen Auftrag an den Host verwendet; dafür gibt es keinen erfundenen universellen skills run-Befehl.
source-manifest.json fixiert die ursprünglich verwendeten Skillquellen. python fetch_sources.py beschafft diese Anleitungen und Ressourcen, führt sie aber nicht aus und installiert keine Scanner. Die zusätzlichen CodeQL- und Compilerquellen sind unter runs/followup/ mit eigenen Manifesten/Hashes dokumentiert. Ein frisches ZIP enthält keine Runtime und keine Git-Verzeichnisse. baseline/, fixture/ und fixed/ sind eigene künstliche Testquellen; CodeQLs öffentliche Testdatei ist ein getrenntes Ziel und wurde niemals ausgeführt.
Zu jedem Eintrag folgen Eingabe, konkreter Auftrag, Dateien, Beobachtung und verbleibende Grenze. Bei blockierten Einträgen ist die Aufrufvorlage ausdrücklich nur dokumentiert. Die vollständigen Messwerte stehen in TESTBERICHT.md und runs/followup/results.json.
01 · security-threat-model
Teststand: Ausgeführt: Agentenmethode.
Revision, Architektur, Datenklassen und vom Eigentümer bestätigter Betriebskontext.
Beauftragen Sie den geladenen Skill: „Erstelle für diese Revision ein Bedrohungsmodell. Frage fehlenden Betriebskontext nach. Trenne Codebelege, bestätigte Betriebsannahmen und Hypothesen; bewerte lokalen Lehrbetrieb und hypothetischen Internetbetrieb getrennt.“
Ergebnisdateien: runs/threat-model/fixture-threat-model.md
Beobachtet: Komponenten, Datenfluss, Schutzwerte, Annahmen, drei Bedrohungen, bedingte Priorität und Maßnahmen.
Grenze: Kein realer Internetbetrieb und kein Angriff getestet.
02 · audit-context-building
Teststand: Ausgeführt: Host angepasst.
Dieselbe Revision; ausdrücklich ausgewählte fünf Portalfunktionen und ein Handler.
Auftrag: „Baue zunächst ausschließlich Kontext auf. Beschreibe Eingaben, Aufrufer, Zustandsänderungen, Abhängigkeiten, Annahmen und Datenflüsse je Funktion; vergib noch keine Befunde oder Schwere.“ Verwenden Sie die im Host unterstützte Delegation.
Ergebnisdateien: runs/context/audit-context/DOSSIER.md; functions/; execution.json
Beobachtet: Sechs getrennte Codex-Funktionsagenten erstellten ein verknüpftes Dossier.
Grenze: Keine native Claude-Workflow-API und kein Test einer installierten Pluginintegration.
03 · codeql
Teststand: Teilweise: nativer Demonstrationslauf.
CodeQL-CLI, passende Sprachpakete, Python, frischer Ausgabeordner und zulässiger Quellbestand. Das gespeicherte Beispiel stammt aus öffentlichem MIT-Code.
Für den vollständigen Skill: Datenbank bauen, Extraktionsqualität prüfen, projektspezifische Datenmodelle untersuchen/ergänzen, explizite Suite erzeugen und deren Auflösung prüfen; erst danach analysieren. Die Beispielbefehle unten demonstrieren nur den nativen Teil.
Ergebnisdateien: runs/followup/codeql/codeql.db/; diagnostics/quality.log; raw/demo.qls; raw/results.sarif
Beobachtet: CodeQL 2.27.3, eine Datei, 44 Baseline-Codezeilen, null Extraktionsfehler. Eine Abfrage liefert 13 Meldungen; eine davon ist im Upstream als SPURIOUS markiert.
Grenze: Kein vollständiger CodeQL-Skill-Workflow; kein CodeQL-Portaltest; keine 13 neuen bestätigten Schwachstellen.
04 · semgrep
Teststand: Teilweise: sechs native Regelläufe.
Semgrep 1.182.1 oder eine separat verifizierte Version; Zielkopie; ausgewählte kompatible Regeln. Pro ist ein eigener Zugang.
Wählen Sie Regeln, Ziel und Ausgabeordner. Starten Sie den unten gezeigten Einzellauf. Für die ursprüngliche Sechserbasis dokumentiert run_semgrep.sh den verwendeten Ablauf. Lesen Sie Exitcode, Fehler, übersprungene Dateien und Findings zusammen.
Ergebnisdateien: runs/semgrep/rulesets.json; scans.json; raw/; results/results.sarif
Beobachtet: Sechs JSON-/SARIF-Paare, null Basismeldungen. Zwei Drittanbieter-Regelläufe wegen Regelproblemen unvollständig.
Grenze: Pro nicht verfügbar; null Treffer belegen keine Fehlerfreiheit. Die kurze Anleitung ersetzt nicht die sechs dokumentierten Regelläufe.
05 · sarif-parsing
Teststand: Ausgeführt: Verlust beobachtet.
Vorhandene native SARIF-Dateien und unveränderte Originale.
Auftrag: „Parse diese SARIF-Dateien, löse die Schwere nach SARIF-Regeln auf, zeige Roh- und Deduplizierungszahl und bewahre unterschiedliche Codepositionen.“ Der konkrete gespeicherte Fall lässt sich mit python process_sarif.py nacharbeiten, wenn die gepinnten Ressourcen und ursprünglichen Eingaben vorhanden sind.
Ergebnisdateien: runs/sarif/combined.sarif; summary.json; findings.json; findings.csv
Beobachtet: Originalhelper: zwei Stellen werden wegen desselben Platzhalter-Fingerprints zu einer. Begrenzte eigene Ableitung erhält beide.
Grenze: Ein beobachteter Verarbeitungsfehler ist kein bestandener unveränderter Workflow; keine vollständige SARIF-Schemavalidierung.
06 · fp-check
Teststand: Ausgeführt: begrenzte Agentenmethode.
Konkrete Kandidaten mit Revision, Codeposition und behauptetem Angriffsweg.
Auftrag: „Prüfe diese vorgegebenen Behauptungen mit fp-check. Suche Aufrufer, wirksame Schutzbedingungen und Gegenbelege. Begründe jedes Urteil; fehlende Voraussetzungen bleiben im führenden Prozess ungeklärt.“
Ergebnisdateien: runs/fp-check/verdicts.md; runs/unit/cross-customer-and-retest.json
Beobachtet: Zwei zutreffende, eine widerlegte vorgegebene Behauptung im untersuchten Funktionsvertrag.
Grenze: Erreichbarkeit über einen echten Login oder ein Netzportal unbewertet; kein Blindbenchmark.
07 · variant-analysis
Teststand: Ausgeführt: eigene AST-Suche nach Methode.
Bekannte Ursache und ein belegter Ausgangsfall; dieselbe Zielrevision.
Auftrag: „Leite aus dem fehlenden Eigentümervergleich eine enge Suchsignatur ab. Erweitere sie schrittweise; prüfe jeden Treffer einschließlich sicherer Gegenfälle.“ Reproduktion der gespeicherten Suchstufen: python variant_search.py.
Ergebnisdateien: runs/variants/search.json; variant-report.md; variant_search.py
Beobachtet: Zusätzlicher betroffener Exportweg; geschützte Abrufvariante verworfen.
Grenze: Suche nach bekannter Ursache; kein initialer allgemeiner Schwachstellenscanner.
08 · differential-review
Teststand: Ausgeführt: Agentenreview mit nativen Git-Daten.
Git-Ausgangs- und Zielrevision, Historie, relevante Aufrufer und Tests. Im ZIP stehen baseline/ und fixture/ ohne Git-Metadaten.
Auftrag: „Prüfe den Sicherheitsbezug dieses Diffs mit differential-review. Beziehe Historie, Blame, Aufrufer und Testabdeckung ein. Verändere die untersuchte Arbeitskopie nicht.“ Für eine frische Wiederholung aus dem ZIP zuerst eine eigene Testhistorie aus baseline/ und fixture/ in einem neuen Verzeichnis aufbauen.
Ergebnisdateien: runs/diff/review.md; changes.stdout.txt; history.stdout.txt; blame.stdout.txt
Beobachtet: Vier entfernte Schutzzeilen in zwei Funktionen; drei bestehende Unit-Tests bestehen trotzdem.
Grenze: Keine native PR-/CI-Integration getestet; externe produktive Aufrufer unbekannt.
09 · insecure-defaults
Teststand: Teilweise: Offline-Tests und manueller Review.
Unterstützter Workflow-Host, Konfigurationsquellen und deren tatsächliche Verbraucher.
Beauftragen Sie den Workflow mit allen sechs Kategorien: Ersatzgeheimnisse, Fail-open, schwache Kryptographie, zu weite Rechte, Standardzugangsdaten und Debug-Datenlecks. Verlangen Sie für jeden Kandidaten einen belegten Weg zur Sicherheitswirkung. Offline-Harness und Mutationstests gesondert ausweisen.
Ergebnisdateien: runs/insecure-defaults/report.md; workflow-tests.; mutation-tests.; seed-coverage.*
Beobachtet: 102 Offline-Assertions bestanden; 36 Mutationen erkannt. Einer von 18 dokumentierten Seed-Fällen passt auf diesem Host nicht. Ersatzschlüssel und DEBUG ungenutzt.
Grenze: Keine sechs nativen Analyseagenten-Sweeps und kein vollständiger nativer Workflowlauf.
10 · semgrep-rule-creator
Teststand: Ausgeführt: Methode und native Regeltests.
Bekannte Ursache, drei positive und drei sichere Beispiele; Semgrep.
Auftrag: „Entwickle testgetrieben eine möglichst enge Regel. Prüfe die Syntaxstruktur, markiere positive Fälle mit ruleid und sichere Fälle mit ok, validiere und iteriere bis alle Tests bestehen.“ Danach mit den unten gezeigten Befehlen testen und auf die Zielkopie anwenden.
Ergebnisdateien: runs/rules/portal-owner-check/portal-owner-check.yaml und .py; tests.txt; validate.txt; fixture.sarif
Beobachtet: Drei positive und drei sichere Beispiele bestanden; zwei bekannte Zielstellen gemeldet.
Grenze: Lokale Musterregel; keine Modellierung beliebiger vorgeschalteter Berechtigungsdienste.
11 · harness-writing
Teststand: Ausgeführt: Quelltext, Builds und begrenzte Läufe.
Deterministische Parserfunktion mit begrenzter Eingabe; Compiler und Fuzzer.
Auftrag: „Erstelle LLVMFuzzerTestOneInput, begrenze die Eingabe auf 32 Byte, behandle ungültige und leere Eingaben und vermeide Netzwerk, globale Zustandsreste und Prozessabbrüche.“ Kompilieren Sie die Testhülle; prüfen Sie sie zusätzlich mit Seeds und einer getrennten absichtlichen Absturzkontrolle.
Ergebnisdateien: runs/fuzzing/harness.cc; runs/followup/fuzzing/
Beobachtet: Mit Clang/libFuzzer und AFL++-GCC kompiliert und ausgeführt.
Grenze: Künstlicher Nummernparser, keine Portalberechtigungsprüfung; die Kontrollfunktion ist ein gesonderter Test.
12 · libfuzzer
Teststand: Ausgeführt: begrenzte native Kampagne.
Clang 14 mit libFuzzer und Sanitizer-Runtimes, Harness, Seeds, eigener Ausgabeordner.
Mit -fsanitize=fuzzer,address,undefined bauen. Mit -runs=20000, -max_len=32, festem Seed und Ressourcenlimits starten. Korpus, Log und etwaige Fehlerdateien erhalten.
Ergebnisdateien: runs/followup/fuzzing/libfuzzer/build.log; run.log; corpus/; control-run.log
Beobachtet: 20.000 Durchläufe; 13 gemeldete Coverage-Zähler, 44 Features; kein Parserabsturz. Absichtliche Kontrollfunktion: Exit 77.
Grenze: Kurze Kampagne; keine Vollabdeckung und kein Sicherheitsbeweis. Positive Kontrolle ist kein gefundener Parserfehler.
13 · aflpp
Teststand: Ausgeführt: begrenzte native Kampagne.
AFL++ 4.00c, GCC-Instrumentierung, eigener stdin-Driver, Seeds; isolierte Testumgebung.
Mit afl-g++ Harness und Driver kompilieren. Mit -V 15 eine zeitlich begrenzte Kampagne starten. Den vom Compiler benötigten AFL_PATH verwenden; keine Kernel- oder Boot-Einstellungen verändern.
Ergebnisdateien: runs/followup/fuzzing/afl/build.log; run.log; out/default/queue/; fuzzer_stats
Beobachtet: 15 Sekunden, 6.444 Ausführungen, zehn Korpuseinträge; null gespeicherte Abstürze/Hänger.
Grenze: Clang-Wrapper zunächst inkompatibel. Crash-Reporting-Vorprüfung war per Umgebungsoption übergangen; zuverlässige Crash-Erfassung nicht positiv kontrolliert.
14 · penetration-testing-with-strix
Teststand: Blockiert: kein aktiver Test.
Arbeitsfähiger Docker-Daemon, freigegebener Modellzugang, entbehrliche Zielkopie bzw. ausdrücklich freigegebenes Staging, Auftrag und Limits.
Zuerst docker info, strix --version und Modellkonfiguration prüfen. Danach den dokumentierten Headless-Aufruf mit Ziel, --max-budget und --max-turns verwenden. Bei fehlenden Voraussetzungen stoppen; keinen Lauf simulieren.
Ergebnisdateien: Nicht erzeugt. Erwartet: strix_runs/
Beobachtet: Docker antwortete auch nach Startversuch nicht innerhalb des Vorprüflimits.
Grenze: Kein Strix-Pentest und keine PoC-Validierung; die Aufrufvorlage unten wurde nicht ausgeführt.
15 · Shannon
Teststand: Blockiert: kein aktiver Test.
Docker, Node.js 18+, freigegebener Providerzugang, Zielquellen und eigene freigegebene Testbereitstellung.
Installations-/Startweg der festgehaltenen Shannon-Dokumentation verwenden, CLI-Version separat pinnen, Quelle und Test-URL verbinden. Authentisierung, Aktionen, Budget und Abbruch müssen vor dem Lauf feststehen.
Ergebnisdateien: Nicht erzeugt. Erwartet: Security-Assessment-Report.md/.pdf sowie interne Sitzungsdaten unter .shannon/.
Beobachtet: Kein Lauf gestartet; Docker weiterhin nicht arbeitsfähig.
Grenze: Dokumentierte Anleitung ist kein eigener End-to-End-Test. Keine Produktbestätigung anhand fremder Benchmarkberichte.
16 · SkillSpector / skill-inspector
Teststand: Ausgeführt: native statische Scans plus separater Agentenreview.
Zwei ausschließlich zu lesende Test-Skills und SkillSpector 2.12.0.
Beide Pakete mit --no-llm getrennt als JSON, Markdown und SARIF scannen. Unter Windows die native Standardausgabe erfassen. Danach den skill-inspector-Auftrag ausführen: Inhalt, Datenwege, Einzelbefunde und Gesamtscore semantisch prüfen. Niemals die schädlichen Instruktionen ausführen.
Ergebnisdateien: runs/skillspector/benign.{json,md,sarif}; injection.{json,md,sarif}; inspector-verdict.md
Beobachtet: Harmlos ohne Befund. Schädlich: HIGH-Einzelbefund bei Score 20, Gesamtschwere LOW, Empfehlung SAFE. Getrennter Agentenreview: REJECT.
Grenze: Produktseitige LLM-Analyse ausgeschaltet; keine allgemeine Fehlerrate und kein Installationstest des verdächtigen Skills.
17 · mcp-server-security-review
Teststand: Ausgeführt: einzelner synthetischer Handler.
Werkzeugbeschreibung, Handlercode und unabhängige Identitätsquelle.
Auftrag: „Verfolge vom Toolargument bis zur Aktion, welche Identität die Berechtigung bestimmt. Prüfe Objekt-/Aktionsrechte, Eingaben und Seiteneffekte. Trenne Handlerbefunde von ungeprüften Anforderungen an Transport, SDK, OAuth und Runtime.“
Ergebnisdateien: runs/mcp-review/report.md
Beobachtet: Der Handler vertraut einer modellseitig gelieferten Kundenkennung und ignoriert den unabhängigen Identitätsparameter; begrenzter Fixvorschlag dokumentiert.
Grenze: Kein vollständiger MCP-Server, keine Protokollkonformitätsprüfung und kein aktiver Serverangriff.
18 · Codex Security
Teststand: Gescheitert: echter Standardlauf.
Freigegebene CLI-Version und Anmeldung, Quellkopie, eigener Ergebnisordner und Zeit-/Kostenlimits.
Zuerst info und scan --dry-run prüfen; danach den Standardscan tatsächlich ohne --dry-run starten. Erst einen finalisierten Ergebnissatz auswerten. Die konkrete lokale Invocation ist in execute_checks.py codex und den execution.json-Dateien aufgezeichnet.
Ergebnisdateien: runs/codex-security/info.; dry-run.; scan.execution.json und scan.stdout.txt; kein finaler report.md/findings.json/coverage.json-Satz.
Beobachtet: Anmeldung und Dry-run erfolgreich. Echter Scan im Preflight technisch abgebrochen; nativer Prozess und MCP-Hilfsprogramm melden Fehler.
Grenze: Kein abgeschlossener Scan; Diff und Deep nicht gestartet. Kein neues kostenpflichtiges Wiederholen in dieser Runde.
Konkrete Befehlsbeispiele
Die native Einzelschritt-Syntax der erfolgreichen Läufe ist unten als Vorlage angegeben. Eigene Ausgabepfade sind gewählt. Für exakte Originalbefehle einschließlich Hostpfaden lesen Sie die jeweiligen Skripte und Ausführungslogs; die gesamte Hostinstallation wurde nicht portabel automatisiert.
Semgrep-Einzellauf und Regressionsregel
mkdir -p eigener-lauf/semgrep
semgrep scan --config p/python --metrics=off \
--json-output eigener-lauf/semgrep/results.json \
--sarif-output eigener-lauf/semgrep/results.sarif fixture/
semgrep --validate --config runs/rules/portal-owner-check/portal-owner-check.yaml
semgrep --test --config runs/rules/portal-owner-check/portal-owner-check.yaml \
runs/rules/portal-owner-check/portal-owner-check.py
Der Einzellauf ist nicht die aufgezeichnete Basis aus sechs Regelläufen. Zwei ihrer Drittanbieter-Regelkompilationen blieben fehlerhaft. Die lokale Regressionsregel ist bewusst auf den bekannten Fall zugeschnitten.
libFuzzer
mkdir -p eigener-lauf/libfuzzer/corpus eigener-lauf/libfuzzer/artifacts
printf '123' > eigener-lauf/libfuzzer/corpus/numeric
clang++-14 -g -O1 -fsanitize=fuzzer,address,undefined \
runs/fuzzing/harness.cc -o eigener-lauf/libfuzzer/fuzz
eigener-lauf/libfuzzer/fuzz eigener-lauf/libfuzzer/corpus \
-runs=20000 -max_len=32 -timeout=2 -rss_limit_mb=256 \
-seed=20261029 -print_final_stats=1 \
-artifact_prefix=eigener-lauf/libfuzzer/artifacts/
Clang, Standardbibliotheken und Sanitizer-Runtimes müssen verfügbar sein. Das Beispiel beginnt vereinfacht mit einem Seed. Die berichteten Messwerte stammen aus dem protokollierten Lauf mit acht bereits vorhandenen Eingabedateien; andere Startbestände können andere Coverage-/Korpuswerte ergeben. Die gespeicherte separate Kontrollfunktion ist unter runs/followup/fuzzing/libfuzzer/control.cc abgelegt; ihr erwarteter Absturz ist eine Kontrollbeobachtung.
AFL++
mkdir -p eigener-lauf/afl/seeds
printf '123' > eigener-lauf/afl/seeds/numeric
afl-g++ -g -O1 runs/fuzzing/harness.cc \
runs/followup/fuzzing/afl/driver.cc -o eigener-lauf/afl/fuzz
AFL_NO_UI=1 AFL_SKIP_CPUFREQ=1 afl-fuzz \
-V 15 -m 256 -t 1000 -i eigener-lauf/afl/seeds \
-o eigener-lauf/afl/out -- eigener-lauf/afl/fuzz
Das vereinfachte Beispiel beginnt mit einem Seed; die gespeicherte Kampagne verwendete numeric und malformed. Die Zahl der zeitabhängigen Ausführungen und die Korpusentwicklung können bei einer Wiederholung abweichen. Der dokumentierte Lauf benötigte zusätzlich AFL_I_DONT_CARE_ABOUT_MISSING_CRASHES=1; diese Umgehung der Crash-Reporting-Vorprüfung wird nicht als allgemein empfehlenswerter Standard gesetzt. Stoppt Ihre Vorprüfung, richten Sie eine geeignete isolierte Umgebung ein. Der ursprüngliche Clang-Wrapperfehler und der erfolgreiche GCC-Weg sind getrennt protokolliert. System- oder Boot-Sicherheitsfunktionen werden für dieses Beispiel nicht abgeschaltet.
SkillSpector unter dem getesteten Windows-Python-Einstieg
python -c 'from skillspector.cli_entry import app; app()' scan skill-fixtures/injection --no-llm --format json
Der Aufruf zeigt den nativen Bericht im Terminal; python muss zur Umgebung mit installiertem SkillSpector gehören. Für die tatsächlich gespeicherten Dateien verwendete der Versuch python execute_checks.py skillspector. Dieses Skript setzt runtime/skillspector-env/ voraus, erfasst die native Ausgabe, prüft JSON/SARIF und speichert als UTF-8. Wegen seiner festen Testordner führen Sie es nur in einer neuen entbehrlichen Kopie aus. Wiederholen Sie den Scan für benign und die Formate markdown/sarif. Die statische Empfehlung wird anschließend inhaltlich überprüft; die im Test beobachtete REJECT-Entscheidung wurde vom bearbeitenden Agenten erzeugt.
Strix und Shannon: dokumentiert, nicht ausgeführt
docker info
strix --version
strix -n -t ./entbehrliche-arbeitskopie --scan-mode quick \
--max-budget 1 --max-turns 10 --instruction-file scope.md
Voraussetzungen: eingerichteter Modellzugang (STRIX_LLM und LLM_API_KEY), eigene Zielkopie und ein verbindlicher Auftrag in scope.md. Lokale Zielverzeichnisse sind für Strix schreibbar. Budget und Schrittlimit begrenzen den Lauf; ein verkürzter Lauf ist kein vollständiger Test. Hier scheiterte bereits docker info; die Strix-Invocation wurde nicht gestartet.
Für Shannon dokumentiert der festgehaltene Quickstart npx @keygraph/shannon@latest setup und anschließend npx @keygraph/shannon@latest start -u <freigegebene-test-url> -r <zielkopie>. Das sind Vorlagen aus der Quelle, keine hier ausgeführten Befehle. Vor einem reproduzierbaren Lauf ersetzen Sie latest durch eine überprüfte konkrete CLI-Version, richten den Providerzugang ein und legen Ziel, Aktionen, Budget und Abbruch fest. Ein interaktiver Wizard ist kein unbeaufsichtigt geeigneter Aufruf.
CodeQL-Demonstration und Codex Security
Die vollständig aufgezeichnete CodeQL-Demonstration steht in run_codeql_followup.sh: eigene Datenbank aus dem öffentlichen Beispiel, Datenbank-Qualitätsprüfung, explizite Ein-Query-Suite, Auflösung und native SARIF-Analyse. Verändern Sie für eine Wiederholung den Ausgabeordner im Skript; eine existierende Datenbank wird nicht still überschrieben. Für den vollständigen Skill folgen zusätzlich die Suiteauswahl und projektspezifische Modellierungsfolge aus der Skillquelle. Aus dem Demolauf darf keine Portalbewertung abgeleitet werden.
Die genaue Codex-Security-Invocation einschließlich --dry-run, --auth chatgpt, --headless, --json, --max-cost 1 und --max-time 2 steht in execute_checks.py und runs/codex-security/*.execution.json. Der Standardlauf ohne --dry-run wurde tatsächlich begonnen und scheiterte. Wiederholungen können Modellressourcen kosten; verwenden Sie einen neuen Ausgabeordner und prüfen Sie die Finalisierung.