AI-Coding im Härtetest: Sicherheit, Vertrauen und Risiken 2025

Gamer

30. September 2025

Lesezeit: 6 Min.

AI-gestützte Softwareentwicklung ist endgültig im Mainstream angekommen: Laut einer neuen Google-Cloud-Umfrage setzen inzwischen 90 % der Tech-Profis KI-Tools im Arbeitsalltag ein – ein Plus von 14 Prozentpunkten gegenüber dem Vorjahr. Gleichzeitig bleibt das Vertrauen in die Ergebnisse der Systeme gering. Für IT-Sicherheitsteams ist das ein Weckruf: Produktivitätsgewinne sind real, aber ohne Guardrails drohen Sicherheitslücken, Compliance-Verstöße und schwer kontrollierbare Risiken.

Warum Entwickler KI nutzen – und wo Sicherheitslücken lauern

Die Versprechen von KI-Assistenten reichen von schnellerem Boilerplate-Code über automatisierte Tests bis hin zu Hilfe bei Refactoring und Dokumentation. In der Praxis verschiebt sich dadurch die „Time-to-Commit“ massiv – ein klarer Produktivitätshebel. Doch gerade in der IT-Sicherheit gilt: Geschwindigkeit ohne Kontrolle schafft Angriffsflächen. KI-Systeme können Halluzinationen produzieren, unsichere Defaults vorschlagen oder in guter Absicht riskante Abhängigkeiten einführen. Wer DevSecOps ernst meint, muss deshalb Standards, Prüfungen und Observability von Anfang an mitplanen.

Risiko 1: Halluzinierter Code und unsichere Defaults

KI-Tools generieren gelegentlich plausibel klingenden, aber unsicheren Code – etwa fehlende Eingabevalidierung (SQL/NoSQL-Injection), schwache Kryptografie, unsichere Deserialisierung oder mangelnde Fehlerbehandlung, die Informationen preisgibt. Für die IT-Sicherheit heißt das: Behandle KI-Ausgaben wie den Code eines neuen Teammitglieds. Setze verbindliche Secure-Coding-Guidelines, enforced durch SAST-Regeln, Pre-Commit-Hooks und Code-Review mit Vier-Augen-Prinzip. Ergänze dies um automatisierte Testfälle für die häufigsten Schwachstellen (z. B. OWASP Top 10) und Negative Tests.

Risiko 2: Datenabfluss und Geheimnisse

Prompts, Code-Snippets und Logs enthalten oft sensible Informationen – von API-Schlüsseln bis zu personenbezogenen Daten. Abhängig vom Tooling können solche Informationen ungewollt in Telemetrie fließen. Reduziere das Risiko mit Data-Loss-Prevention, Secret-Scanning (z. B. Pre-Commit/CI), redigierten Prompts und klaren Richtlinien, was in KI-Systeme eingegeben werden darf. Für hochsensible Kontexte kann der Einsatz lokaler Modelle oder isolierter Unternehmens-Endpunkte sinnvoll sein.

Risiko 3: Supply-Chain und Lizenzfragen

KI-Assistenten schlagen häufig zusätzliche Libraries vor. Das erhöht die Angriffsfläche und kann Lizenz-Compliance gefährden. Nutze Software Composition Analysis (SCA), eine strikte Allowlist für Abhängigkeiten, SBOMs (Software Bill of Materials) und verdrahte Artefakt-Repositories. Pinne Versionen, etabliere Dependabot-ähnliche Updates mit Review und prüfe Lizenztypen automatisch. Sicherheit beginnt in der Lieferkette.

Risiko 4: Prompt-Injection und überprivilegierte Agenten

Mit wachsender Tooling-Integration (z. B. Agenten mit Shell-, Git- oder Cloud-Rechten) steigt das Risiko von Prompt-Injection, SSRF und ungewollten Aktionen. Isoliere Agenten in Sandboxes, beschränke Ausführungsrechte (Least Privilege), setze Egress-Kontrollen, genehmigungspflichtige „High-Risk“-Befehle und Audit-Logs durch. Validierte Eingaben, strikte Policy-as-Code und sichere Default-Einstellungen sind Pflicht.

Vertrauen bleibt niedrig: Governance schlägt Bauchgefühl

Die geringe Vertrauensbasis in KI-Ausgaben ist kein Bug, sondern ein Sicherheitsfeature – Skepsis bewahrt vor Blindflug. Eine robuste Governance schafft den Rahmen, in dem Teams produktiv und sicher mit KI arbeiten. Orientierung geben etablierte Standards und Best Practices wie Secure SDLC, NIST-SSDF, SLSA für die Software-Lieferkette oder die OWASP-Empfehlungen für LLM-Anwendungen. Entscheidend ist die Operationalisierung: Policies, Metriken, Audits.

Messbare Qualität statt Hoffnung

Definiere Qualitätsziele für KI-generierten Code: Abdeckung durch Unit-/Integrationstests, SAST/DAST-Befundquote, Mean-Time-to-Fix für Findings, Regressionsraten. Führe „Golden Prompts“ mit erwartbaren Output-Beispielen ein und vergleiche Vorschläge über die Zeit. So wird Vertrauen messbar – und verbesserbar.

Transparenz: SBOM, Änderungsjournal und Kennzeichnung

