Die berechtigte Frage
Wenn eine KI beim Bauen von Software hilft, ist die Sorge naheliegend: Kann ich dem Ergebnis trauen? Steckt da eine Sicherheitslücke drin, die mir irgendwann um die Ohren fliegt? Die Frage ist berechtigt, und wer sie mit „KI macht das schon richtig" abtut, hat entweder keine Ahnung oder verkauft dir etwas.
Die ehrliche Antwort: KI-generierter Code ist nicht per se sicher und nicht per se unsicher. Er ist so sicher, wie der Prozess drumherum ihn macht. In diesem Artikel zeige ich, wo die echten Risiken liegen, warum Sicherheit nicht vom Sprachmodell kommt, und woran du erkennst, dass jemand sauber arbeitet.
Wo KI-Code wirklich Risiken hat
Fangen wir bei der Ehrlichkeit an. KI-generierter Code hat ein paar typische Schwachstellen, die man kennen muss.
Erstens: erfundene oder unsichere Abhängigkeiten. KI schlägt manchmal Programmbibliotheken vor, die es gar nicht gibt oder die bekannte Lücken haben. Wer das ungeprüft übernimmt, baut sich ein Einfallstor ein.
Zweitens: fehlende Prüfung von Eingaben. Ein Prototyp nimmt an, dass der Nutzer brav das Richtige eingibt. Ein Angreifer tut das nicht. Ohne saubere Prüfung von allem, was von außen kommt, entstehen genau die klassischen Lücken, über die Systeme übernommen werden.
Drittens: verratene Geheimnisse. Zugangsdaten oder Schlüssel, die im Code landen und dann versehentlich in einem Repository oder einem Log auftauchen, sind einer der häufigsten realen Sicherheitsvorfälle überhaupt. KI, die schnell Beispielcode produziert, verleitet dazu, so etwas hineinzuschreiben.
Diese Risiken sind real. Aber, und das ist der Punkt, es sind alles Risiken, gegen die es etablierte Gegenmittel gibt. Sie entstehen nicht, weil KI im Spiel ist, sondern weil jemand die Sorgfalt weglässt.
Sicherheit kommt nicht vom Modell, sondern vom Prozess
Das ist der Kern. Kein Sprachmodell, egal wie gut, macht deine Software sicher. Sicherheit ist keine Eigenschaft des Codes, den die KI ausspuckt, sondern des Prozesses, durch den dieser Code läuft, bevor er in Betrieb geht.
Ein Angreifer fragt nicht, ob dein Code von einem Menschen oder einer KI stammt. Er sucht nach der Lücke. Und ob die Lücke drin ist, entscheidet sich daran, ob jemand nach ihr gesucht hat, bevor der Code live ging. Genau das ist die Aufgabe eines ordentlichen Bau-Prozesses: die Lücken finden, bevor es ein anderer tut.
Was ein sicherer Bau-Prozess mitbringt
Woran erkennst du also, dass jemand sauber arbeitet? An ein paar konkreten Dingen, nach denen du fragen kannst.
Geheimnisse liegen nie im Code, sondern in einem separaten, verschlüsselten Speicher, aus dem die Software sie zur Laufzeit zieht. Jede Eingabe von außen wird geprüft und bereinigt, bevor sie verarbeitet wird. Abhängigkeiten sind fest verankert und werden auf bekannte Lücken geprüft, statt blind die neueste Version zu ziehen. Automatisierte Sicherheitsprüfungen laufen mit, bevor überhaupt etwas ausgeliefert wird, und blockieren im Zweifel den Weg in die Produktion. Und die Daten liegen dort, wo sie hingehören, in der EU, unter deiner Kontrolle, statt auf irgendeinem Server, dessen Standort niemand kennt.
Nichts davon ist exotisch. Es ist das Handwerk seriöser Softwareentwicklung. Der Unterschied ist nur, dass es beim schnellen Prompten gern weggelassen wird, weil es in der Demo niemand sieht.
Ein Beispiel: die Absicherung dieser Website
Damit das konkret wird, ein Blick auf die Seite, die du gerade liest. Sie ist bewusst schlank gebaut, und trotzdem läuft vor jeder Veröffentlichung eine automatisierte Sicherheitsprüfung mit. Sie durchsucht die Dateien nach versehentlich hinterlassenen Zugangsdaten oder Schlüsseln und blockiert die Veröffentlichung, falls sie etwas findet. Sie prüft, ob die Schutzregeln des Browsers gegen eingeschleuste Skripte korrekt gesetzt sind. Und sie stellt sicher, dass sensible interne Dateien gar nicht erst mit ausgeliefert werden.
Dazu kommen die üblichen, aber wichtigen Dinge: strikte Sicherheits-Header, verschlüsselte Verbindung, kein Nutzer-Tracking, das Daten abgreift, und Schriften und Analyse laufen lokal, statt Besucherdaten an Dritte zu geben. Das ist kein großer Aufwand, aber es ist der Unterschied zwischen „wird schon passen" und „ist bewusst abgesichert".
Wie funktioniert das technisch?
Jetzt wird es etwas technischer. Wer nur die Grundhaltung mitnehmen wollte, kann direkt zum Fazit springen.
Die wirksamste Absicherung ist die, die automatisch passiert und die man nicht vergessen kann. Bei meinen Projekten läuft deshalb vor jeder Auslieferung eine Kette von Prüfungen: Der Code wird in einer sauberen Umgebung gebaut, Abhängigkeiten werden gegen bekannte Schwachstellen abgeglichen, und ein Scan sucht nach Geheimnissen, die nichts im Code zu suchen haben. Erst wenn all das durchläuft, geht überhaupt etwas in Betrieb.
Zur Laufzeit gelten weitere Prinzipien. Zugangsdaten kommen aus einem verschlüsselten Geheimnis-Speicher, nicht aus dem Code. Eingaben werden bereinigt, bevor sie verarbeitet werden. Wo KI mit personenbezogenen Daten arbeitet, maskiert ein Vorfilter das Sensibelste, bevor es überhaupt an ein Modell geht, und die Modelle laufen über europäische Anbieter mit EU-Endpunkten. So bleibt selbst dann, wenn irgendwo doch etwas schiefgeht, der mögliche Schaden begrenzt.
Sicherheit ist also nicht ein einzelnes Feature, das man am Ende dranschraubt, sondern eine Reihe von Gewohnheiten, die in den Bau-Prozess eingebaut sind. Genau das unterscheidet Software, der du vertrauen kannst, von Software, die nur noch nicht aufgefallen ist.
Fazit
Ob mit KI gebaute Software sicher ist, hängt nicht von der KI ab, sondern von dem, der sie einsetzt. KI-generierter Code hat typische Schwachstellen, aber gegen jede davon gibt es ein etabliertes Gegenmittel. Sicher wird Software durch Prozess, nicht durch das Modell.
Wenn du also jemanden mit einem KI-Projekt beauftragst, frag nicht, welches Modell er benutzt. Frag, was passiert, bevor sein Code live geht. Wie er mit Geheimnissen umgeht, wie er Eingaben prüft, welche automatischen Kontrollen mitlaufen und wo deine Daten liegen. Die Antworten auf diese Fragen sagen dir mehr über die Sicherheit deines Projekts als jedes Technik-Versprechen.