Warum braucht es ein Projekt wie SecureCoder?
Mehr als 90 Prozent der Softwareentwicklerinnen und -entwickler nutzen heute KI-gestützte Programmierhilfen wie GitHub Copilot oder Cursor – und der Trend beschleunigt sich. Gleichzeitig zeigen systematische Studien: Ein erheblicher Anteil des KI-generierten Codes enthält Sicherheitslücken – Pufferüberläufe, unsichere API-Aufrufe, fehlende Eingabevalidierung. Das liegt nicht daran, dass KI nachlässig ist. Das liegt daran, dass die Modelle ursprünglich auf Korrektheit und Produktivität optimiert wurden – nicht auf Sicherheit.

Die gängige Reaktion darauf ist, nachgelagerte Prüfwerkzeuge einzusetzen: statische Analyse, Vulnerability-Scanner. Aber das ist das falsche Paradigma. Damit behandeln wir Symptome, keine Ursachen. SecureCoder fragt anders: Wie muss ein KI-System gebaut sein, damit sicherer Code die natürliche Ausgabe ist und nicht das Ergebnis nachträglicher Korrekturen? Unser Leitbild sind typsichere Programmiersprachen: nicht weil man Fehler im Nachhinein abfängt, sondern weil die Sprachstruktur bestimmte Fehlerklassen von vornherein unmöglich macht. Das ist Security by Construction.

Die Dringlichkeit wächst noch: Softwareentwicklung wird zunehmend agentisch – KI-Agenten planen, schreiben, testen und deployen Code autonom, oft ohne direkte menschliche Aufsicht. In solchen Pipelines kann eine einzige Sicherheitslücke, die ein Agent erzeugt, unbemerkt durch das gesamte System propagieren, bevor ein Mensch auch nur eine Zeile gesehen hat. SecureCoder ist explizit darauf ausgelegt, auch diese neue Klasse von Sicherheitsproblemen zu adressieren – nicht nur einzelne Codevorschläge, sondern ganze KI-gesteuerte Entwicklungsworkflows.

Wie unterscheidet sich Ihre Technik von bisherigen KI-Modellen?
Unsere technischen Entscheidungen sind direkte Antworten auf die Schwächen bestehender Architekturen für sichere Codegenerierung. Die meisten großen Sprachmodelle basieren auf der Transformer-Architektur und erzeugen Code autoregressiv – Token für Token, von links nach rechts, ohne Möglichkeit, frühere Entscheidungen zu revidieren. Das ist ein fun­da­men­ta­les Missverhältnis: Sicher­heits­eigen­schaften hängen oft von Interaktionen zwischen weit entfernten Programmteilen ab, sie erfordern ganzheitliches Denken, kein inkrementelles Einpflegen.

Wir erkunden zwei architektonische Alternativen. Erstens: State-Space-Models (SSMs) – Modelle mit linearer statt quadratischer Komplexität, die über ganze Codebasen mit hunderttausenden Zeilen hinweg schlussfolgern können, ohne die Rechenkosten zu sprengen. SSMs pflegen einen expliziten, aktualisierbaren internen Zustand, was gut zu den strukturierten, abhängigkeitsbasierten Schlüssen passt, die Sicherheitsanalysen verlangen. Zweitens: Diffusions-Sprachmodelle, die Code nicht in einem einzigen Links-rechts-Durchgang erzeugen, sondern iterativ verfeinern – von einem anfänglich unscharfen Entwurf zu sauberem, sicherem Code. Bei jedem Verfeinerungsschritt kann ein Constraint-Mechanismus bekannte Schwachstellenmuster strukturell ausschließen.

Das Training dieser Modelle nutzt Off-Policy Reinforcement Learning mit verifizier­baren Belohnungssignalen: Wir setzen symbolische Werkzeuge, wie etwas Typprüfer, statische Analysatoren, formale Verifizierer, als parallele Evaluatoren ein. Sie liefern konkretes, überprüfbares Feedback ohne den Engpass manueller Annotation. Das Zusammenspiel von SSM-Backbone, Diffusions-LM, Constraint Decoding und Off-Policy Reinforcement Learning mit verifizier­baren Belohnungssignalen als integriertes System ist, nach unserem Kenntnisstand, in dieser Form neu.

