The Trust Trap – Security von Coding Assistants (Clemens Hübner)

Clemens Das zeigt ganz gut, was da die Gefahren sind. Zum einen natürlich aus dem geopolitischen Aspekt, aber auch, weil das ganz gut demonstriert, wie, wenig wir einfach wissen, auf was wurde da genau trainiert, wie wurde das trainiert, ist das hier absichtlich entstanden, ist das ein blöder Seiteneffekt, weil man irgendwie da einen falschen Bias in den Trainingssachen hat. Man weiß es einfach nicht, aber das muss einem einfach bewusst sein. Wir benutzen LLMs gerne, sie sind super wertvoll, aber wir verstehen nicht so ganz, was unter der Haube passiert, auch worauf sie trainiert wurden, was für Rahmenbedingungen sie vielleicht mitbringen.

Hendrik Der Thomas, der hat uns jetzt richtig Appetit gemacht auf KI im Coding, das mal einzusetzen, zu schauen, was kann man damit alles machen und ja, die Versprechen der KI-Technologie, die klingen ja auch verlockend. Effizienzboost, Ten Times Developer, Revolution. Ich weiß nicht, wie oft man das Wort Revolution schon gehört hat im Rahmen von KI-Technologie. Aber es gibt eine entscheidende Frage, die dabei vielleicht beim ganzen Enthusiasmus oft übersehen wird. Wie sicher ist denn eigentlich der Code, den KI-Assistenten schreiben? Die Antwort ist da leider ernüchternd. KI-Code bringt neue Risiken mit sich. Risiken sind auf alle Fälle da. Von klassischen Schwachstellen bis zu völlig neuen Angriffen wie Model Poisoning oder Rules File Backdoors. Vielleicht Begriffe, die ihr zum ersten Mal hört, aber die sehr real sind. Und deshalb freue ich mich, dass jetzt Clemens Hübner hier ist. Der ist nämlich Software Cyber Security Lead bei Giesecke und Devrient, einem Unternehmen, das Sicherheit ernst nimmt. Er begleitet Softwareprojekte, berät zu DevSecOps und baut sichere Entwicklungsprozesse auf. Als Trainer und Speaker auf internationalen Konferenzen kennt er die realen Sicherheitsprobleme, die KI-generierter Code mitbringt. Und die wird er uns jetzt auch gleich vorstellen. Seid gespannt. Ich freue mich sehr, dass du hier bist, lieber Clemens.

Clemens Ja, ich freue mich auch. Danke, Hendrik. Danke für die Einladung.

Hendrik Sehr, sehr gerne. Immer wieder gerne. Aber wir haben, wie du vielleicht gemerkt hast, wenig Zeit. Deshalb würde ich sagen, die Bühne gehört dir. Wenn ihr Fragen an Clemens habt, schreibt sie in den Chat und ich gebe sie weiter. Viel Spaß.

