vibegate

Hier ist alles, was VibeGate derzeit überprüft:

Die vollständige, aktuelle Liste befindet sich in guidance.TECHNICAL_RISKS und formatter.BLOCKING_CATEGORIES, falls diese Tabelle jemals abweicht.

Was passiert, wenn Sie es aktivieren?

Kurz gesagt: Sicherer Code passiert unberührt, riskanter aber überlebensfähiger Code wird mit einer Warnung gespeichert, und Code, der nur einen Schritt von SQL-Injection, Befehlseinschleusung oder Remote-Code-Ausführung entfernt ist, wird gestoppt, bevor er die Festplatte erreicht.

Wenn VibeGate selbst auf einen unerwarteten Fehler stößt, lässt es den Schreibvorgang immer durch – ein Fehler im Hook sollte niemals der Grund dafür sein, dass Ihre Arbeit blockiert wird.

Jede Warnung und jeder Block enthält auch eine explizite Anweisung an Claude Code, den Fund in seiner Antwort zu erwähnen, nicht nur stillschweigend zu beheben. Dadurch wird die Aktivität von VibeGate im Gespräch sichtbar, nicht nur in einem Terminalprotokoll, das Sie erst suchen müssten.

Die vollständige, pro Prüfung aufgeschlüsselte Liste dessen, was blockiert vs. nur warnt, finden Sie in der Tabelle unter "Welches Problem wird gelöst?" oben.

Derzeit versteht VibeGate Python, JavaScript/TypeScript, Go, Java, PHP und Ruby und bindet sich in Claude Code und Codex ein. Weitere Sprachen und Tools können hinzugefügt werden, ohne die Kernlogik zu berühren.

Es überprüft auch GitHub Actions-Workflow-Dateien auf zwei häufige CI/CD- Lieferkettenfehler: Aktionen, die auf einen veränderlichen Tag (@v4) anstatt auf einen Commit-SHA fixiert sind, und den unsicheren pull_request_target-Trigger. Beides verursacht Warnungen, keine Blockaden, da es sich um Härtungsprüfungen handelt und nicht um den Nachweis eines aktiven Exploits.

In Aktion sehen

Hier ist eine echte Aufnahme von Claude Code, das eine RSS-Feed-Reader-App von Grund auf erstellt, während VibeGate die ganze Zeit läuft. Achten Sie auf die Momente, in denen Claude Code anhält und explizit sagt, was VibeGate markiert hat und warum, bevor es fortfährt – einschließlich eines echten SSRF-Risikos im Feed-Abruf-Code, das es sofort behebt.

Hier ist ein zweites Beispiel als Standbild: Claude Code erstellt eine App, mit der Benutzer ein Foto hochladen und seine Details anzeigen können. VibeGate bemerkt, dass der Dateiname und andere Dateidetails später auf dem Bildschirm angezeigt werden, und warnt, dass dies zur Einschleusung schädlichen Codes in die Seite verwendet werden könnte (dies wird XSS genannt). Claude Code passt den Code an, sodass Informationen sicher angezeigt werden.

In beiden Fällen wurde nichts grundlos blockiert, und niemand musste den Code Zeile für Zeile durchgehen, um das Problem zu finden. VibeGate hat es im Moment des Dateischreibens erwischt, und die KI hat es sofort behoben.

Warum ein Gate weniger Tokens verbraucht als das Laden eines Skills

Es gibt zwei Möglichkeiten, einen KI-Assistenten dazu zu bringen, sichereren Code zu schreiben. Eine Möglichkeit besteht darin, vor dem Start einen großen Satz von Anweisungen zur sicheren Programmierung in das Gespräch zu laden, zum Beispiel eine Checkliste, die SQL-Injection, XSS, Passwort-Handling, Datei-Uploads und mehr abdeckt. Die andere Möglichkeit ist das, was VibeGate tut: den Code automatisch prüfen, genau dann, wenn eine Datei geschrieben wird, und nur dann etwas sagen, wenn tatsächlich etwas falsch ist.

Der erste Ansatz kostet Tokens für jede einzelne Nachricht, ob benötigt oder nicht. Eine typische Checkliste zur sicheren Programmierung, die mehrere Risikokategorien abdeckt, kann leicht einige tausend Tokens hinzufügen. Wenn ein KI-Assistent in einer Sitzung 50 Dateien schreibt und diese Checkliste jedes Mal neu geladen oder im Kontext behalten wird, zahlen Sie möglicherweise für weit über hunderttausend Tokens an Ratschlägen, die meistens nicht auf die gerade geschriebene Datei zutreffen. Eine Login-Seite und eine einfache Datei mit Farbkonstanten benötigen nicht die gleichen Warnungen, aber eine geladene Checkliste kann sie im Voraus nicht unterscheiden.

VibeGate dreht dies um. Es bleibt stumm und kostet nichts extra für jede Datei, die kein riskantes Muster enthält. Nur wenn es etwas findet, wie Benutzereingaben, die in eine Datenbankabfrage fließen, fügt es eine kurze, spezifische Notiz zu diesem einen Problem hinzu, meist ein kleiner Bruchteil der Größe einer vollständigen Checkliste. Anstatt also für jede Datei unabhängig vom Inhalt einen festen Token-Preis zu zahlen, zahlen Sie einen kleinen Preis nur für die Dateien, die tatsächlich Aufmerksamkeit benötigen, und dieser Preis zielt genau auf das gefundene Problem ab, nicht auf eine allgemeine Sicherheitsvorlesung.