Dokumentiere, wo KI mitgewirkt hat: Commit-Tags (z. B. „Co-authored-by: AI“), Ticket-Referenzen, Changesets. Ergänze jede Build-Artefakt mit einer SBOM und einem signierten Provenance-Record. Das unterstützt Audits, Forensik und erleichtert das Patch-Management bei Zero-Day-Lücken.

Praktische Schutzmaßnahmen für deinen Stack

  • Policies & Awareness: Erstelle klare Richtlinien zu zulässigen Tools, Datenklassen und Freigabeprozessen. Ergänze dies um regelmäßige Security-Awareness-Trainings und Phishing-Simulationen, um Social Engineering und Fehlbedienung zu minimieren.
  • IDE- und Prompt-Hygiene: Aktivere Secret-Scanning in der IDE, nutze Maskierung für Token, setze einen zentralen „AI-Gateway“-Proxy mit Redaction und Logging ein. Sensible Prompts gehören nicht in externe Dienste.
  • Pipeline-Härtung (DevSecOps): SAST, DAST, IAST, SCA, IaC-Scanning und Container-Scanning gehören in jede CI/CD-Stufe. Führe Mandatory Reviews für sicherheitsrelevante Änderungen ein und blockiere Deployments bei kritischen Findings.
  • Supply-Chain-Schutz: Erstelle und prüfe SBOMs, nutze signierte Artefakte, private Registries und reproduzierbare Builds. Etabliere eine Allowlist für Abhängigkeiten und halte diese aktuell.
  • Zugriff & Geheimnisse: MFA, Just-in-Time-Zugriff, Least Privilege, Secrets-Manager und kurzlebige Tokens. Keine Schlüssel in Prompts, Tickets oder Chat-Tools.
  • Runtime-Abwehr: WAF/API-Gateways mit Schema-Validierung, RASP/EDR im Workload, Rate Limiting und Anomalieerkennung gegen Exploit-Ketten (z. B. Ransomware nach Initial Access).
  • Monitoring & Forensik: Zentrales Logging, Prompt-/Agenten-Telemetrie, Alerting auf Policy-Verstöße. Klare Playbooks für Incident Response, inklusive LLM-spezifischer Szenarien (Prompt-Injection, Datenabfluss).
  • Standardwerke verankern: Richte dich nach Zero-Trust-Prinzipien (Least Privilege, kontinuierliche Verifikation). Mehr dazu in unserem Zero-Trust-Guide und den weiterführenden Beiträgen im Security-Blog.

Beispiel aus der Praxis: Terraform-Misskonfiguration durch KI

Ein Team nutzt einen KI-Assistenten, um Terraform-Snippets zu schreiben. Das Tool schlägt eine S3-ähnliche Storage-Ressource mit vereinfachten Zugriffsregeln vor. Im Code-Review fällt es nicht auf, dass die Ressource „public-read“ setzt. In der CI schlägt jedoch das IaC-Scanning an, die Policy-as-Code blockiert den Merge, und ein Guardrail schlägt sichere Defaults vor. Ergebnis: keine Exposition, kein Datenabfluss.

Lehrstück: KI hat Tempo gebracht, doch die Sicherheitsnetze – IaC-Scanner, Policy-as-Code, verpflichtende Reviews – haben die Lücke geschlossen. Genau so sollte moderne IT-Sicherheit mit KI funktionieren.

Pro und Contra: KI-Coding-Assistenten im Sicherheitscheck

Pro

  • Schnelleres Prototyping und höhere Developer-Produktivität.
  • Automatisierte Tests, Dokumentation und Refactoring-Hilfen.
  • Geringere Eintrittshürden für sichere Patterns – wenn Guardrails aktiv sind.

Contra

  • Halluzinierter oder veralteter Code kann neue Schwachstellen einführen.
  • Risiko von Datenabfluss und Compliance-Verstößen durch ungefilterte Prompts.
  • Erhöhte Angriffsfläche in der Software-Lieferkette und durch neue Abhängigkeiten.

Fazit: Mit Guardrails wird KI zum Sicherheitsgewinn

Der KI-Einsatz in der Entwicklung bleibt – und wächst. Die Google-Cloud-Zahl von 90 % Nutzung zeigt, dass die Frage nicht „ob“, sondern „wie sicher“ lautet. Wer KI wie eine leistungsfähige, aber unerfahrene Kollegin behandelt, liegt richtig: klare Richtlinien, verpflichtende Prüfungen, starke Pipeline-Kontrollen und kontinuierliche Schulungen. So lassen sich Risiken wie Prompt-Injection, Datenabfluss, Zero-Day-Folgeschäden und Supply-Chain-Attacken deutlich reduzieren.

Starte jetzt mit einem Security-Review deiner Toolchain, definiere eine KI-Policy und führe Guardrails in der CI/CD ein. Nutze unsere Awareness-Trainings und den Leitfaden zu Phishing-Simulationen, um die menschliche Komponente zu stärken – die beste Prävention gegen Social Engineering, Fehlkonfigurationen und Ransomware-Ketten. Weitere Praxis-Artikel findest du im Security-Blog.

Tags: AI Security, DevSecOps, Software Supply Chain, LLM Security, Secure Coding