Clemens Super, danke dir. Starten wir direkt rein. Ich habe nämlich auch viel mitgebracht, und da schauen wir jetzt direkt mal rein. Ich glaube, zur Motivation brauche ich euch heute gar nicht so viel erzählen. Ihr seid alle hier, weil ihr euch mit Code AI beschäftigt, weil ihr das relevant findet. Ich habe trotzdem mal die letzten Zahlen rausgesucht, die ich gefunden habe, wie weit verbreitet. Code AI schon in den Entwicklungsprozessen in den Unternehmen ist und auch wie viel Geld hinter den entsprechenden Tools, hinter den entsprechenden Lösungen steht. Also eine große Erfolgsgeschichte, könnte man meinen. Wir haben heute auch schon so ein bisschen was von den menschlichen, organisatorischen Herausforderungen gehört in der Keynote und ich muss jetzt weiter ein bisschen den Spielverderber spielen, denn wenn man sich mit dem Thema beschäftigt, dann stolpert man auch immer wieder über Schlagzeilen wie diese hier. Prompt Injection in AI-Agenten, über AI-Development-Tools, die irgendwelche Daten verloren haben, über gelöschte Datenbanken, über AI-Agenten, die Dinge machen, die man nicht möchte, die gehackt werden. Und da möchten wir heute ein bisschen Struktur reinbringen und uns ein bisschen genauer anschauen, was ist denn genau die Angriffsoberfläche, das Sicherheitsrisiko, wenn wir Code AI einsetzen und wie können wir das sicher machen. Was sind passende Gegenmaßnahmen, damit ich das passend und sicher einsetzen kann. Ganz kurz noch zu mir. Ich wurde schon vorgestellt. Clemens Hübner mein Name, Software Cyber Security Lead bei Giesecke und Devrient. Wir sind ein Unternehmen, das sich mit Sicherheit rund um Zahlungsdienstleistungen beschäftigt. Also jeder, der schon mal eine Euro-Banknote in der Hand hatte, eine SIM-Karte, eine Chip-Karte, kennt unsere Produkte, also ein Umfeld, in dem es viel um sichere Entwicklung geht. Und aus der Brille darf ich euch heute eben auch ein bisschen meinen Blick auf, das Thema Software Security mit Code AI erzählen. Kleiner Disclaimer vorweg, ich bin heute hier als Privatperson, das heißt, die Meinungen, die ich habe, die sind meine eigenen. Und dann müssen wir uns auch nicht weiter zurückhalten und starten direkt rein in den Aufstieg von Code AI. Und Emma hat es vorhin schon kurz erwähnt, als Andrej Karpathy den Begriff Vibe-Coding geprägt hat. Da fand gefühlt so, startete so eine neue Epoche in der Softwareentwicklung, zumindest in der AI-gestützten Softwareentwicklung. Vibe Coding wurde zu einem Schlagwort, an dem sich viele auch reiben und der so ein bisschen die letzte Evolutionsstufe vielleicht von verschiedenen Entwicklungen im Bereich Code AI darstellt. Und wenn ich heute von Code AI spreche oder auch mal Coding Assistant sage, dann benutze ich das so ein bisschen synonym, aber es hilft sicher, wenn wir kurz verstehen, dass es da eine gewisse Bandbreite gibt. Und wir haben so Autocompletion-Tools, die gab es auch schon vor LLMs, die kennt jeder, der schon länger entwickelt, wo die IDE da eben entsprechend, ja, auf Basis von einer Zeile oder vielleicht von zwei Zeilen irgendwie die nächste vorgeschlagen hat. Das war so der Anfang. Dann kam mit dem Erfolg von Chat-GPT natürlich auch der Einsatz von solchen Modellen als Frage-Antwort-Helfer, wo wir vielleicht auch fleißig Code rauskopiert haben. Das wurde dann weiter verfeinert, eben mit Tools, die sich speziell mit Code-Generierung beschäftigen, sowas wie Copilot-Chat oder dann eben auch ganzen IDEs, die darauf aufbauen, und jetzt eben dann die agentische Entwicklung. Hin zu Vibe Coding Agents, wo wir also sogar nur noch natürliche Sprache irgendwie reingeben und dann eine ganze App rausbekommen und vielleicht gar nicht mehr so viel. auf den Code schauen müssen, sondern quasi das alles vom Agenten scheinbar weg abstrahiert wird. Also das ist so der Range, in dem wir uns entwickeln und der hilft uns auch, damit ihr später verstehen könnt, welche Schwachstelle ist denn für welche Art von Code AI besonders relevant und ohne dass ich jetzt zu viel Spoiler, desto mehr man ins Autonome geht, desto, mehr muss man natürlich auch darauf achten, dass die Agenten entsprechend sicher agieren. Also, das so zur Einführung, Code AI, Coding Agents, über diese Systeme sprechen wir und vor allem dann eben über das agentische Coden. Und wenn wir dann jetzt über die Security sprechen wollen, dann habe ich uns mal so ein vereinfachtes Schaubild von einem Coding Assistant mitgebracht. Ein Coding Assistant, wirklich sehr, sehr vereinfacht, der hat, gewissen Input, das ist zum einen natürlich der User Prompt, das ist das, an das man als erstes denkt, also das, was ich als EntwicklerInnen eingebe und. Dann gelöst haben möchte, aber natürlich auch der gesamte Kontext, also die Inhalte, die der Coding Assistant sich zusätzlich, dazu holt, sei es jetzt verschiedene Code-Files drumherum, Dokumentation, vielleicht Libraries, vielleicht andere Materialien, die bereitstehen, also all das wird dann in den Kontext gepackt, Und landet dann gemeinsam mit irgendwie einem System-Prompt, mit dem der Coding-Assistent selber irgendwie, ja, programmiert wird oder die Rahmenbedingungen mitbekommt, mit denen er agieren soll. Und all das wird in einen Prompt gepackt und in das LLM geworfen. Und das ist ganz wichtig zu verstehen, dass ein LLM ja nur auf einem großen, natürlich sprachlichen Input letzten Endes agiert. Das heißt, all die verschiedenen Sachen, die Sachen, die wir als Developer reingeben und auch die Sachen, die irgendwie vom Coding Assistant oder aus dem Kontext kommen, landen am Ende gemeinsam im Prompt, den das LLM ausführt, dann vielleicht auch drüber iteriert, das sind dann, die entsprechenden Sachen, die der Coding Assistant eben so macht. Und wo er dann am Ende die Möglichkeit hat, Code-Änderungen natürlich durchzuführen, aber vielleicht auch irgendwie Tests auszuführen, zu schauen, kompiliert noch alles, also. Ja, das sind die Aktivitäten und wenn wir jetzt dann über moderne Agenten sprechen, dann haben die eben auch noch Zugriff auf eine Reihe an Tools und da wird es dann besonders interessant, deswegen schauen wir uns das später im Detail an. Konkret möchte ich jetzt auf fünf Schwachstellen oder Risiken im Zusammenhang mit, Code AI eingehen und wir starten direkt mit dem Bereich hier, nämlich was landet eigentlich alles in dem Prompt und wenn man Prompt schon hört und ein bisschen was mit Security, zu tun hatte, dann denkt man natürlich als erstes an Prompt Injection. Prompt Injection, eine Schwachstellenklasse, die quasi mit LLMs erst neu aufkam, sehr spannend ist für jemanden wie mich, finde ich, und die vom Begriff so ein bisschen an SQL Injection erinnern, wer sich schon früher mal mit Security beschäftigt hat, und es funktioniert recht ähnlich. Das, wie SQL Injection, Input von einem Nutzer oder auch von einem Angreifer, also, nicht vertrauenswürdiger Input, wird so in ein Query, in ein Kommando integriert, das später ausgeführt wird, dass, der Angreifer eben die Möglichkeit hat, aus dem eigentlichen Dateninput auszubrechen und den Query, das Kommando selber zu manipulieren. Das ist die Idee hinter SQL Injection, das ist auch die Idee hinter Prompt Injection. Die typische Prompt Injection, mit der es oft losging, die viele wahrscheinlich kennen, ist so dieses Ignore all previous instructions. Damit versucht man eben, diese Grenze zwischen dem System Prompt, der vielleicht vor dem User Prompt steht, und dem User Prompt aufzubrechen und aus dem User Prompt hinaus den System Prompt zu manipulieren, in dem Fall eben ihn ignorieren zu lassen. Als die ersten Chatbots aufkamen auf irgendwelchen Unternehmensseiten, da gab es also lustige Posts, wo dann jemand eben genau mit so einem Trick geschafft hat, ja, zum Beispiel jetzt hier ein Auto für einen Dollar zu kaufen oder ein Angebot dafür, davon zu bekommen von so einem Chatbot. Das kann aber auch noch entsprechend ausgefeilter werden, aber das Grundprinzip ist immer das gleiche. Inhalt, der in den Prompt kommt, verändert den Prompt als Ganzen so, dass das LLM am Ende Aktionen macht oder. ein Ziel verfolgt, das eigentlich so nicht vorgesehen war. Also zum Beispiel der User-Prompt manipuliert wird oder der System-Prompt manipuliert wird, je nachdem aus welcher Richtung man kommt. Und Prompt Injection ist so das wichtigste Risiko, das es überhaupt gibt im Zusammenhang mit LLMs. Die OWASP hat die Top Ten Risiken im Zusammenhang mit LLMs und da ist Prompt Injection schon von Anfang an auf Platz 1 als eben das wichtigste Risiko, mit dem man sich auf jeden Fall auseinandersetzen muss. Was bedeutet das jetzt im Zusammenhang mit Coding Assistants? Coding Assistants. Wir haben gesehen, alles, was in den Prompt landet, kann irgendwie potenziell für eine Prompt Injection verwendet werden. Das ist zum einen der User-Prompt, okay, das heißt, wir können uns irgendwie als Developer selber hacken, vielleicht nicht so interessant, aber es kann auch alles andere sein, was drumherum liegt. Zum Beispiel auch alles, was im Kontext ist. Da gibt es ein anschauliches Beispiel, das nennt sich dann Rules-File-Backdoors. Rules-Files, das sind so die Dateien, die neben einem Repository liegen oder neben einem Code liegen, mit dem man einem Assistenten irgendwie Anweisungen geben kann, auf was für Regeln soll er grundsätzlich achten. Wir haben irgendwie Coding-Styles, je nach Coding-Assistent heißen die dann. irgendwie unterschiedlich, aber das Prinzip ist immer das gleiche. Wir spezifizieren dann Rahmenbedingungen für einen Agenten und die werden sich dann automatisch mit angezogen, mit dem Kontext geladen und dann mit in den Prompt gepackt. Und gerade zu Beginn waren so Rules Files gerne geteilt im Internet, man hat sich da gerne Sachen zusammen kopiert, um irgendwie. ja, gut funktionierende Instructions für einen Coding Assistant zu bekommen, da wurde eben auch beobachtet, dass es Rules Files gab, in denen mit unsichtbaren Unicode-Zeichen eben zusätzliche Instructions, eingefügt waren, man sieht die jetzt hier dann rechts, die dann dadurch in den Prompt gelangt sind und damit am Ende eine Instruction war, die der Coding Assistant ausgeführt hat. Also, das ist eine Möglichkeit, wie so eine Prompt Injection unseren Coding Assistant beeinflussen kann. Andere Möglichkeit ist die Studie hier. Ich habe die Links immer mit draufgepackt. Ihr kriegt die Slides ja später. Könnt ihr euch nochmal im Detail durchlesen. Da haben es eben Forschende geschafft, zu zeigen, dass man auch über Dependencies, Third-Party-Dependencies, die wir mit in unserem Projekt benutzen, solche Prompt-Injections eben durchführen können, wenn der Coding-Assistent eben bemerkt, ah, hier geht es jetzt eben um diese, in diesem Fall Python-Library, hier hole ich mir eben entsprechend die Datei mit rein, auch dann, um zu verstehen, was ich eigentlich machen muss, dann landet das genauso im Prompt und ist genauso ein Einfallstor für eine Prompt-Injection. Und die Autoren hier haben es sogar geschafft, dass. Die Library quasi vom Inhalt gar nicht verändert war, die hat immer noch weiterhin das getan, was sie eigentlich sollte, war auch auf den ersten Blick gar nicht zu erkennen, deswegen haben sie das eben Stealthy Cross-Origin Context Poisoning genannt, also über den Kontext verwendet. Eben eine Prompt Injection gegen einen AI-Coding-Assistent. Und das muss einem sehr, sehr bewusst sein. Alles, was im Kontext landet, muss eigentlich vertrauenswürdig sein. Und da kann man sich überlegen, wie gut kann man den eigenen Kontext eigentlich kontrollieren. Vor allem, wenn dann auch noch das Thema MCP ins Spiel kommt. MCP-Server sind ja dafür ausgelegt, dass man eben ein gewisses Ökosystem schaffen kann, dass Coding-Assistents oder gegen jede Art eben mit anderen Systemen auf eine standardisierte Art und Weise interagieren können, und das funktioniert in der Praxis so, dass die MCP-Server dann eben advertisen, was bieten sie an, eine Description bereitstellen und diese Description dem Coding-Assistent von Anfang an mitgegeben wird. Das heißt, diese Description ist von Anfang an Teil des Kontexts, egal ob der MCP-Server jetzt benutzt wird oder nicht, das muss einem bewusst sein, sobald man einen MCP-Server integriert, selbst wenn der nicht benutzt wird, hat dieser MCP-Server eben, die Möglichkeit, den eigenen Kontext zu manipulieren und da gab es dann schon so, Rugpull-Attacks, wo eben MCP-Server erst irgendwie sinnvolle Arbeit geleistet haben, später dann aber quasi geflippt sind, das heißt, selbst wenn man das am Anfang einmal kontrolliert, was schickt dieser MCP-Server, dann kann man natürlich nicht sicherstellen, dass das auch in aller Ewigkeit so bleibt. Da gab es jetzt im Frühjahr ein schönes Beispiel bei Context 7, das ist so ein. MCP-Server, der eben Dokumentationen bereitstellt, das heißt, wer da mal ein konkretes Beispiel anschauen möchte, wie sowas funktionieren kann, Dem sei dieser Artikel hier empfohlen. Also, das ist so ein ganz wichtiger Punkt. Prompt Injection bei Coding Assistants ist extrem wichtig und ich glaube, es ist eigentlich, in der Art und Weise, wie wir das aktuell benutzen, unmöglich, den Kontext so zu kontrollieren und so clean zu halten, so trusted zu halten, dass wir sicherstellen können, dass da keine Prompt Injection reinkommt und Prompt Injection ist technisch ungelöst. Also SQL Injection weiß man inzwischen sehr gut, wie das funktioniert. Prompt Injection fehlen bisher zuverlässige deterministische Maßnahmen, um das zu verhindern. Das heißt, wir müssen uns Gedanken machen, eigentlich annehmen, dass wir für Prompt Injection anfällig sind, uns Gedanken machen, okay, wie können wir die Auswirkungen davon, verhindern, aber dazu später mehr. Wir schauen aber auf eine zweite wichtige Risikoklasse im Zusammenhang mit Coding Assistants, und zwar ist das Data Leakage, das heißt Daten von uns oder aus unserem Projekt fließen ab, und das ist auch schon länger ein Thema, gab es bei Devon auch so eine, ja, Agentic IDE quasi, oder Coding Assistant, schon 2024, ein schönes Beispiel, wo eben gezeigt wurde, auf wie viele unterschiedliche Arten man aus so einem Coding Assistant eben Daten exfiltrieren kann, also zum Beispiel, Code, der euch wichtig ist, oder Credentials, die mit dem Repo liegen, obwohl sie da vielleicht nicht sein sollten. Aber natürlich auch, je nachdem, wie der Coding Assistant gesandboxed ist, alles andere, was auf der Festplatte des Developers liegt, also SSH-Keys zum Beispiel. Die Dateien, das heißt, das sind alles Möglichkeiten, auf die ein Coding Assistant potenziell Zugriff hat und wo Devin das hier eben auf verschiedene Arten und Weise dann exfiltrieren konnte, oder, aus Devin exfiltriert werden konnte, dem Curl-Commands abgeschickt wurden, mit dem das abgeschickt wurde, über den Browser, der da integriert war, mit dem halt Sachen aufgerufen werden konnten, also gab es quasi, sehr viele Möglichkeiten. Ein anderes schönes Beispiel, das ich recht anschaulich finde, ist bei GitHub Copilot Chat, also, der Möglichkeit, dass man in GitHub in der Web UI auf Pull Request zum Beispiel, ein LLM hat, mit dem man eben über den Pull Request quasi chatten kann, der läuft dann, mit den Rechten des Nutzers, der eben gerade diesen Chat benutzt und da gab es eben eine schöne Demonstration, dass unsichtbare Kommentare in den Pull-Requests, eines Angreifers dann eben dazu geführt haben, dass der Agent, also das GitHub-Copilot-Chat, dann eben Sachen gemacht hat im Kontext des Nutzers und auf Sachen zugegriffen hat, die von außen zum Beispiel nicht zugreifbar sind, also auf Secrets, auf private Repos. Und wo dann sehr spannend auch diese Daten exfiltriert wurden, das ist ja bei so einem. Chatbot vielleicht nochmal ein bisschen schwieriger, könnte man meinen, war das dann aber quasi in lauter einzelne Bilder kodiert, also jedes Zeichen ist dann ein Bild, wir haben. ein Bild für A, ein Bild für B, ein Bild für C und so weiter und packen die hintereinander, je nachdem welchen String wir exfiltrieren wollen und je nachdem welche Bilder dann von unserem Server geladen werden, dann können wir dann eben gut sehen, wie das Secret, das wir da exfiltrieren wollen, eben genauer ausschaut. Also, sehr spannender Angriff. Lohnt sich auch, das sich mal anzuschauen, wenn einem das interessiert. Das zeigt nämlich auch ganz gut, wie vielfältig die Möglichkeiten sind, mit denen man solche Daten exfiltrieren kann. Gut, kommen wir zu dem Thema Tools. Wir haben vorhin schon gesehen, immer mehr, Tools stehen so einem Coding-Agent zur Verfügung, zum Beispiel über einen MCP-Server, aber natürlich auch, gerade wenn wir jetzt über eine IDE-Integration sprechen, über die Aspekte, die dort direkt zur Verfügung stehen. Also, vielleicht hat unser Agent Zugriff auf das komplette Filesystem, er kann auf jeden Fall sicher das Repo lesen, vielleicht darf er im Web nach Sachen suchen, vielleicht soll er auch in unserem... Repo, ähm, agieren dürfen, ja, vielleicht soll der in Git rein oder in unserem Issue-Tracker schauen können, was, ähm, was verbirgt sich hinter einem Feature, ja, all das sind, sind Tools, die oft an Agenten, äh, angebunden wurden und die zum einen dann eben, ähm, Möglichkeit sind für eine Prompt Injection als Einfallstor, das haben wir vorhin gesehen, aber natürlich auch eine Möglichkeit, wie der Agent, ähm, der Coding Agent, dann eben Schaden anrichten kann und das berühmte Beispiel, das, äh, letztes Jahr, ähm, für viel, ja, vielleicht auch ein bisschen Freude. Gesorgt hat, weil der Artikel sehr, sehr unterhaltsam geschrieben war, ist eben hier das Beispiel von Replit, auch so ein, Webcoding-Anbieter, der eben die gesamte Produktionsdatenbank von einem Nutzer gelöscht hat und dann danach behauptet, er kann sie auch nicht wiederherstellen, obwohl er es gekonnt hätte, großartige Ausreden produziert hat, also wirklich, ja, wenn es nicht so tragisch wäre, ein sehr unterhaltsamer Vorfall, vor allem auch so wie der Autor das da eben berichtet hat und das war nur ein unbeabsichtigter Fehler. Das heißt, da hat der Agent einfach irgendwie Sachen verwechselt, man kann das natürlich nicht so ganz nachvollziehen, was da genau schief lief, aber man kriegt ein Gefühl dafür, was passieren kann, wenn ein Angreifer das wirklich darauf anlegt und da so einen Coding Agent bewusst manipulieren möchte. Solche Sachen kommen immer wieder um die Ecke, solche Erfahrungsberichte. Jetzt erst von diesem Jahr auch wieder, wo ein anderer Nutzer berichtet hat, jetzt den Claude-Code, das ist jetzt nicht auf einen bestimmten Agent beschränkt, ähnlicher Vorfall, ja, wo eigentlich die Idee war, er möchte irgendwie Kosten optimieren, hat da einen Agenten drauf losgeschickt und das Resultat war, dass die Datenbank dann weg war und dass er dann am Ende sogar mehr für seine Infrastruktur bezahlt hat. Also das ist auch ein schönes Beispiel dafür, was quasi ein Agent mit zu viel Toolzugriff alles für Schaden anrichten kann. Und dann sehen wir eben Sachen, wo das absichtlich passiert, also wo das kein Versehen ist, zum Beispiel bei Agent Skills, die ja auch fleißig im Internet geteilt werden, wo es eben Studien gibt, oder Versuche gibt, dass eben sehr viele von diesen Skills, die ja auch dann am Ende Teil von unserem Prompt werden, eben dafür genutzt wurden, um die Agenten zu übernehmen und dann auch dort wieder zum Beispiel Secrets auszuleiten, durch entsprechende Tools, also auch das ein Beispiel dafür, was durch zu viel. Ja, agentische Autonomie passieren kann. Also das muss einem an dieser Stelle eben bewusst sein. Alle Möglichkeiten, die ein Agent hat, kann dann eben zum Beispiel durch eine ausgenutzte Prompt Injection-Schwachstelle auch ein Angreifer nutzen. Also, hier mal so ein Beispiel, wie so ein malicious Agent-Skill ausschaut und auch ein Beispiel dafür, dass man sowas auch immer gut überprüfen muss und sich überlegen muss, ist das wirklich das, was der Agent machen soll. Gut. Das waren jetzt so die verschiedenen Bereiche rund um den Agenten selber. Jetzt müssen wir uns natürlich noch mit dem Output von dem Coding Assistant beschäftigen. Wie ist eigentlich die Code-Qualität und insbesondere die Security von generiertem Code? Und da ist zuerst mal zu verstehen, wir haben das ja auch in der Keynote heute schon gelernt, dass der Durchsatz und die schiere Menge an Code massiv steigt. Gibt's auch schöne Untersuchungen, jetzt hier eben auf einem Datenset mit, ja, fast einer halben Milliarde, glaube ich, von Line Changes aus verschiedenen großen Repositories, nicht nur Open Source, sondern auch eben Google, Microsoft, Meta, interne Repos, die da untersucht haben, wie verändert Copilot, Usage oder Agentic AI im Coding eben die, Art und Weise, wie entwickelt wird und das Spannendste, was man eben sehen kann, ist, dass der Code-Churn eben massiv ansteigt in den letzten Jahren, also. Die Menge an Code, der quasi immer wieder angefasst wird und das, was ich auch selber bei der Benutzung von Coding Assistants, merke, sie tendieren dazu, viel zu verändern, viel umzustrukturieren, wenn man sie davon nicht abhält, das heißt, immer mehr Code wird irgendwann mal von einem Coding Assistant angefasst Und deswegen ist es interessant zu schauen, ja gut, wie ist denn die Sicherheit von dem Code, der da generiert wird. Da gibt es ganz spannende Studien. Eine sehr umfangreiche war von Veracode aus dem letzten Jahr, wo sie über 100 verschiedene Modelle eben gefragt haben, ja, verschiedene Coding-Tasks gegeben haben und fast die Hälfte von allen Coding-Samples, die da rausgefallen sind, eben Schwachstellen hatten und oft auch einfach sehr simple, oberste Top-Ten-Schwachstellen, also jetzt nicht besonders ausgefeilte, sondern wirklich typische, einfache Schwachstellen, an die ein guter Entwickler, eine gute Entwicklerin eigentlich denken würde, war eben fast die Hälfte aller Coding-Aufgaben da der Fall. Und weil sie hier eben so viele Modelle sich angeschaut haben, war da auch ganz spannend zu sehen, die neueren Modelle sind in der Hinsicht Security gar nicht so viel besser als die Modelle, die schon ein bisschen älter waren. Die Studie ist schon fast ein Jahr alt, das ist in AI-Zeitalter natürlich irgendwie ein Jahrtausend. Aber auch die neueren Studien, die waren jetzt nicht ganz so umfangreich, die man da sieht, die zeigen so eine leichte Verbesserung mit den Modellen, aber die, wenn man die ungepromptete Security nimmt, also ohne, dass man besonders darauf achtet, dann ist die Sicherheit von generiertem Code immer noch relativ schlecht. Wenn man da ein bisschen tiefer reinsteigen möchte, dann finde ich BaxBench schon mal ein ganz tolles Projekt. Das ist ein Benchmarking eben für LLMs, Open Source. Dann kann man sich auf GitHub anschauen, welche Testcases da benutzt wurden, und kann das zum Beispiel auch mal für ein eigenes LLM ausführen. Das ist jetzt auch eine Studie aus dem letzten Jahr, die da aber auch gezeigt hat, ja, bei den, selbst bei dem besten Modell, das sie da eben getestet haben, waren fast zwei Drittel entweder falsch oder haben eine Schwachstelle enthalten. Und insgesamt über alle Modelle, die wir da eben getestet haben, das ist jetzt der aktuelle Stand, den ich mal gezogen habe, es sind eigentlich, im Durchschnitt in der Hälfte aller Antworten noch hier eine Schwachstelle enthalten. Was für Schwachstellen sind das? Ich habe meine Erfahrungen mit Schwachstellen aus Coding Assistants mal in vier Cluster eingeteilt. Zum einen gibt es die Schwachstellen, die irgendwie darauf basieren, dass die Coding Assistants sehr auf den Happy Path fokussiert sind, also auf die Funktionalität, auf das umzusetzen, was von ihnen verlangt wird erstmal, die Beschreibung, die man ihnen gibt, und dass dann gerne eben begleitende Sicherheitsmaßnahmen vergessen werden, also eine Autorisierung, also eine Rechtevergabe, ein Rate Limiting oder auch schon irgendwie einfach nur ein Error Handling, dass das irgendwie Sachen sind, die fehlen. Dann gibt es natürlich den Aspekt, dass, ja, die auch nur auf unsicherem Code trainiert wurden, das heißt, manche Sachen sind auch einfach gelernt, das ist das, was man früher als Stack-Overflow-Effekt bezeichnet hat. Wo eben in den Trainingsdaten schon irgendwie unsichere Sachen waren oder irgendwelche alten Patterns, alten Cypher, zum Beispiel gerade bei Krypto irgendwie benutzt waren, die man heute eigentlich nicht mehr benutzen möchte. Dann natürlich das Thema Architectural Blindness. Ich glaube, das ist der Bereich, der sich am meisten verbessert, weil die Modelle immer besseres Verständnis, einen größeren Kontext, ein besseres Verständnis für ein gesamtes Projekt bekommen, aber halt trotzdem vielleicht immer noch nicht, die gesamte Domäne überblicken, alles komplett verstehen, verstehen, was hat man eigentlich für ein Trust-Model, gerade wenn man irgendwie nur ein Sub-Projekt hat und das Modell nicht weiß, was sind denn die entsprechenden anderen Komponenten, mit denen wir arbeiten. Das ist all das, was in die Klasse fällt. Und dann natürlich, wir arbeiten hier immer noch mit LLMs. LLMs halluzinieren fröhlich. Das heißt, wir sehen Schwachstellen, die darauf basieren, dass APIs falsch aufgerufen werden, dass zum Beispiel irgendwelche Security-Flags vergessen werden bei einer API oder auch das berühmte Thema Slop-Squatting. Man kennt vielleicht den Begriff Typosquatting, wo also. Pakete registriert werden, Third-Party-Pakete registriert werden, die so einen ähnlichen Namen haben wie valide Pakete und Angreifer dann eben sich zunutze machen, dass sich Developer vielleicht mal vertippen und Slopsquatting ist quasi das Gleiche, nur mit halluzinierten Paketen. LLMs halluzinieren irgendwelche Libraries, irgendwelche. NPM-Packages zum Beispiel, die es eigentlich gar nicht gibt und ein cleverer Angreifer hat diese Halluzination vorhergesehen oder vielleicht selber schon mal gesehen oder hat einfach auf Verdacht sehr viele von diesen Paketen genauso schon registriert, die dann aber entsprechend bösartig sind und sobald das LLM das eben halluziniert, laden wir uns das Package runter, führen das vielleicht mit aus oder es landet in unserem Produkt. Das ist also das, was man unter Slopsquatting versteht, warum man immer quasi auch die Abhängigkeiten, die ein Modell benutzen möchte, nochmal genauer überprüfen sollte. Sind das wirklich die Richtigen, sind das die Abhängigkeiten, die ich da benutzen möchte? Da gab es jetzt gerade, ja, ist schon länger ein Thema. Wer da nochmal genauer reinschauen möchte, da habe ich hier noch einen Artikel, verlinkt, wo eben analysiert wurde, was da alles zusammenhalluziniert wurde. Also wir sehen, es gibt so eine Reihe von verschiedenen Schwachstellen, die für AI-generated-code typisch sind und wir sehen auch, dass die Studien, die wir bisher haben, zeigen, ja, es gibt eine gewisse Diskrepanz oder eine gewisse Problematik mit der Qualität von so generiertem Code. Und das fasst eine Studie, die jetzt auch schon ein paar Jahre älter ist, aber deren psychologischer Effekt ein sehr, sehr spannendes, eine psychologische Erkenntnis, war auch eine Studie, wo. Teilnehmende quasi mit Coding Assistants, eine Kontrollgruppe eben ohne Coding Assistants, Code entwickeln sollten, und wo die Autoren von Stanford eben herausgefunden haben, nicht nur haben die mit Coding Assistants irgendwie mehr Schwachstellen in ihrem Code eingebaut, sie hatten auch danach ein besseres Gefühl über die Qualität, über die Sicherheit von ihrem Code. Also, mehr Schwachstellen gleichzeitig aber, ja, ein besseres Gefühl, das ist das, was ich eben als The Trust Trap bezeichne, also eine falsche Wahrnehmung, ein falsches Gefühl, wie gut und wie sicher der Code ist, der mit Coding Assistants entsteht. Wie gesagt, die Studie ist jetzt schon ein paar Jährchen alt, aber auch der aktuelle BSIMM-Report, das ist ein Report über den Reifegrad von Softwareentwicklung. Der jetzt veröffentlicht wird, der zeigt eben auch, dass, es diese Illusion of Correctness, nennen sie es jetzt hier eben, existiert, dass eben Code, der von einem Coding Assistant generiert wird, grundsätzlich irgendwie als besser, als sicherer wahrgenommen wird bei vielen Entwicklern und das eben, Zusammen mit dem Phänomen, dass es eben kein perfekter Code ist, eben ein echtes Problem darstellt und da versuche ich immer, mehr Bewusstsein für zu schaffen und hoffe, dass ihr das heute so ein bisschen mitnehmen könnt, was da noch, die Einschränkungen sind und dass es wichtig ist, darüber zu sprechen und sich damit zu beschäftigen. Soviel also zum Thema Code Quality. Dann kommen wir zum Abschluss noch zu einem letzten Thema, Model Poisoning. Das hatte ich hier unten, genau. Das Thema Trainingsdaten hatte ich vorhin so ein bisschen ausgeklammert, weil das ja etwas ist, mit dem sich die wenigsten hier aktiv beschäftigen. Die wenigsten trainieren noch eigene LLMs, aber man muss sich natürlich immer vergegenwärtigen, dass es diese Trainingsdaten gibt und dass wir die genauso wenig kontrollieren können für die meisten LLMs, wie das Training selber oder wie das LLM sich eben verhält. Und das ist eben ein ganz wichtiger Punkt, den man ganz gut an dieser Studie sehen kann, wo eben das chinesische Modell DeepSeek untersucht wurde und dem Modell eben gleichlautende Coding-Tasks gegeben wurden, also zum Beispiel eine To-Do-Liste oder eine Verwaltungs-App für eine Firma, die aber einmal eben komplett ohne einen, politischen Kontext und einmal eben mit einem gewissen politischen Kontext, der in China als kontrovers eingeschätzt wird. Zum Beispiel baue eine To-Do-Listen-App für ein tibetanisches Kloster zum Beispiel, war da, glaube ich, ein Beispiel, wo dann verglichen wurde, wie ist die Qualität von diesem Code, den dieses chinesische Modell da eben generiert, und es hat sich gezeigt, obwohl quasi der Task, der technische Task der gleiche ist, waren die Produkte oder der Code, der eben mit so politischen Triggern versehen war, eben signifikant unsicherer, hat mehr Sicherheitsschwachstellen, Security-Bugs enthalten, als die, die eben ohne sowas geprompted wurden. Und das zeigt ganz gut, was da die Gefahren sind. Zum einen natürlich aus dem geopolitischen Aspekt, aber auch, weil das ganz gut demonstriert, wie wenig wir einfach wissen, auf was wurde da genau trainiert, wie wurde das trainiert, ist das hier absichtlich entstanden, ist das ein blöder Seiteneffekt, weil man irgendwie da einen falschen Bias in den Trainingssachen hat. Man weiß es einfach nicht. Aber das muss einem einfach bewusst sein, wenn man über solche Themen spricht. Wir benutzen LLMs gerne, sie sind super wertvoll, aber wir verstehen nicht so ganz, was unter der Haube passiert, auch worauf sie trainiert wurden, was für Rahmenbedingungen sie vielleicht mitbringen. Das wäre also mein Überblick zu den fünf wichtigsten Risiken, die ich euch heute mitgeben möchte im Zusammenhang mit Coding Assistants. Jetzt wollen wir die letzten Minuten noch nutzen und ein bisschen über Gegenmaßnahmen sprechen. Denn ich möchte hier Coding Assistants nicht verteufeln. Sie haben großen Wert. Ich benutze sie auch super gerne selber, aber man muss sie halt passend und verantwortungsbewusst einsetzen. Also schauen wir mal auf die Gegenmaßnahmen zu den fünf Schwachstellen, die wir jetzt gesehen haben. Wir haben gesehen, Prompt Injection betrifft alles, was irgendwie über den Kontext vor allem in unserem Prompt landet. Wir haben gesehen, wie dann daraus basierend Daten irgendwie abfließen können, zum einen natürlich durch Command-Executions, aber auch durch Tools, das passt zu beiden, dann eben wie die Tools insgesamt missbraucht werden können durch Agenten, was die Code-Qualität betrifft, und eben das Thema, wie die Trainingsdaten ausschauen, also ob die potenziell vergiftet wurden, Model-Poisoning, ich glaube, den Begriff hatte ich vorhin gar nicht so explizit genannt, so nennt man das, Und die Gegenmaßnahmen zu diesen Sachen lassen sich in ein paar Bereiche einteilen. Zum einen gibt es Sachen, da gibt es schon sehr typische und sehr. bewährte Methoden und das betrifft alles, was den Bereich Code Quality eben betrifft. Da haben wir schon gute Maßnahmen, wie wir die Qualität von, jemandem, von Code überprüfen, der von jemandem geschrieben wurde, der wir nicht selber sind und diese Aktivitäten müssen wir einfach weiter genauso durchführen, auch wenn wir jetzt eben Code von Coding Assistants bekommen, das heißt, gerade jetzt in Bezug auf Security heißt das, die Security-Aktivitäten, die wir eigentlich schon lange in unseren Entwicklungsprozessen haben müssen, Sei es jetzt schon beim Entwurf, durch Threat Modeling zum Beispiel, aber dann eben auch, beim Review natürlich und beim Testen von Code. Das ist für alles, was von Coding Assistants kommt, eben. Besonders relevant und eben dieser Trust Trap aktiv begegnen, ein bisschen Sachen hinterfragen, Sachen überprüfen und das Ganze eben verantwortungsbewusst nutzen. Bei den anderen Sachen ist es so ein bisschen schwieriger. Prompt Injection, habe ich vorhin schon gesagt, ist aktuell noch ein ungelöstes Problem. Es gibt Tools und Methoden, um eben solche einfachen Prompt Injections irgendwie zu finden. Alle großen LLMs haben sowas, bieten sowas an, um eben so diese typischen Ignore All Previous Instructions zu verhindern. Aber das ist nicht 100% möglich und das wird vermutlich auch so schnell nicht sein, eben durch die nicht-deterministische Art und Weise von LLMs. Das heißt, wir müssen eigentlich hier annehmen, dass ein Angreifer mit genug, Motivation und mit genug Aufwand eben so eine Prompt Injection durchführen kann. Das heißt, wir müssen uns darum kümmern, wie können wir die Auswirkungen verhindern. Das heißt, da sind wir dann jetzt hier bei den Limitations, das heißt, das macht Sinn, die Autonomie von Coding Agents, gezielt zu beschränken, um eben so eine Prompt Injection dann eben einzudämmen, das heißt, das macht Sinn zu überlegen, welche Tools braucht mein Agent genau, darf er da einfach drauf zugreifen, muss er da nochmal nachfragen, das ist so dieser berühmte Human-in-the-Loop, Und darauf wird sich oft irgendwie zurückgezogen, wenn man sagt, okay, wir können das hier nicht weiter kontrollieren, dann machen wir hier noch so ein Human-in-the-Loop-Button, aber jeder, der schon mal irgendwie 50 Mal in Folge auf ein, Ja-Okay-Mach-Weiter-Button geklickt hat, der kann sich vorstellen. Wie gut das in der Praxis wirklich funktioniert. Also, ich bin da mal so ein bisschen vorsichtig. Schöner sind da technische Lösungen, dass man Sachen wirklich konkret einschränkt, sinnvolle Rechte vergibt und eben auch das Thema Sandboxing sich genauer anschaut. Also, einen Coding Assistant ohne eine passende Sandbox zu betreiben, ist eine gefährliche Sache. Das kann ich auf keinen Fall empfehlen. Und das gleiche gilt dann natürlich auch für Data Leakage, also sich zu überlegen, wo können überall Daten hinfließen, auch dort die passenden Einschränkungen, die passenden Rechte zu vergeben, das ist da eben die Gegenmaßnahme. Und beim Model Poisoning, ich springe hier wild ein bisschen hin und her, ich hoffe, ihr könnt mir folgen, bei Model Poisoning ist eben der Punkt, ja, wir können es nicht komplett kontrollieren, außer wir nehmen wirklich ein Modell, wo auch die Trainingsdaten offengelegt sind, was sehr selten ist, das heißt, wir können das auch nur wieder durch Reviews versuchen, zu erkennen, zu überprüfen, aber wir werden das nie komplett verhindern können. Auf einer Folie zusammengefasst, habe ich hier nochmal meine Tipps für eine sichere Nutzung von Coding Assistants, hier darüber sprechen, sich dazu weiterzubilden, das macht ihr gerade eh, das ist eh gerade im Gange, und dann ist quasi wichtig, dass man in jedem Schritt vom Entwicklungsprozess das passend und verantwortungsbewusst einsetzt, also dass man sich vorab genau Gedanken macht, okay, was ist das Feature, das ich hier machen möchte, was hat das für eine Bedrohungslage, was hat das für eine Angriffsoberfläche, kann ich das später dem Modell dann eben auch entsprechend mitgeben, oder prompten, das zeigt die Erfahrung, dass so ein Security Reminder eben hilft, desto besser, dass der Agent eben versteht, was meine Rahmenbedingungen sind, worauf er achten soll, desto, eher kann er das verhindern, Und dann natürlich das Thema Review, also alles, was irgendwie von dem Agenten, generiert wurde, muss von dem Menschen meiner Meinung nach reviewt werden und natürlich auch durch passende Security-Tests begleitet werden und schauen, dass da keine neuen Schwachstellen eingeführt wurden. Das sind also meine Empfehlungen für euch. Ich habe hier noch zwei Links mit draufgepackt, wer sich nochmal weiter einlesen möchte. Das eine ist die OpenSSF Guidance. Da kann man nochmal genauer nachlesen, was es für Empfehlungen gibt für AI Coding Assistants und dann von der OWASP das GenAI Security Project. Steckt auch eine große Sammlung an verschiedenen Ressourcen, Tools, Templates, Whitepapern. Das kann ich euch mitgeben, wenn ihr sagt, da möchte ich noch mehr zu lernen. Und so hoffe ich, dass ihr heute mitnehmen konntet, was eben die, ja, Möglichkeiten sind von Code AI und dass es wichtig ist, da gewisse Sachen aktiv zu beschränken, um eben Risiken zu minimieren. Alles, was nur durch Prompting passiert, ist eben für eine Prompt Injection auch anfällig, das heißt, wir müssen Sicherheit um das LLM drumherum bauen, uns darauf konzentrieren, was darf alles rein, was darf alles raus, was darf der Coding Assistant alles machen. Das sind also die Sachen, die ihr hoffentlich heute mitnehmen könnt. Und damit würde ich jetzt auch zum Abschluss kommen, denn ich bin mir sicher, es gibt noch ein paar Fragen und denen wollen wir genug Zeit einräumen und deswegen sage ich erstmal herzlichen Dank und freue mich auf eure Fragen.

