Was sich geändert hat, ist nicht nur ein weiteres Regelwerk – es ist eine Brücke zwischen AI-Sicherheitsbedenken und ausgereiften AppSec-Workflows. CodeQL verfolgt nun nicht vertrauenswürdige Werte, die das System-Prompt eines Modells beeinflussen können, und markiert, wenn diese Flüsse sensible SDK-Aufrufe erreichen. Durch die Erweiterung der Sinks für APIs großer Anbieter erkennt die Erkennung reale Muster, die Entwickler verwenden, um Systemanweisungen, Sitzungsrichtlinien und Tool-Verkabelungen zusammenzustellen. Das Ergebnis ist ein vertrautes Sicherheitsevent: ein Dataflow-Befund, der priorisiert, behoben und durch Richtlinien verhindert werden kann, anstatt eine vage „AI-Fehlverhalten“-Anekdote, die selten auf CI/CD-Kontrollen abgebildet wird.

Für technische Führungskräfte stellt dies Prompt Injection als ein Problem der Abhängigkeits-Hygiene und Eingabevalidierung dar. Wenn System-Prompts benutzerkontrollierte Zeichenketten übernehmen – Feature Flags, Mandanteneinstellungen oder CMS-Inhalte – können Modelle dazu gebracht werden, Anweisungen zu umgehen, Tools offenzulegen oder Kontext zu leaken. Der Ansatz von CodeQL bringt diese Risiken in SARIF, PR-Anmerkungen und Baseline-Metriken ein und ermöglicht dieselben Eskalationspfade wie klassische Injection-Klassen. Entscheidend ist, dass es Produktverantwortlichen hilft, Risiken in einer Sprache zu quantifizieren, die Prüfer verstehen: Dataflow von nicht vertrauenswürdigen Quellen zu sensiblen Sinks, unterstützt durch reproduzierbare Abfragen und versionierte Richtlinien.

Die Einführung dieser Funktion bedeutet weniger, Prompts neu zu schreiben, sondern Grenzen zu kodifizieren. Teams sollten eine aktuelle CodeQL-Version festlegen, die neue System-Prompt-Injection-Abfrage für JS/TS aktivieren und organisationsweite Baselines durchführen. Beginnen Sie mit Repositories, die Agenten, Tool-Aufrufe oder RAG-Pipelines bauen; erweitern Sie dann auf Dienste, bei denen Prompts aus Konfigurationen zusammengesetzt werden. Die Priorisierung sollte Flüsse nach Ausnutzbarkeit klassifizieren: Grad der Benutzerkontrolle, Vorhandensein von Template-Sicherungen und Macht der nachgelagerten Tools. Wo Lücken bestehen, schreiben Sie kleine benutzerdefinierte Modelle für proprietäre SDK-Aufrufe, um eine Abdeckung auf Produktionsniveau sicherzustellen.

Erwarten Sie Grenzen: Statische Analyse kann dynamische Tool-Graphen, promptübergreifende Kompositionen oder Laufzeit-Schutzmaßnahmen wie Funktionsaufrufbeschränkungen nicht vollständig simulieren. Aber das galt auch für SSRF oder Deserialisierung, bis sich Ökosysteme auf Muster und Linter einigten. Das größere Bild ist Konvergenz: AI-Risiken werden in SDLC-Gates normalisiert und schaffen eine gemeinsame Sprache für Sicherheit, Plattform und Compliance. Das erhöht die Anforderungen für Anbieter und interne Plattformen gleichermaßen – AI-Funktionen ohne Code-Scanning-Abdeckung auszuliefern, wird zunehmend so wirken wie APIs ohne Authentifizierungstests zu veröffentlichen.