Warum wir jedes Release durch ein Gate schicken
KI generiert Software schneller, als irgendein Team sie reviewen kann. Unsere Antwort ist nicht, weniger zu reviewen — sondern die Review automatisch zu machen. Und zu einem Gate.
Die unbequeme Wahrheit über KI-generierten Code: Das Volumen überholt die Kontrolle. Wenn ein System ein funktionierendes Feature in Minuten produziert, wandert der Engpass zu der Frage, die niemand demonstriert: Ist das sicher und gut genug zum Ausliefern? XAIOs Haltung: Diese Frage darf nie davon abhängen, ob jemand daran denkt, sie zu stellen.
Vier Gates, eine Pipeline
Jeder Publish durchläuft dieselbe Sequenz — über einen eingefrorenen Stand von exakt dem Code, der live gehen würde: Tests, Sicherheitsanalyse, Code-Qualität und eine Prüfung der API-Oberfläche. Tests, Sicherheit und Code-Qualität sind bei jedem Projekt standardmäßig aktiv; Deep Quality (eine vollständige SonarQube-Analyse) und API-Linting lassen sich pro Projekt dazuschalten. Hier ist, was jedes Gate tut — und warum es existiert.
Gate 1: Tests gegen einen eingefrorenen Stand
Die generierte Test-Suite — Vitest fürs Frontend, pytest fürs Backend — läuft in einer isolierten Build-Umgebung mit eigener, frischer Testdatenbank. Sie läuft gegen einen eingefrorenen Stand des Releases: Die getesteten Bytes sind exakt die Bytes, die ausgeliefert werden. Du kannst im Workspace weiterarbeiten, während das Release läuft — nichts davon sickert in die Prüfung. Echte Testfehler blockieren den Publish.
Warum es das gibt: Eine Test-Suite, die „manchmal" läuft oder gegen ein bewegliches Ziel, beweist nichts. Erst der eingefrorene Stand macht aus Tests einen Nachweis statt eines Rituals.
Gate 2: Sicherheitsanalyse über den Auslieferungs-Code
Zwei Scanner schauen aus verschiedenen Blickwinkeln auf das Release:
- Semgrep mit einem von XAIO kuratierten Regelwerk: SQL-Injection, unsichere Deserialisierung, JWT- und TLS-Fehlkonfiguration, Wildcard-CORS, vergessener Debug-Modus, gefährliche HTML-Injection, hartkodierte Credentials.
- Trivy: bekannte CVEs in Dependencies, Secret-Scanning (inklusive eigener Muster für Key-Formate) und Infrastruktur-Fehlkonfigurationen.
Ein Policy-Detail ist hier wichtig: Das Gate blockiert nur bei behebbaren CVEs. Eine Schwachstelle, für die es noch keinen Fix gibt, darf dein Release nicht auf unbestimmte Zeit festhalten — sie wird deutlich angezeigt, nimmt den Publish aber nicht als Geisel.
Wer weiter gehen will, schaltet den optionalen Dynamik-Scan dazu (OWASP ZAP): Er prüft eine Wegwerf-Kopie der laufenden App von außen — Security-Header, Cookie-Flags, CORS, Informationslecks — inklusive eingeloggter Seiten, wenn die Testing-Integration aktiv ist. Seine Findings sind Hinweise und landen in derselben Problems-Ansicht.
Gate 3: Code-Qualität — bis hin zur vollen SonarQube-Analyse
Ruff prüft das Python-Backend: Lücken in der Fehlerbehandlung, Async-Fallen, naive Datumswerte, Performance-Fallen und ein Sicherheits-Regelwerk. Biome prüft das TypeScript/React-Frontend. Projekte mit der Deep-Quality-Integration bekommen beim Publish zusätzlich eine vollständige SonarQube-Analyse: Bugs, Vulnerabilities, Code Smells und Duplikate — auf exakt den Quellen, die ausgeliefert werden.
Warum es das gibt: Qualitätsprobleme lassen selten die Demo platzen — sie schlagen in Monat sechs zu. Wer sie bei jedem Release sichtbar macht, hält die Codebasis wartbar, während sie wächst.
Gate 4: Die API-Oberfläche
Die generierte OpenAPI-Spezifikation wird gelintet (Spectral, erweitert um API-Security-Regeln). Und das Open-Endpoints-Gate listet jede Backend-Route auf, die ohne Authentifizierung erreichbar ist — der Publish pausiert, bis du diese Liste bestätigst. Routen, die bewusst öffentlich sind, werden im Code deklariert, mit verpflichtender Begründung: Die Entscheidung ist nachvollziehbar statt stillschweigend.
Warum es das gibt: Das häufigste reale Datenleck ist kein exotischer Exploit — es ist ein Endpunkt, der nie öffentlich sein sollte. Dieses Gate macht „öffentlich" zu einer expliziten Entscheidung, bei jedem Release.
Warum manche Findings blockieren und andere nur warnen
Nicht alles stoppt das Release — und das ist Absicht. Blockiert wird bei Findings mit hoher Trefferquote und hohem Schaden: Injection-Risiken, offengelegte Secrets, TLS/JWT-Fehlkonfiguration, Debug-Modus, Wildcard-CORS, behebbare CVEs, fehlschlagende Tests, unbestätigte offene Endpunkte. Verrauschtere Kategorien — Stil, Wartbarkeit, die meisten Fehlkonfigurationen — erscheinen als Hinweise.
Der Grund ist menschlich, nicht technisch: Ein Gate, das ständig falschen Alarm schlägt, wird abgeschaltet — und ein abgeschaltetes Gate schützt niemanden. Und ein Infrastrukturfehler in einem Scanner blockiert nie ein Release — nur echte Findings tun das.
Was bei fehlgeschlagenen Checks passiert
Ein fehlgeschlagenes Gate blockiert den Publish — genau das ist der Zweck. Findings erscheinen in der Deployment-Ansicht, der vollständige Report ist einen Klick entfernt, und die meisten kommen mit einem Ein-Klick-Fix: XAIO schlägt die Änderung vor, wendet sie an und lässt die Checks erneut laufen. Jeder Publish-Versuch bekommt eine eigene Versionsnummer — fehlgeschlagene Versuche sind klar von dem getrennt, was wirklich live ist.
Das Ergebnis ist eine Eigenschaft, die Prototyping-first-Tools nicht bieten können: nicht, weil ihre Modelle schlechter wären, sondern weil in ihrer Pipeline nichts Nein sagen darf. Eine Qualitätslatte existiert nur, wenn etwas sie durchsetzt.