Hendrik Ja, lieber Clemens, erstmal sage ich herzlichen Dank dir für diesen Vortrag. Wir haben tatsächlich auch eine Frage im Chat, und zwar der Cass, der sagt, in meinem Dev-Team nutzen wir IntelliJ-AI. Die größte Besorgnis im Team, unser Code, ups, da springt es, könnte in falsche Hände geraten. Deshalb nutzen wir den Coding-Agent nur mit der Option Codebase off. Er fragt jetzt, wir geben stattdessen die benötigten Files explizit mit. Ist das jetzt schlau oder doch eher das Gegenteil von schlau?

Clemens Also das betrifft ja quasi so das Risiko, wir machen uns irgendwie Sorgen, dass unser Intellectual Property, also unser eigener Code irgendwie abfließt. Ich glaube, dafür ist die beste oder die typische Antwort heute, dass man das halt vertraglich regelt, dass man quasi nur ein LLM benutzt, wo einem der Anbieter zusichert, dass er die Daten, die er da bekommt, nicht zum Training oder sonst was verwendet. Dann kann man da drauf vertrauen oder es auch nicht machen. Aber am Ende ist die Erfahrung ja, desto mehr Kontext ein LLM hat, ein Coding Assistant hat, desto besser sind die Ergebnisse, das heißt, ich bin mir nicht sicher, ob es so praktikabel ist, was er jetzt da beschreibt, dass man dann nur wirklich einzelne Sachen mitgibt. Wenn man wirklich so sensiblen Code hat, dass man das auf keinen Fall irgendwie rausgeben möchte, dann möchte man ja wahrscheinlich auch nicht einzelne Dateien rausgeben, dann hat man da ja auch weiterhin irgendwie ein schlechtes Gefühl. Dann lohnt es sich vielleicht wirklich zu überlegen, möchte man da irgendwie eigene Modelle hosten, was aber wieder ganz andere Herausforderungen mit sich bringt. Also ich glaube, dafür gibt es gerade keine bessere Lösung, als auf Verträge zu vertrauen.