Im Projekt SecureCoder wenden Sie und Ihr Team Fachwissen aus verschiedenen Bereichen an. Wie greift das ineinander?
Was SecureCoder wirklich inter­dis­zi­pli­när macht, ist die Einsicht, dass Sicherheit in KI-generiertem Code ein grundlegend mehrschichtiges Problem ist und dass diese Schichten mit­ei­nan­der interagieren. Kompromittierte Trainingsdaten untergraben selbst die beste Modellarchitektur. Ein einwandfreies Modell auf sauberen Daten kann immer noch unsicheren Code erzeugen, wenn der Generierungsprozess kein Sicherheitsbewusstsein hat. Und eine gut konzipierte Generierung kann durch adversarielle Eingaben umgangen werden, wenn es keine Laufzeitdurchsetzung gibt. Nur eine Schicht zu behandeln, gibt ein falsches Sicherheitsgefühl.

Wir vereinen Fachwissen aus Programmiersprachen und formaler Verifikation, maschinellem Lernen und NLP sowie Cybersicherheit. Die vier Hauptkomponenten – kuratierte Trainingsdaten, sicherheitsorientiertes Modelltraining, Constraint Decoding und Security-Critic-RL-Modelle – bilden keine Kette, sondern eine Rückkopplungsschleife: Critics entdecken Fehler, die die Trainingsdaten verbessern; Constraint-Engines leiten ihre Regeln aus derselben Sicherheitswissensbasis ab, die auch das Prompting informiert; Benchmark-Ergebnisse treiben die Modellverfeinerung an.

Diese Architektur erweitern wir explizit auf agentische Entwicklungsumgebungen. In einer Multi-Agenten-Pipeline – mit Orchestrierungs-, Generierungs-, Retrieval-, Verifikations- und Gedächtnisagenten – muss Sicherheit in die Interaktionen zwischen den Agenten eingebaut werden, nicht nur in einzelne Generierungsschritte. Das bedeutet Security Critics, die Agentengrenzen überwachen, Constraint-Mechanismen für Werkzeugzugriff und Ausführungsumfang sowie Audit-Trails, die das Verhalten der gesamten Pipeline nachvollziehbar machen.

Wie genau wird der generierte Code sicherer gemacht?
Sicherheit greift in SecureCoder an mehreren Stellen – und diese Stellen sind mit­ei­nan­der verbunden.
Vor dem Training werden die Trainingsdaten von historischen Schwachstellen bereinigt und mit Sicherheitswissen aus Quellen wie dem MITRE-CWE-Katalog, den OWASP-Richtlinien und der CVE-Datenbank angereichert.

Nach dem Vortrainieren mit diesen kuratierten Daten wird das Modell mithilfe von Off-Policy Reinforcement Learning und verifizier­baren Signalen aus symbolischen Softwarequalitätssicherungsmethoden – etwa Typprüfern, statischen Analysetools und formalen Verifikatoren – auf Sicherheitsstandards nachtrainiert.

Entwickler-Prompts werden automatisch um sicherheitsrelevanten Kontext ergänzt – auch wenn die Person selbst nicht explizit danach fragt. 

Während der Generierung setzt Constraint Decoding Sicher­heits­eigen­schaften durch. Das ist kein weicher Hinweis: Bestimmte Muster, wie bekannt unsichere API-Aufrufe, verbotene Speicheroperationen oder fehlende Validierungsschritte, können strukturell unmöglich gemacht werden, ähnlich wie ein Typsystem Typfehler als solche gar nicht erst zulässt. Harte Constraints erzwingen absolute Verbote; weiche Constraints lenken das Modell zu sichereren Idiomen, ohne die Flexibilität zu opfern.

Nach der Generierung überprüfen dedizierte Security-Critic-Modelle den Output – nicht isoliert, sondern im Kontext der gesamten Codebasis. Eine Schwachstelle, die in einer isolierten Funktion unsichtbar ist, kann offensichtlich werden, sobald man ihre Interaktion mit dem Rest des Systems betrachtet.

In agentischen Entwicklungsworkflows greift diese mehrstufige Sicherheitsarchitektur auch zwischen Agenten: Ein Critic kann den Code eines Generierungsagenten prüfen, bevor ein Deployment-Agent ihn ausführt.

