OpenAnt

OpenAnt von Knostic ist ein LLM-basiertes Open-Source-Produkt zur Schwachstellenentdeckung, das Verteidigern hilft, verifizierte Sicherheitslücken proaktiv zu finden und dabei sowohl False Positives als auch False Negatives zu minimieren. Stufe 1 erkennt. Stufe 2 greift an. Was überlebt, ist real.

Wir sind ziemlich stolz auf dieses Produkt und befinden uns für seine Ergebnisse im Vulnerability-Disclosure-Prozess. Bedenken Sie jedoch, dass dies als Forschungsprojekt begann und einige seiner Funktionen sich noch in der Beta-Phase befinden. Wir freuen uns über Beiträge, um es zu verbessern.

Warum Open Source?

Angesichts der Explosion KI-entdeckter Schwachstellen hoffen wir, dass OpenAnt das Werkzeug sein wird, das Open-Source-Maintainern hilft, Angreifern einen Schritt voraus zu sein, wobei sie es selbst nutzen oder ihr Repository kostenlos zum Scannen einreichen können.

Da Knostics Fokus auf dem Schutz von Agenten und Code-Assistenten liegt und nicht auf Schwachstellenforschung oder Anwendungssicherheit, und da wir Open Source mögen, haben wir uns entschieden, OpenAnt unter der Apache-2-Lizenz zu veröffentlichen. Außerdem haben Sie vielleicht von Aardvark von OpenAI (jetzt Codex Security) und Claude Code Security von Anthropic gehört, und wir haben keinerlei Absicht, mit ihnen zu konkurrieren.

Technische Details und kostenloses Scannen für Open-Source-Projekte

Technische Details, Einschränkungen und Token-Kosten finden Sie in diesem Blogbeitrag: https://knostic.ai/blog/openant

Um Ihr Repository zum Scannen einzureichen: https://knostic.ai/blog/oss-scan

Unterstützte Sprachen

• Go
• Python
• JavaScript/TypeScript (beta)
• C/C++ (beta)
• PHP (beta)
• Ruby (beta)
• Zig (beta)
• Swift (beta)

Danksagungen

Forschung und Ideenfindung: Nahum Korda.

Produktentwicklung: Alex Raihelgaus, Daniel Geyshis.

Mit Dank an: Michal Kamensky, Imri Goldberg, Gadi Evron, Daniel Cuthbert. Josh Grossman und Avi Douglen.

Schauen Sie sich Knostic an

Wenn Ihnen unsere Arbeit gefällt, schauen Sie sich an, was wir bei Knostic tun, um Ihre Agenten und Code-Assistenten zu schützen, sie daran zu hindern, Ihre Festplatte und Ihren Code zu löschen, und die damit verbundenen Lieferkettenrisiken wie MCP-Server, Erweiterungen und Skills zu kontrollieren.

Lokale Einrichtung

Bauen Sie die CLI-Binary (erfordert Go 1.25+):

cd apps/openant-cli && make build

Dies kompiliert den Go-Quellcode und gibt die Binary nach apps/openant-cli/bin/openant aus.

Verknüpfen Sie es per Symlink mit Ihrem PATH, damit Sie openant von überall aus ausführen können:

ln -sf "$(pwd)/apps/openant-cli/bin/openant" /usr/local/bin/openant

Hinweis: Führen Sie dies vom Repository-Stammverzeichnis aus, damit $(pwd) zum korrekten absoluten Pfad aufgelöst wird.

Ein LLM einrichten

OpenAnt leitet jede Pipeline-Phase über ein konfigurierbares (Provider, Modell)-Paar. Der schnellste Weg ist der interaktive Assistent:

openant setup llm

Sie geben der Konfiguration einen Namen (z. B. my-llm), wählen pro Pipeline-Phase einen Provider (anthropic, openai oder google) aus, geben pro Provider einmal einen API-Schlüssel ein, und der Assistent testet jedes eindeutige Provider+Modell-Paar mit einer 1-Token-Anfrage, bevor er ~/.config/openant/config.json schreibt. Führen Sie anschließend einen Scan mit --llm-config aus:

openant scan /path/to/repo --llm-config my-llm

Die Standardwerte des Assistenten spiegeln die phasenbezogenen Empfehlungen des Projekts wider (stärkere Reasoning-Modelle für Erkennung / Verifizierung / Erreichbarkeitsprüfung; leichtere Modelle für Kontext-, Berichts- und Testgenerierung) — jede Antwort kann nach Belieben überschrieben werden.

Mitgelieferte Adapter

Alle drei unterstützen Tool Calling, sodass jedes von ihnen die enhance- und verify-Phasen steuern kann, die die agentische Tool-Use-Schleife nutzen.