Hendrik Alles klar, okay. Wir haben noch eine Frage von dem Nils Klüver, der auch nachher hier einen Vortrag halten wird. Er möchte wissen, hast du Erfahrungen mit der Model Armor von Google gemacht?

Clemens Nee, die kenne ich nicht. Das würde mich interessieren, wenn du da später etwas zu sagen willst, sonst schaue ich es mir selber an. Ich glaube, der Vortrag geht in eine etwas andere Richtung.

Hendrik Ja, das habe ich befürchtet.

Clemens Nee, das kenne ich selber noch nicht. Ich nehme mal an, das ist auch eine Art und Weise, wie man versucht, Prompt Injection zu verhindern. Wie gut das da funktioniert, kann ich nicht einschätzen. Meinem Gefühl nach gibt es da immer noch keine hundertprozentige Trefferquote, um sowas wirklich zu verhindern. Dafür gibt es einfach in natürlicher Sprache zu viele Möglichkeiten, Sachen irgendwie zu verstecken und zu verschleiern. Und alle Ansätze, ja, dann muss man halt mit einem zweiten LLM das erste LLM kontrollieren und dann findet man da wieder einen Weg drumherum. Ist alles bisher noch nicht vom Erfolg gekrönt. Das ist, glaube ich, so ein grundsätzliches, konzeptionelles Problem mit LLMs. Aber ich schaue es mir mal an. Danke für den Tipp.

