Lieber der KI blind vertrauen oder Strukturen implementieren, die für Sicherheit sorgen?
"Lass uns das doch einfach schnell von der KI schreiben lassen", sagte der Teamleiter, "Das muss heute noch raus".
Na ja, und dann wurde eben ein LLM-Agent auf das Problem losgelassen.
Die Buttons waren an der richtigen Stelle, die Daten kamen im Backend an und das LLM fragte auch noch freundlich nach neuem Input: Erledigt! Gibt es noch etwas Weiteres, wobei ich dir behilflich sein kann? 🚀
Auch Wochen darauf ist alles ruhig. Niemand bemerkt die SQL-Injection, die in dem neuen Suchfeld hinzugekommen ist, wie auch bei den 10.000 Zeilen Code, die nun pro Entwickler:in pro Stunde erzeugt werden können (ich spreche aus eigener Erfahrung).
Aber wie es kommen musste, bleibt diese Schwachstelle nicht unentdeckt. Ein LLM-Agent eines Angreifers findet die Schwachstelle und hat sich schon weiter im System ausgebreitet und wird auch viele weitere Wochen bis sogar Monate nicht auffallen. Der Schaden wird enorm sein.
Diese Geschichte sehen wir in der Cybersicherheitswelt täglich. Die Kompetenz von LLMs wird immer wieder überschätzt. Gefährliche Nebeneffekte im Code sind das Resultat. Doch natürlich wissen wir, dass wir KI verwenden müssen, um unseren Aufgaben in der Entwicklungswelt hinterherzukommen. Um Kunden die Features zu liefern, die gewünscht werden.
Das Wichtige dabei ist, wie wir die Sicherheit unserer Anwendungen und Infrastruktur aufrechterhalten können, ohne Fortschritt zu verlangsamen.
Die Antwort auf diese Frage ist genauso klar wie die Ursache des Problems: Skalierung durch Automatisierung. Wo Entwicklerinnen, Tester und die Sicherheitsprüfungen nicht mehr hinterherkommen, werden Automatismen benötigt, die diese Fleißarbeit abnehmen können. Dabei möchte ich in diesem Beitrag den Fokus auf drei verschiedene Methoden richten:
Mit diesen drei Methoden kann man schon relativ viel Gefahr abwenden, und das Ganze mit relativ wenig Aufbauaufwand und sehr wenig Wartung.
Eine nicht neue, aber eine umso wichtigere Methode, um die Codesicherheit zu erhöhen, sind automatisierte Scans. Ich beziehe mich hier spezifisch auf klassische, nicht LLM-/KI-gestützte Scanner, welche anhand von vordefinierten Strukturen und Signaturen arbeiten. Diese laufen in der Regel in den Pipelines der Coderepositories, nachdem diese von den Entwicklungsgeräten in die jeweiligen Plattformen befördert wurden.
Mit diesen werden verschiedene Aspekte der Codesicherheit abgehandelt, von Prüfungen nach Secrets, gefährlichen Code-Strukturen oder sogar automatischen Scans über die deployte Anwendung. Falls du mehr zu diesen Scannern erfahren möchtest, kommt bald ein Artikel spezifisch zu diesen.
Der besonders interessante Punkt an diesen klassischen Scannern ist, dass sie ausnahmslos jede Zeile Code durcharbeiten. Gerade bei KI-generiertem Code ist das wichtig, da hier immer die Chance besteht, dass Fehler übersehen werden durch das Volumen der Zeilen und den Fakt, dass LLMs, wie jede KI basierend auf neuronalen Netzen, immer nur eine gewisse Wahrscheinlichkeit haben, richtig zu liegen.
Die Schwäche bei klassischen automatischen Scannern ist jedoch, dass sie Fehler, welche nicht vordefiniert sind, nicht finden. Pattern, die gerade so an der Konfiguration des Scanners vorbeigehen, werden so nicht erkannt.
Als Standardscanner würde ich so gut wie immer einen Static-Application-Security-Testing-(SAST)-Scanner einbauen. Diese prüfen, ob sich in dem Code Zeilen oder Abläufe befinden, welche gefährlich sind. Dabei gibt es verschieden komplexe Scanner. Also z. B. SAST-Scanner, die einfach nur einzelne Funktionen testen oder gefährliche Aufrufe erkennen wie unzureichende kryptographische Funktionen, bis hin zu SAST-Scannern, die den Datenfluss von Front- bis Backend verfolgen und anhand dessen bewerten, ob eine Schwachstelle vorliegt.
Als weiteren Scanner empfiehlt sich ein Secret-Scanner. Diese Scanner halten Ausschau nach Zeichenketten, welche aussehen wie Passwörter, API-Keys etc. Zu diesen ist tatsächlich nicht mehr zu sagen. Sie erfüllen eine recht einfache, aber sehr wichtige Aufgabe in jedem Software-Development-Lifecycle-(SDLC). Diese laufen regulär auch in der Pipeline, aber sind auch als sinnvolle Fallstricke in einem Git-Workflow. Man kann diese beispielsweise vor einem Commit oder Push laufen lassen um diesen zu blockieren, gerade falls die Commits/Pushes von den Agenten direkt gemacht werden.
Ein weiterer häufiger Fehler von LLM-Agenten ist das Einbinden von nicht direkt gewollten oder veralteten Softwarepaketen. Bei so gut wie jedem Projekt, das ich per LLM-Agenten entwickelt habe, werden so gut wie immer Abhängigkeiten verwendet in veralteten, oft unsichereren, Versionen. Aus diesem Grund erachte ich es auch als sehr sinnvoll, einen Dependency-Scanner mit in das Projekt einzubauen. Diese prüfen, wie der Name schon sagt, die Abhängigkeiten von verschiedenen Paketverwaltungstools auf bekannte Schwachstellen anhand der Versionsnummer.
Während diese Scanner deterministisch sind, liefern sie trotzdem ab und zu False Positives. Denn sie können nicht den gesamten Kontext eines Fundes von selbst verstehen, so weiß der SAST-Scan nicht, ob eine SHA1-Implementierung hier für Passwörter verwendet wurde oder einfach nur zum schnelleren Vergleichen von Daten.
Kommen wir nun von der SecOps-Verantwortung zu der Verantwortung, die die einzelnen Entwickler:innen tragen. Denn schon beim Schreiben des Codes selbst können den KI-Agenten strengere Regeln vorgegeben werden.
Zuerst aber ein Disclaimer. Ich rede in diesem Abschnitt so gut wie immer nur von Regeln, aber in verschiedenen KI-Tools wird auch von z. B. Skills, Subagenten oder anderen abgrenzenden Definitionen gesprochen. Dies sind aber im Grunde immer nur textbasierte Beschreibungen, die ein LLM bekommt, um genauer zu definieren, was es macht. Ein Skill ist einfach eine (hoffentlich) detaillierte Beschreibung, wie ein Agent was und womit tun soll. Er gibt mehr Kontext zu dieser Aufgabe als der Prompt selbst. Das Gleiche ist auch ein vordefinierter Subagent, nur dass dieser mit dieser Beschreibung und einer Instruktion frisch gestartet wird. In manchen Tools wird auch von Regeln gesprochen, die immer oder durch bestimmte Trigger greifen. Diese Regeln sind aber wiederum auch einfach nur textbasierte Beschreibungen, welche dem LLM mitgegeben werden, um genauer zu definieren, wie es sich verhalten soll.
Wir merken uns also: Regeln, Skills, Subagenten ➔ Textbasierte Instruktionen wie die KI handeln soll.
Während wir uns in diesem Artikel nur mit der SDLC-Seite des Themas beschäftigen werden, kann diese Methodik aber auch auf andere Seiten der KI-Agentennutzung verbreitet werden. Diese vorgeschlagenen Regeln sind etwas abgewandelt auch z. B. für jegliche Personen im DevOps-, Administrations- oder Tooling-Bereich sinnvoll.
Für mich ist es noch wichtig anzumerken, dass die Regeln, die hier KI-Agenten gegeben werden, zwar die Chance auf Fehler reduzieren, aber diese nicht ausschließen. Gerade an den kritischen Teilen einer Software sollte ein Mensch sich Gewissheit schaffen, dass die Abläufe auch so sind, wie sie erwartbar sind.
Die erste Regel, die ich grundsätzlich definiere, ist no-secrets-rule.
Diese Regel ist so definiert, dass sie bei jeder Interaktion mit persistenten Dateien aktiv ist.
In der Regel steht explizit, dass niemals Secrets wie API-Keys, Passwörter, beliebige Tokens oder private Adressen in irgendeine Datei geschrieben werden sollen.
Mit dieser Regel prüft das LLM bei jeder Dateiinteraktion, ob diese auch wirklich frei von Secrets ist und so kein gefährliches Datenleak entstehen kann.
Falls ein Verweis gemacht werden soll, mit z. B. einer Beispielkonfiguration, ist der KI-Agent instruiert, hier nur den Namen einzutragen, beispielsweise so als APP_API_KEY.
In der Realität sollte es eigentlich nie dazu kommen, dass ein LLM-Agent mit Secrets arbeitet. Dennoch passiert dies zu oft. Man darf nicht vergessen, dass jede Information, die das LLM hat, in der Regel über das Internet an einen Provider gesendet wird. Es ist äquivalent dazu, das Secret in einem Messenger zu versenden. Falls ihr so mit euren Secrets umgeht, hoffe ich, dass ihr viel Vertrauen in die Datenschutzrichtlinien des Providers habt.
Eine weitere Regel, die ich verwende, ist die no-negligent-errors, also keine fahrlässigen Fehler.
In dieser Regel definiere ich, welche grob fahrlässigen Fehler es beim Programmieren gibt, also Themen wie nicht bereinigte Userinputs, veraltete Kryptographie oder unsichere Defaults.
Hier kann man sich gut an z. B. den OWASP Top 10 orientieren.
Wichtig ist es bei dieser Regel, recht konkret zu werden und nicht einfach als Eintrag "Der Code soll nicht unsicher sein" zu haben.
LLMs funktionieren am besten mit möglichst präzisen Instruktionen und vermeiden am ehesten Fehler, die ihnen "bewusst" sind.
Weitere solche Regeln können je nach Projekt und Risiko definiert werden. Dazu kann man bestimmte Programmabschnitte besonders hervorheben, z. B. jene, die besonders kritisch sind für die Sicherheit der Anwendung. Besonders hier ist es wichtig, dass die LLM-Agenten wissen, wie sie sicher arbeiten sollen. Dabei können auch klar definierte Architektur- bzw. Sicherheitsentscheidungen helfen. Falls es sich hier um eine sehr große Anwendung handelt, kann es sich schon lohnen, diese Regelungen zentral zu verwalten und die KI-Agenten gezielt darauf zugreifen zu lassen, beispielsweise per MCP-Server, der nur die Architekturentscheidungen holt, die für die aktuellen Arbeiten relevant sind. Das spart in diesem Fall nicht nur Zeit, sondern auch die Menge an Token, die verbraucht werden, und somit Geld. Zusätzlich arbeitet die KI präziser, da eine genauere Menge an Instruktionen in den Kontext geladen wird und so der Fokus nicht genommen wird.
Vorsicht ist hier nur geboten, den Agenten auch Raum zu geben, Fehler zu finden, die nicht spezifisch definiert worden sind. Ein Problem, das nämlich auftreten kann, ist, dass Agenten instruiert werden, Thema A, B und C zu finden, aber so X übersehen wird. Aus diesem Grund definiere ich tendenziell die Instruktionen als Beispiele und gebe dem Agenten den Raum, auch periphere Fehler zu finden.
Eine Natur von LLMs ist, dass diese wie andere neuronale Netze trainiert werden müssen. Dieses Training kostet Zeit, und nach dem Training wird eine gewisse Zeit genutzt, um das Modell zu testen. Erst dann wird es veröffentlicht.
Das bedeutet, dass alles, was das LLM kennt, eine Welt aus der Zeit der Trainingsdaten ist. Ist dieser Cutoff vor einem halben Jahr gewesen, oder gab es zumindest keine Aktualisierung der Trainingsdaten zu einem bestimmten Paket, dann kennt das LLM auch nur das Veraltete. Aus diesem Grund ist es wichtig, sich im Klaren zu sein, dass die Informationen, die ein LLM einem geben kann, zumindest ohne eine Suche im Web zu starten, nicht immer aktuell sind.
Eine Instruktion, die sich daraus ableitet, ist, dass man sich von Agenten im Falle des Hinzufügens einer neuen Abhängigkeit die neueste stable Version aus den offiziellen Quellen bestätigen lassen soll.
Letztlich bleibt noch das Thema von einem Sicherheitsreview. Diese müssen in einer KI-getriebenen Entwicklungsabteilung aus Notwendigkeit in der Kooperation von Mensch und Maschine gemacht werden. Der Mensch bleibt hier weiterhin wichtig, um die Fehlentscheidungen von den LLMs abzufangen, allerdings benötigt der Mensch die Beschleunigung von der KI, um dem Arbeitsaufwand hinterherzukommen. Hier greifen auch die vorherigen beiden Themen: Die Scanner verringern die Chance, dass etwas übersehen wird, und liefern schon die ersten Ergebnisse, während durch die gehärteten Regeln für die KI-Agenten die Schwachstellen erst gar nicht in den Code kommen.
Um effizient durch den Code zu kommen und wirkliche Schwachstellen zu entdecken, empfehle ich, auch hier sehr spezifisch zu sein. Gerade wenn es sich in dem Review um viele Veränderungen handelt, ist es sinnvoll, nicht einen KI-Agenten auf alles loszulassen, sondern gezielte und differenzierte Instruktionen zu geben.
Typischerweise verwendet man hierfür dann eine Auswahl an Agenten, die mit bestimmten Instruktionen gestartet werden und denen eine Persona gegeben wird. So wird ein Agent gestartet, der sich spezifisch Injection-Themen anschaut, ein Agent, der die Kryptographie inspiziert, ein Agent, der neue Features Threat-modeled usw. Eben getrennte Aufgaben, die am Ende auf spezifischere Fragen Antworten liefern, da so die Chancen erhöht werden, dass das LLM dies in Betracht zieht.
// Beispiel-Instruktion für einen Agenten, der unsichere Kryptographie abfangen soll
Du bist ein LLM-Agent, der ein Experte in der Verwendung von Kryptographie und Systemsicherheit ist.
Deine Aufgabe ist es, Schwachstellen und Gefahren im Code und dessen Architektur zu finden.
// === Spezifische Kryptographie-Beispiele für das LLM ===
// Ich ziele auf mindestens 10 bis maximal 30 echte Beispiele.
// Aus Platzgründen lasse ich diese hier weg.
// Vielleicht ergibt sich daraus ein weiterer Artikel
Die Ergebnisse sollen so aufgearbeitet sein, dass entweder ein User oder ein
LLM-Agent, welcher diese Scans orchestriert, diese strukturiert durchlesen kann.
Als Beispiel für die Struktur der Rückgabe dient die folgende Tabelle:
| ID | Titel | Pfad | Zeile(n) | Chance | Impact | Begründung |
| CRYPT01 | Insecure time-based RNG | src/lib/crypt.js | 37 - 38 | MEDIUM | HIGH | <<Detaillierte Begründung>> |
| CRYPT02 | Unsalted Password storage | src/lib/crypt.js | 127 | LOW | CRITICAL | <<Detaillierte Begründung>> |
Bewerte die Befunde anhand der Eintrittswahrscheinlichkeit und des Impacts.
Beide können nur die Werte LOW, MEDIUM, HIGH, CRITICAL annehmen.
Die Eintrittswahrscheinlichkeit ergibt sich aus der Komplexität des Ausnutzens und der Erreichbarkeit der Schwachstelle.
Der Impact ergibt sich aus den betroffenen Daten, erlangbaren Rechten, Ausbreitungs- und Persistenzmöglichkeiten
und dem Ausmaß der Betroffenheit der Vertraulichkeit, Integrität und Verfügbarkeit.
Alle Befunde sollen mit einer Begründung versehen werden, warum es wirklich eine Schwachstelle ist.
Dazu zählt, dass begründet wird, warum diese Schwachstelle generell ein Problem ist und warum sie in diesem spezifischen System ein Problem ist.
Mit dieser Art von Grundprompt für einen Agenten kann man schon wirklich gute Ergebnisse erzielen. Wenn alle Agenten, die so gestartet werden, diese Art von Prompt haben und so auch ein einheitliches Ergebnis liefern, kann ein orchestrierender Agent sehr gut die Ergebnisse am Ende zusammenführen.
An Orten, an denen LLMs (oder auch Menschen) Werte einschätzen sollen, tendiere ich dazu, eine gerade und niedrige Menge an Optionen zu wählen. Das Konzept kommt aus der Psychologie und zwingt Mensch und hier Maschine dazu, nicht zur Mitte zu tendieren, und erzwingt meinungsstärkere Antworten.
Sind diese Ergebnisse einmal von dem oder den Agenten zusammengeführt, so kann ein Mensch sich der Evaluation widmen und prüfen, ob noch Themen im Code zu behandeln sind.
Ich hoffe, mit diesen Grundbausteinen konnte ich euch helfen, etwas mehr über Sicherheit nachzudenken, oder euch vielleicht dazu inspirieren, die Sicherheit in eurer Entwicklungsabteilung mitzuziehen. Im best-case nimmt es euch sogar Arbeit ab. Viele dieser Methoden sind recht leicht einbaubar, und selbst falls ihr keinen Support bekommt von den Führungspersonen, könnt ihr nun zumindest über die LLM-Agenten euren Code etwas sicherer machen.
Das Zusammenspiel aus Automatisierung und menschlicher Kontrolle ist in meinen Augen immer noch absolut nötig, da die KI-Systeme (und seien wir mal ehrlich, es handelt sich in den aktuellen Diskussionen immer um LLMs) noch zu leicht Fehler übersehen. Ein passender Vergleich ist dieser: Deterministische Scanner sind wie ein grobes Sieb. Sie filtern alles, was nicht in den restlichen Sand gehört, aber übersehen die Nadel, welche durch die Löcher passt. Ein LLM, das nach Schwachstellen sucht, ist wie eine Hand, die im Sand nach Irregularitäten sucht. Dort, wo die Nerven der Finger etwas spüren, wird auch etwas gefunden, aber überall sonst bleibt die Schwachstelle im Sand versteckt.
Also nochmal zurück zum Anfang, hätte unser Software-Team die SQL-Injection gefunden mithilfe von diesen Ratschlägen? Die Frage ist sogar eine Fangfrage. Der Fehler wäre vielleicht nicht mal in das System gekommen! Der SAST-Scanner hätte das Fehlerpattern wahrscheinlich entdeckt, der Security-Review-Agent hätte wahrscheinlich eine Schwachstelle gemeldet und die Agentenregeln fürs Programmieren hätten wahrscheinlich dafür gesorgt, dass die Schwachstelle erst gar nicht in den Code gekommen wäre.
Der letzte Satz hat hoffentlich für etwas Verwirrung gesorgt, denn bei jeder Maßnahme, die die Sicherheit erhöhen soll, stand das Wort 'wahrscheinlich' davor, was bestimmt für einige von euch etwas unbefriedigend sein wird. Die Realität ist jedoch, dass Sicherheit nie zu 100% gewährt werden kann. Man kann sich immer nur einem komplett sicheren System annähern, indem man mehrere Schichten baut, die sich gegenseitig ergänzen und ein möglichst breites, aber auch tiefes Feld an Fehlerquellen abdecken. Nur so kann das Risiko minimiert werden, nur so kann der Schaden gering gehalten werden.
Möchtest du mehr über diese Inhalte Erfahren? Dann melde dich gerne bei mir!