Schneller Weg für reine-Anthropic-Setups

Wenn Sie die aktuellen phasenbezogenen Claude-Standardwerte und sonst nichts möchten, überspringen Sie den Assistenten:

openant set-api-key sk-ant-...
openant scan /path/to/repo

Dies verwendet die integrierte openant-default-Konfiguration (in die Binary kompiliert, kein config.json erforderlich) — Claude Opus 4.6 für Erkennungsphasen, Sonnet 4 für den Rest.

Manuell erstellte Konfiguration

Der Assistent schreibt ~/.config/openant/config.json für Sie, aber Sie können es auch direkt bearbeiten. Jede LLM-Konfiguration muss alle sieben Pipeline-Phasen auflisten:

{
  "$schema_version": 2,
  "default_llm": "my-llm",
  "llm_providers": {
    "anthropic": {"type": "anthropic", "api_key": "sk-ant-..."},
    "openai":    {"type": "openai",    "api_key": "sk-proj-..."},
    "google":    {"type": "google",    "api_key": "AIza..."}
  },
  "llm_configs": {
    "my-llm": {
      "app_context":  {"provider": "openai",    "model": "gpt-4o-mini"},
      "llm_reach":    {"provider": "anthropic", "model": "claude-opus-4-6"},
      "enhance":      {"provider": "openai",    "model": "gpt-4o-mini"},
      "analyze":      {"provider": "anthropic", "model": "claude-opus-4-6"},
      "verify":       {"provider": "anthropic", "model": "claude-opus-4-6"},
      "dynamic_test": {"provider": "google",    "model": "gemini-2.0-flash"},
      "report":       {"provider": "google",    "model": "gemini-2.0-flash"}
    }
  }
}

Provider akzeptieren eine benutzerdefinierte base_url für OpenAI-kompatible / Anthropic-kompatible Proxys (OpenRouter, vLLM, Bedrock, interne Gateways). Die openant-default-Konfiguration (Claude in allen Phasen) ist integriert und unabhängig vom Dateiinhalt immer verfügbar.

Hinzufügen eines neuen Provider-Adapters

Die Adapterschicht von OpenAnt ist ein kleines Python-Rezept — eine Python-Datei, die das LLMAdapter-Protokoll implementiert, eine Factory für die Vertragstest-Umgebung sowie einen Registry-Eintrag — und das allein reicht aus, um den Adapter aus einer manuell erstellten Konfiguration auszuführen. Damit es auch vom openant setup llm-Assistenten angeboten wird und dessen Probe vor dem Speichern besteht, fügen Sie einige Go-Berührungspunkte in apps/openant-cli/cmd/setup.go hinzu (die Liste der unterstützten Provider, einen Probe-case, die phasenbezogenen Standardmodell-Zuordnungen) sowie eine Go-Probe-Funktion. Die 12 Vertragstests laufen automatisch gegen Ihren Adapter, sobald er angebunden ist. Das vollständige Rezept finden Sie in docs/features/llm-providers/HOW_TO_ADD_AN_ADAPTER.md.

Python-Laufzeitumgebung

Der Parsing-, Enhancement-, Analyse- und Berichtscode von OpenAnt erfordert Python 3.11+. Die Go-CLI wählt einen Interpreter in dieser Reihenfolge aus:

1. OPENANT_PYTHON-Umgebungsvariable (setzen Sie diese, um einen bestimmten Interpreter festzulegen — z. B. OPENANT_PYTHON=python3.11).
2. Verwaltete venv unter ~/.openant/venv/ (bei erster Verwendung automatisch erstellt). Die CLI verwendet bin/python unter Linux/macOS und Scripts\python.exe unter Windows.
3. python3 / python im PATH.

Wenn keiner davon Python 3.11+ liefert, beendet sich der Befehl mit einem Fehler, der auf python.org verweist. Um eine veraltete verwaltete venv neu aufzubauen (z. B. nach einem Python-Upgrade), löschen Sie ~/.openant/venv/ und führen Sie einen beliebigen openant-Befehl erneut aus.

Datenverzeichnisse

OpenAnt erstellt zwei Verzeichnisse:

• ~/.config/openant/ — CLI-Konfiguration (config.json). Speichert Ihren API-Schlüssel, das aktive Projekt und Ihre Einstellungen. Dateiberechtigungen sind auf 0600 beschränkt.
• ~/.openant/ — Projektdaten. Jedes initialisierte Projekt erhält einen Arbeitsbereich unter ~/.openant/projects/<org>/<repo>/, der project.json und ein scans/-Verzeichnis mit Ausgaben pro Commit enthält.