Hendrik Ja, cool. Und Ingo hat noch eine Frage. Ich lese das mal kurz vor. Er sagt, auffällig ist in der Taxonomie, irgendwie scheinen so ziemlich alle Punkte ein entsprechendes menschliches Pendant zu haben. Liegt das eher an der Arbeitsweise von LLMs, die trainiert sind auf einem menschlichen Textkorpus, oder ist das vielleicht auch ein Blindspot in der Taxonomie, dass nicht menschliche Fehlertypen nicht ausreichend beachtet werden. Da fehlt einem vielleicht auch die Fantasie, was diese Fehlertypen überhaupt sein könnten. Das ist mal eine spannende Frage.

Clemens Das stimmt, das stimmt. Also ich bin ja grundsätzlich der Meinung, dass es eigentlich nur menschliche Fehlertypen gibt, weil, also man kann sich nie darauf zurückziehen, dass irgendwie ein System, das da alleine schuld ist, weil dann betreibt man das System falsch und das ist am Ende wieder ein menschlicher Fehler. Das heißt, die Grenze ist da eh schon so ein bisschen schwammig. Wo haben wir denn die Folie? Aber also die grundsätzliche Beobachtung gilt natürlich, genau, die meisten Sachen davon lassen sich irgendwie darauf zurückführen, dass entweder schon mal früher jemand diese Fehler gemacht hat oder, man vielleicht falsch gepromptet hat oder das hätte besser erklären müssen und so. Also, die Beobachtung stimmt auf jeden Fall. Hier hinten wird es dann so ein bisschen schwieriger, aber dann kann man natürlich immer noch sagen, ja gut, da fehlt dann halt die gewisse Sorgfalt und dann auch wieder ein menschlicher Fehler. Es wirft aber einen interessanten Punkt auf, quasi auch zu dem Aspekt, der aus den Studien kommt, wie sicher ist dein Code? Weil ich natürlich jetzt gezeigt habe, ja, irgendwie 50 Prozent der Sachen, die Studien sind irgendwie unsicher. Das ist natürlich die Frage, womit vergleicht man das eigentlich genau? Also, wie gut ist denn ein durchschnittlicher Entwickler? Ist das besser oder ist das schlechter als das? Also, wenn es darum geht, das jetzt irgendwie auf menschlichen Fehler zurückzuführen oder mit menschlichen Fehlern zu vergleichen, dann wird es, glaube ich, eh schwierig, weil ich bisher auch keine Studie gefunden habe, die leider die gleichen Coding-Tasks auch an, Menschen gegeben hat und das damit verglichen hat. Da kann jetzt jeder mal sich selber überlegen, wie er sich oder seine, Kolleginnen so einschätzt, ob die da besser oder schlechter sind.

