KI kann Code entwerfen. Sie kann kein Release freigeben.

Schnellere Entwicklung senkt nicht den Standard

KI verändert, wie schnell Code entstehen kann. Sie verändert nicht, welche Anforderungen erfüllt sein müssen, bevor dieser Code Kunden erreicht.

Wir gehen davon aus, dass generierter Code plausibel aussehen und trotzdem falsch sein kann. Unsere Kontrollen richten sich deshalb nach beobachtbaren Fehlerquellen und nicht nach dem Vertrauen in ein Modell.

Womit wir bei generiertem Code rechnen

Das sind keine theoretischen Sonderfälle. Es sind vorhersehbare Probleme, auf deren Erkennung unser Review- und Release-Prozess ausgelegt ist.

• Erfundene oder unsichere Abhängigkeiten: Erfundene Pakete, aufgegebene Projekte, verwundbare Releases oder ungeprüfte Änderungen am Abhängigkeitsgraphen.
• Code, der kompiliert, aber nicht funktioniert: Code kann lokale Prüfungen bestehen und trotzdem beim Build, bei der Integration oder unter realer Last versagen.
• Toter Code, der nie eingebunden wird: Eine Funktion oder Komponente kann vollständig aussehen, ohne jemals mit dem restlichen Produkt verbunden zu sein.
• Architekturverletzungen: Eine kleine Änderung kann etablierte Service-Grenzen umgehen und Abhängigkeiten schaffen, die später nur teuer rückgängig zu machen sind.
• Abweichungen bei API und OpenAPI-Spezifikation: Ein Endpunkt kann sich ändern, ohne dass veröffentlichter Vertrag, Dokumentation und Laufzeit gemeinsam aktualisiert werden.
• Ungetestete kritische Pfade: Authentifizierung, Autorisierung, Abrechnung, Audit-Logging und Datenexport brauchen Tests, die jede wesentliche Änderung abdecken.

Keine Änderung wird allein auf Vertrauen veröffentlicht

Jeder Commit und jeder Pull Request durchläuft dieselbe Pipeline. Eine Änderung erreicht die Produktion erst, wenn jede Prüfung bestanden ist.

• Statische Analyse: Änderungen an Go und Svelte müssen die Linting- und Formatierungsregeln des Projekts bestehen. Neue Verstöße stoppen den Build.
• Architektur-Wächter: Eigene Wächter verhindern, dass Code Paketgrenzen überschreitet oder HTTP-Handler direkt auf die Datenbank zugreifen. Neue Verstöße stoppen die Änderung.
• Analyse auf toten Code: Jeder Pull Request wird auf ungenutzte Funktionen geprüft. So wird Code erkannt, der hinzugefügt, aber nie in das Produkt eingebunden wurde.
• Schwachstellen-Scanning: Der gesamte Go-Abhängigkeitsgraph wird bei jedem Push geprüft. Bekannte verwundbare Pakete blockieren das Release.
• Integrität der Lieferkette: Frontend-Installationen verwenden eine committete Lockfile und prüfen Paketsignaturen. Workflow-Aktionen von Drittanbietern sind an konkrete Commits statt beweglicher Tags gebunden.
• Durchsetzung des OpenAPI-Vertrags: Die erzeugte OpenAPI-Spezifikation muss gültig bleiben. Vertragstests bestätigen, dass die laufende API mit ihr übereinstimmt. Abweichungen stoppen den Build.
• Frontend-Tests und Coverage: Unit- und Komponententests des Frontends laufen bei jedem Pull Request. Änderungen an der Testabdeckung sind beim Review sichtbar.
• Bericht zur Bundle-Größe: Jeder Pull Request berichtet die komprimierte Bundle-Größe. Unerwartet schwere Abhängigkeiten werden so vor dem Release sichtbar.
• Produktions-Build und Multi-Architektur-Image: Produktions-Build und Container-Image werden für linux/amd64 und linux/arm64 validiert. Jede veröffentlichte Architektur muss bestehen.
• Signierte Image-Herkunft: Veröffentlichte Container-Images enthalten signierte Attestierungen, die das Image mit dem erzeugenden Workflow und Quellcode-Commit verbinden.
• Scratch-Basis-Image: Der veröffentlichte Container hat kein Basisbetriebssystem, keine Shell und keinen Paketmanager. Er enthält nur das Windshift-Binary und die erforderlichen Zertifikate.

Unabhängige Tests über unsere Pipeline hinaus

Automatisierte Kontrollen und interne Reviews reichen allein nicht aus. Windshift wird zusätzlich von einer unabhängigen kommerziellen Sicherheitsfirma getestet.

Fragen dazu, wie wir KI einsetzen, oder möchten Sie eine Zusammenfassung des aktuellen Pentests? Schreiben Sie an security@windshift.sh.

• Jährlicher Penetrationstest durch eine externe kommerzielle Sicherheitsfirma.
• Der Umfang umfasst Authentifizierung, Autorisierung, Mandantentrennung, die öffentliche API-Oberfläche und die standardmäßige selbst gehostete Deployment-Konfiguration.
• Befunde werden bis zur Behebung verfolgt. Kritische Befunde blockieren das nächste Release.
• Eine Zusammenfassung des jüngsten Tests steht Enterprise-Kunden unter NDA zur Verfügung.