Security & Produktionsreife

KI-Code prüfen, bevor er live geht

Mit KI-Assistenten entsteht eine funktionierende Anwendung in Tagen. Ob sie auch sicher ist, zeigt die Oberfläche nicht. Wir prüfen Prototypen, interne Tools und Apps vor dem produktiven Einsatz auf Sicherheitslücken und Betriebsreife und liefern eine priorisierte Liste mit konkreten Korrekturen.

Kostenloses Erstgespräch Case Study: best-body-shop.de

Befunde mit konkreter Korrektur Prüfung nach OWASP-Kategorien Klare Go-live-Entscheidung

Audit: 1–2 Wochen
Ergebnis: Befundliste
Abschluss: Go-live-Gate

Ausgangslage

Was schnell gebauter Code oft übersieht.

Der Entstehungsweg ist nicht das Problem. Das Problem ist, was ein Assistent weglässt, wenn niemand danach fragt: alles, was im Normalfall unsichtbar bleibt.

Rechteprüfung nur in der Oberfläche

Der Button ist ausgeblendet, die Schnittstelle dahinter aber offen. Wer die Adresse kennt, ruft fremde Daten direkt ab.

Schlüssel im Code

API-Schlüssel und Zugangsdaten stehen im Quelltext, im Browser-Bundle oder in Protokollen. Dort findet sie früher oder später jemand.

Ungeprüfte Abhängigkeiten

Pakete wurden übernommen, weil der Assistent sie vorgeschlagen hat. Ob sie gepflegt werden, bekannte Lücken haben oder überhaupt nötig sind, hat niemand geprüft.

Kein Plan für den Ausfall

Es gibt keine Überwachung, keine Protokolle und keinen Weg zurück zur letzten funktionierenden Version. Beim ersten Fehler im Betrieb fehlt jeder Anhaltspunkt.

Leistungsumfang

Was wir prüfen.

Wir prüfen das Ergebnis, nicht die Methode. Für KI-geschriebenen Code gelten dieselben Anforderungen wie für handgeschriebenen. Dazu kommen Prüfungen, die nur Anwendungen mit Sprachmodell betreffen.

Leistung anfragen

Authentifizierung und Autorisierung

Jede Schnittstelle wird serverseitig geprüft: Wer ist angemeldet, und darf diese Person genau diesen Datensatz sehen oder ändern?

Mandantentrennung

Bei Anwendungen für mehrere Kunden oder Shops testen wir gezielt, ob Daten eines Mandanten für einen anderen erreichbar sind.

Secrets und Konfiguration

Zugangsdaten, Umgebungsvariablen und Berechtigungen der eingesetzten Schlüssel. Jeder Schlüssel darf nur, was die Anwendung braucht.

Eingaben und Abhängigkeiten

Validierung aller Eingaben an der Servergrenze, Prüfung der Pakete auf bekannte Schwachstellen und auf ihre Herkunft.

Prompt Injection und Tool-Missbrauch

Kann ein manipulierter Text, etwa in einer Kundenmail oder Produktbeschreibung, das Modell zu Aktionen bringen, die es nicht ausführen soll? Wir testen es.

Betriebsreife

Protokolle ohne personenbezogene Daten, Überwachung, Alarmierung, Rollback und eine benannte Person, die zuständig ist.

Vorgehen

Vom Code zur Go-live-Entscheidung.

Phase 01

Überblick und Bedrohungsmodell

Was tut die Anwendung, welche Daten berührt sie, wer könnte sie missbrauchen? Daraus entstehen ein Datenflussbild und die Liste der Prüfpunkte.

2–3 Tage
Phase 02

Prüfung

Durchsicht von Code und Konfiguration, automatisierte Scans und gezielte Tests für Rechte, Mandantentrennung und Eingabegrenzen.

1 Woche
Phase 03

Befunde und Korrektur

Jeder Befund kommt mit Schweregrad, Nachweis und konkretem Korrekturvorschlag. Auf Wunsch beheben wir die Punkte selbst.

1–3 Wochen
Phase 04

Nachprüfung und Freigabe

Kritische und hohe Befunde werden nachgetestet. Am Ende steht eine klare Aussage: bereit, bereit mit dokumentiertem Restrisiko oder noch nicht.

2–3 Tage

Ergebnisse

Was am Ende vorliegt.

Ein Audit findet nicht jede Lücke. Es senkt das Risiko auf ein bekanntes, dokumentiertes Maß. Sicherheit an Shops haben wir bereits gehärtet: Bei best-body-shop.de stieg das SSL-Rating von A auf A+ und der Observatory-Report von F auf B. Das war eine Shop-Optimierung und kein KI-Code-Audit, zeigt aber die Arbeitsweise.

Case Study: best-body-shop.de → SSL-Rating A → A+, Observatory F → B

1–2 Wo.

bis zur Befundliste

offene kritische Befunde als Go-live-Bedingung

Schweregrade mit klarer Priorität

Nachprüfung nach der Korrektur

Womit wir arbeiten.

OWASP Top 10
OWASP Top 10 für LLM-Anwendungen
Statische Codeanalyse
Dependency-Scans
Secret-Scanning
Manuelle Rechte-Tests
Mozilla Observatory
SSL Labs

FAQ

Häufige Fragen zu KI-Code-Audit.

Sie haben eine Frage, die hier nicht beantwortet wird?

Direkt sprechen

Ist KI-generierter Code unsicherer als handgeschriebener?

Nicht grundsätzlich. Er entsteht aber schneller, als er geprüft wird, und oft bei Personen, die sonst keine Software entwickeln. Die typischen Lücken sind bekannt: fehlende Rechteprüfung auf dem Server, Schlüssel im Code, ungeprüfte Pakete.

Was brauchen Sie von uns?

Zugriff auf das Repository, eine Testumgebung mit Beispieldaten und eine Person, die erklären kann, was die Anwendung tun soll. Produktivdaten brauchen wir für die Prüfung nicht.

Beheben Sie die Befunde auch?

Auf Wunsch ja. Viele Teams beheben einfache Punkte selbst und geben uns die strukturellen, etwa ein Rechtemodell oder die Trennung von Mandanten. Die Nachprüfung gehört in beiden Fällen dazu.

Prüfen Sie auch Shopify Apps und Themes?

Ja. Bei Apps achten wir zusätzlich auf die Verifizierung von Webhooks, den Umgang mit Zugriffstoken und die angeforderten Berechtigungen. Bei Themes auf eingebundene Skripte von Dritten.

Ist das ein Penetrationstest?

Nein. Ein Penetrationstest greift ein laufendes System von außen an. Unser Audit liest Code und Konfiguration und testet gezielt die Stellen, an denen schnell gebaute Anwendungen typischerweise Lücken haben. Für Systeme mit hohem Schutzbedarf empfehlen wir beides.

Was, wenn die Anwendung durchfällt?

Dann wissen Sie es vor Ihren Kunden. Sie bekommen eine Liste, was mindestens behoben sein muss, und eine Einschätzung, ob sich die Korrektur lohnt oder ein Neuaufbau der betroffenen Teile günstiger ist.

Passt dazu