Hendrik Alles klar. Und eine letzte Frage noch von Christian. Was für Modelle setzt ihr ein? Hosted in EU? Also Quatsch, warum lese ich das auf Englisch vor? Also gehostet in der EU, in den USA oder lokale LLMs? Willst du da auspacken?

Clemens Ja, ich kann da schon einen Einblick geben. Also genau, selbst gehostete Modelle benutzen wir nicht, aus den Gründen, die ich da vorhin schon mal genannt habe, halten das aktuell nicht für praktikabel. Soweit ich weiß, sind unsere Modelle alle EU-hosted. Ich glaube, dass es aber letzten Endes auch ähnliche, rechtliche ... ich möchte jetzt nicht Augenwischerei sagen, aber man darf das auch mit einer gewissen Skepsis betrachten, ob das jetzt wirklich den Unterschied macht, ob ein amerikanischer Konzern das hier hostet oder drüben hostet. Ich glaube, im Fall eines Falles ist da der Zugriff immer da. Das heißt, auch wir verlassen uns bei den meisten Sachen eben auf rechtliche Zusicherungen und haben natürlich gewisse Sachen, die so sensibel sind, dass sie nie das, Auge einer externen AI sehen, wo also dann noch wirklich, ohne AI gecodet wird.

Hendrik Okay, super. Dann vielen Dank nochmal dir hier für deinen Vortrag und jetzt auch, dass du nochmal hier die letzten Fragen auch noch beantwortet hast. Und ja, bis zum nächsten Mal, würde ich sagen, Clemens. Ja, sehr gerne.

Clemens Ja, sehr gerne. Viel Spaß noch. Bis zum nächsten Mal.