Analysieren eines Projekts

1. Initialisieren

Richten Sie OpenAnt auf ein Repository aus. Das -l-Flag (Sprache) ist erforderlich — verwenden Sie go oder python.

# Remote — clones the repo
openant init <repo-url> -l go

# Remote — pin to a specific commit
openant init <repo-url> -l go --commit <sha>

# Local — references the directory in-place
openant init <path-to-repo> -l go --name <org/repo>

Dies erstellt einen Projektarbeitsbereich und legt ihn als aktives Projekt fest. Alle nachfolgenden Befehle arbeiten automatisch mit dem aktiven Projekt — Pfadargumente sind nicht erforderlich.

2. Pipeline ausführen

Jeder Schritt übernimmt die Ausgabe des vorherigen aus dem Scan-Verzeichnis des Projekts:

openant parse
openant enhance
openant analyze
openant verify
openant build-output
openant report -f summary

Oder führen Sie die gesamte Pipeline mit einem Befehl aus:

openant scan --verify

Arbeiten mit mehreren Projekten

Die Pipeline arbeitet jeweils an einem Projekt. Durch die Ausführung von openant init wird das neu initialisierte Projekt zum aktiven Projekt, sodass alle nachfolgenden Befehle standardmäßig darauf abzielen.

Wenn Sie mit mehreren Projekten arbeiten, haben Sie zwei Optionen:

# Option 1: switch the active project
openant project switch org/repo
openant parse

# Option 2: target a project directly with -p
openant parse -p org/repo

Projektverwaltung

openant project list              # shows all projects, marks active
openant project show              # details of active project
openant project switch <org/repo> # switch active project

Roadmap

Punkte auf der Liste, in keiner bestimmten Reihenfolge:

• Weitere Provider-Adapter. Ollama (lokale Modelle), vLLM, Cohere, Mistral, Groq, Amazon Bedrock, Azure OpenAI — jeder davon ist ein kleines Python-Adapterrezept (plus einiger Go-Berührungspunkte für Assistent/Probe, falls es von openant setup llm angeboten werden soll), wie im Beitragsleitfaden beschrieben. Senken Sie die Hürde für lokale / On-Premises-Inferenz.
• Abonnementbasierte Authentifizierung. ChatGPT-/Codex-, Claude-Pro-/Max- und Gemini-Advanced-Abonnements gewähren derzeit kein API-Kontingent — Benutzer müssen pro Provider einen separaten API-Schlüssel pflegen. OAuth-basierte Adapter, die das Verbraucherabonnement nutzen, würden diese Lücke schließen.
• Tool-Call-Eigenheiten über Provider hinweg. Alle drei mitgelieferten Adapter unterstützen Tool Calling, aber der Long Tail (parallele Tool-Aufrufe, strikte Schema-Durchsetzung im Strict Mode, Retry-Semantik bei teilweisem JSON) verhält sich pro Provider unterschiedlich. Praxisnahe Scans bringen diese zum Vorschein — PRs willkommen.
• Weitere Sprachen. Die obige Liste der unterstützten Sprachen ist die aktuelle Abdeckung. Rust, Java, C# und Swift werden häufig genannt.
• Gehosteter Scan-Dienst. Knostic bietet heute kostenlose Scans für OSS-Projekte über das oben verlinkte Formular an; eine Self-Service-API für vertrauenswürdige Partner ist eine zukünftige Möglichkeit.

PRs zu jedem dieser Punkte sind willkommen — öffnen Sie zuerst ein Issue, wenn der Umfang nicht trivial ist, damit wir uns abstimmen können, bevor Sie etwas bauen.

Lizenz

Dieses Projekt ist unter Apache 2 lizenziert. Details finden Sie in der LICENSE-Datei.

Haftungsausschluss und rechtlicher Hinweis

Dieses Projekt ist ausschließlich für Verteidigungs- und Forschungszwecke bestimmt. OpenAnt befindet sich noch in der Forschungsphase; verwenden Sie es sorgfältig und auf eigenes Risiko. Knostic, OpenAnt und die zugehörigen Entwickler, Forscher und Maintainer übernehmen keinerlei Verantwortung für Missbrauch, Schäden oder Folgen, die aus der Nutzung dieses Tools entstehen.

Scannen Sie nur Code, den Sie besitzen oder für dessen Test Sie eine ausdrückliche Genehmigung haben. Wenn Sie auf legitime Weise eine Schwachstelle im Projekt einer anderen Person entdecken, befolgen Sie bitte die Praktiken der koordinierten Offenlegung von Schwachstellen (Coordinated Vulnerability Disclosure) und melden Sie diese den Maintainern, bevor Sie sie öffentlich machen.