Ist Ihr Ansatz weltweit einzigartig?
In mehrfacher Hinsicht, ja. State-Space-Models wurden für natürliche Sprache erforscht, aber ihre systematische Anwendung auf sichere Codegenerierung ist weitgehend unerschlossenes Terrain. Unsere Arbeit an dem CodeSSM Model, das die Grundlage für das SecureCoder Projekt bildet, war einer der ersten, die hier eine Grundlage etablieren.

Die Kombination von SSMs, Diffusions-Sprachmodellen, Off-Policy RL mit verifizierten Signalen und Constraint Decoding als integriertes System für Sicherheit ist nach unserem Wissen in dieser Form neu.

Aber was wir als konzeptuell bedeutsamer einschätzen, ist das übergeordnete Framing: Sicherheit nicht als nachgelagerte Qualitätsprüfung zu behandeln, sondern als strukturelle Eigenschaft, die in jede Phase der KI-gestützten Entwicklung eingebaut sein muss – von der Datenkuration über das Training und die Generierung bis zu den Laufzeitguardrails. Das rückt SecureCoder näher an die Tradition der Programmiersprachenforschung, wo Sicher­heits­eigen­schaften durch Konstruktion erzwungen werden, als an die Tradition des Softwaretestens, wo sie nachträglich geprüft werden.

Am weitesten vorn sind wir in einem Bereich, der noch kaum erforscht ist: der Sicherheit agentischer Softwareentwicklungspipelines. Kein bestehendes Framework adressiert systematisch die Sicherheitsimplikationen von Multi-Agenten-Codegenerierung – Schwachstellenpropagation über Agentengrenzen, die Sicherheit agentenübergreifender Kommunikation oder die Governance autonomen Werkzeugzugriffs. Wir legen gerade die konzeptuellen und technischen Grundlagen dafür.

Was ich an dieser Stelle hervorheben möchte, ist, dass das SSM-Backbone unseres Systems deutlich weniger Rechenleistung und Speicherplatz benötigt und mit weniger Daten lernen kann als vergleichbare Transformer Backbones. Unsere Hoffnung ist, damit ein System zu liefern, das firmenintern auf eigenen Daten trainiert und gehostet werden kann.

Wie geht es mit SecureCoder weiter?
Unmittelbar steht die Skalierung und Validierung an. Bis Ende des Jahres wächst unser Modell von einer auf sieben Milliarden Parameter, gefolgt von einer 32-Milliarden-Parameter-Version – trainiert auf der Infrastruktur von hessian.AI und in Deutschland gehostet, was europäische Datensouveränität sicherstellt. Unser Open-Source-Benchmark-Suite – mehrere Programmiersprachen, Schwachstellen aus CWE, CVE und Community-Mining – wird als gemeinsame Evaluierungsressource für die Forschungs­gemeinschaft veröffentlicht.

Die bedeutsamere nächste Grenze aber ist die Ausweitung des SecureCoder-Paradigmas auf agentische Softwareentwicklung. KI-Agenten schreiben, testen und deployen bereits heute autonom Code – oft in Multi-Agenten-Pipelines mit minimaler menschlicher Übersicht. Dabei entstehen grundlegend neue Sicherheits­heraus­forderungen: Ein orchestrierender Agent kann durch Prompt Injection manipuliert werden, um Schadcode zu erzeugen. Schwachstellen, die ein Agent einführt, können sich lautlos durch die Pipeline propagieren. Werkzeugzugriff, der einem Generierungsagenten gewährt wird, kann Privilege-Escalation-Risiken erzeugen. Das sind keine hypothetischen Szenarien, sie treten in bereits eingesetzten Systemen auf.

Wir bauen SecureCoders Kernkomponenten – Security Critics, Constraint Engines, formale Verifikationsanker – so aus, dass sie in Multi-Agenten-Architekturen arbeiten, nicht nur auf Einzelmodell-Ebene. Das Ziel: ein verifizier­barer Sicherheitsperimeter um den gesamten KI-gestützten Entwicklungsworkflow – vom Prompt bis zum Deployment. Das verbindet sich mit dem übergeordneten Agenda für ver­trauens­würdige KI: Je mehr Autonomie KI-Systeme in sicherheitskritischen Domänen erhalten, desto wichtiger ist es, Sicherheit und Rechenschaft von Anfang an einzubauen.

Weitere Informationen zu SecureCoder finden Sie unter den  ATHENE  Missionsprojekten und unter https://securecoder-project.github.io/.

 

Zur News-Übersicht