Dies macht die Anleitung auch zuverlässiger. Ein KI-Assistent, der beim Schreiben von hundert Zeilen Code gebeten wird, "Sicherheit im Hinterkopf zu behalten", kann eine riskante Zeile unter vielen einfach übersehen. Ein Gate wird nicht müde oder abgelenkt: Es prüft jedes einzelne Schreiben, jedes Mal, unter Verwendung derselben festgelegten Regeln.

Erste Schritte

Einmal installieren – dies installiert auch Semgrep, auf das VibeGate angewiesen ist:

Dann aktivieren Sie es in dem Projekt, das Sie schützen möchten:

vibegate on fügt einen PreToolUse-Hook für Write|Edit|MultiEdit zur .claude/settings.local.json dieses Projekts hinzu. Es ist projektbezogen, daher beeinflusst das Aktivieren in einem Repository keine anderen.

Claude Code führt den Hook als vibegate run --host claude_code aus – keine absoluten Pfade, daher funktioniert es auch nach einer Neuinstallation oder Verschiebung.

vibegate status zeigt auch ein laufendes Protokoll dessen, was VibeGate in diesem Projekt tatsächlich abgefangen hat – jede Warnung und jeden Block mit Datei, Zeile und Kategorie –, sodass Sie seine Aktivität im Zeitverlauf sehen können, nicht nur, ob es eingeschaltet ist:

Dieses Protokoll befindet sich unter .vibegate/activity.jsonl im Projektstamm – fügen Sie es Ihrer .gitignore hinzu, es ist lokaler Entwicklerstatus, kein Einchecken.

VibeGate ermittelt, mit welchem Host es spricht, in dieser Reihenfolge: ein explizites --host <name>-Flag, dann die Umgebungsvariable VIBEGATE_HOST, dann automatische Erkennung aus der eingehenden Nutzlast, mit Fallback auf claude_code.

Unterdrücken eines Fundes

Wenn VibeGate etwas markiert, das Sie bewusst als sicher entschieden haben, fügen Sie einen Kommentar vibegate-ignore in derselben Zeile hinzu – es funktioniert mit jeder Kommentarsyntax (#, //, …), da VibeGate nur nach dem Text sucht:

Um nur bestimmte Kategorien zu unterdrücken, anstatt alles in dieser Zeile, listen Sie sie nach einem Doppelpunkt auf (stimmt entweder mit der technischen Kategorie oder dem semantischen Typ überein, durch Kommas getrennt, Groß-/Kleinschreibung egal):

Wie der Code organisiert ist

Die Pipeline selbst (core.py) kommuniziert nie direkt mit einem bestimmten Host – die gesamte host-spezifische Ein-/Ausgabe befindet sich in adapters/, sodass das Hinzufügen eines neuen Hosts keine Änderungen an der Analyselogik erfordert.

Tests ausführen

Um den gesamten Ablauf ohne Claude Code zu sehen:

VibeGate erweitern

• Eine Sprache hinzufügen – rules/<lang>-user-input.yaml hinzufügen, die neuen Regel-IDs in classifier.RULE_TO_TECHNICAL registrieren und die Dateierweiterung in core.EXT_TO_LANGUAGE zuordnen.
• Einen neuen zu erkennenden Datentyp hinzufügen – ein Schlüsselwort zu classifier.VARNAME_TO_SEMANTIC und eine Beschreibung in guidance.SEMANTIC_GUIDANCE hinzufügen.
• Eine neue zu erkennende Senke hinzufügen (z. B. eine neue Art, wie Daten missbraucht werden können) – eine Semgrep-Regel, einen Eintrag in RULE_TO_TECHNICAL und eine Karte in guidance.TECHNICAL_RISKS hinzufügen.
• Ein neues Host-Tool hinzufügen – einen Adapter unter adapters/ hinzufügen und in adapters/__init__.py registrieren.

Wissenswertes

• Der codex-Adapter ist eine frühe, bestmögliche Zuordnung. Überprüfen Sie seinen Ereignisvertrag mit Ihrer Codex-Version, bevor Sie sich darauf verlassen, dass er etwas blockiert.
• Das kostenlose Semgrep-Tarif gibt "requires login" anstelle der tatsächlich übereinstimmenden Zeile zurück, daher rekonstruiert der Klassifikator den Ausschnitt selbst aus dem Dateiinhalt anhand der Zeilennummern.
• Bei Edit/MultiEdit rekonstruiert der claude_code-Adapter die vollständige Datei nach der Bearbeitung von der Festplatte, sodass eine verunreinigte Quelle und eine Senke, die durch getrennte Bearbeitungen eingeführt wurden, dennoch verbunden sind – aber es werden nur Funde auf den Zeilen gemeldet, die die Bearbeitung tatsächlich berührt hat. Wenn eine Senke bereits existiert und eine spätere Bearbeitung nur die verunreinigte Quelle hinzufügt, die sie erreicht, wird dies nicht erfasst (die Zeile der Senke war nicht Teil der neuen Bearbeitung). Diese Rekonstruktion ist Claude-Code- spezifisch; der codex-Adapter macht dies noch nicht.