OpenAnt

OpenAnt de Knostic est un produit open source de découverte de vulnérabilités basé sur LLM qui aide les défenseurs à trouver de manière proactive des failles de sécurité vérifiées, tout en minimisant à la fois les faux positifs et les faux négatifs. La phase 1 détecte. La phase 2 attaque. Ce qui survit est réel.

Nous sommes plutôt fiers de ce produit et sommes en cours de divulgation des vulnérabilités pour ses découvertes, mais gardez bien à l'esprit qu'il s'agissait au départ d'un projet de recherche et que certaines de ses fonctionnalités sont encore en version bêta. Nous accueillons volontiers les contributions pour l'améliorer.

Pourquoi l'open source ?

Compte tenu de l'explosion des vulnérabilités découvertes par l'IA, nous espérons qu'OpenAnt sera l'outil qui aidera les mainteneurs open source à garder une longueur d'avance sur les attaquants, en leur permettant de l'utiliser eux-mêmes ou de soumettre leur dépôt pour une analyse gratuite.

Ensuite, comme Knostic se concentre sur la protection des agents et des assistants de codage, et non sur la recherche de vulnérabilités ou la sécurité des applications, et que nous aimons l'open source, nous avons décidé de publier OpenAnt sous licence Apache 2. D'ailleurs, vous avez peut-être entendu parler d'Aardvark d'OpenAI (désormais Codex Security) et de Claude Code Security d'Anthropic, et nous n'avons aucune intention de leur faire concurrence.

Détails techniques et analyse gratuite pour les projets open source

Pour les détails techniques, les limitations et les coûts en tokens, consultez cet article de blog : https://knostic.ai/blog/openant

Pour soumettre votre dépôt à une analyse : https://knostic.ai/blog/oss-scan

Langages pris en charge

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

Crédits

Recherche et conception : Nahum Korda.

Productisation : Alex Raihelgaus, Daniel Geyshis.

Remerciements à : Michal Kamensky, Imri Goldberg, Gadi Evron, Daniel Cuthbert. Josh Grossman et Avi Douglen.

Découvrez Knostic

Si vous appréciez notre travail, découvrez ce que nous faisons chez Knostic pour défendre vos agents et assistants de codage, les empêcher de supprimer votre disque dur et votre code, et maîtriser les risques associés de la chaîne d'approvisionnement, tels que les serveurs MCP, les extensions et les skills.

Installation locale

Compilez le binaire CLI (nécessite Go 1.25+) :

cd apps/openant-cli && make build

Ceci compile le code source Go et génère le binaire dans apps/openant-cli/bin/openant.

Créez un lien symbolique vers votre PATH afin de pouvoir exécuter openant depuis n'importe où :

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

Remarque : exécutez cette commande depuis la racine du dépôt afin que $(pwd) corresponde au bon chemin absolu.

Configuration d'un LLM

OpenAnt achemine chaque phase du pipeline à travers une paire (fournisseur, modèle) configurable. Le chemin le plus rapide est l'assistant interactif :

openant setup llm

Vous nommez la configuration (par ex. my-llm), choisissez un fournisseur pour chaque phase du pipeline (anthropic, openai ou google), saisissez une clé API une fois par fournisseur, et l'assistant teste chaque paire fournisseur+modèle unique avec une requête d'un token avant d'écrire ~/.config/openant/config.json. Lancez une analyse avec --llm-config :

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

Les valeurs par défaut de l'assistant reflètent les recommandations du projet par phase (des modèles de raisonnement plus puissants pour la détection / la vérification / la revue d'atteignabilité ; des modèles plus légers pour la génération de contexte, de rapport et de tests) — modifiez n'importe quelle réponse à votre convenance.

Adaptateurs fournis

Les trois prennent en charge le tool calling, de sorte que chacun d'eux peut piloter les phases enhance et verify qui utilisent la boucle agentique d'utilisation d'outils.

Chemin rapide pour les configurations exclusivement Anthropic

Si vous voulez les valeurs par défaut Claude actuelles par phase et rien d'autre, ignorez l'assistant :

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

Ceci utilise la configuration intégrée openant-default (compilée dans le binaire, aucun config.json nécessaire) — Claude Opus 4.6 pour les phases de détection, Sonnet 4 pour le reste.

Configuration écrite à la main

L'assistant écrit ~/.config/openant/config.json pour vous, mais vous pouvez également le modifier directement. Chaque llm-config doit lister les sept phases du pipeline :

{
  "$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"}
    }
  }
}

Les fournisseurs acceptent un base_url personnalisé pour les proxys compatibles OpenAI / compatibles Anthropic (OpenRouter, vLLM, Bedrock, passerelles internes). La configuration openant-default (Claude pour toutes les phases) est intégrée et toujours disponible, quel que soit le contenu du fichier.

Ajout d'un nouvel adaptateur de fournisseur

La couche d'adaptateurs d'OpenAnt est une petite recette Python — un fichier Python implémentant le protocole LLMAdapter, une fabrique pour le harnais de tests de contrat, plus une entrée de registre — et cela suffit à lui seul pour exécuter l'adaptateur depuis une configuration écrite à la main. Pour qu'il soit également proposé par l'assistant openant setup llm et réussisse sa vérification préalable à l'enregistrement, ajoutez quelques points d'accroche Go dans apps/openant-cli/cmd/setup.go (la liste des fournisseurs pris en charge, un case de sonde, les cartes des modèles par défaut par phase) ainsi qu'une fonction de sonde Go. Les 12 tests de contrat s'exécutent automatiquement contre votre adaptateur une fois qu'il est câblé. Consultez docs/features/llm-providers/HOW_TO_ADD_AN_ADAPTER.md pour la recette complète.

Environnement d'exécution Python

Le code d'OpenAnt chargé du parsing, de l'enrichissement, de l'analyse et des rapports requiert Python 3.11+. La CLI Go choisit un interpréteur dans cet ordre :

1. La variable d'environnement OPENANT_PYTHON (définissez-la pour épingler un interpréteur spécifique — par ex. OPENANT_PYTHON=python3.11).
2. Le venv géré dans ~/.openant/venv/ (créé automatiquement à la première utilisation). La CLI utilise bin/python sous Linux/macOS et Scripts\python.exe sous Windows.
3. python3 / python dans le PATH.

Si aucun ne fournit Python 3.11+, la commande se termine avec une erreur renvoyant vers python.org. Pour reconstruire un venv géré obsolète (par ex. après une mise à niveau de Python), supprimez ~/.openant/venv/ et relancez n'importe quelle commande openant.

Répertoires de données

OpenAnt crée deux répertoires :

• ~/.config/openant/ — Configuration de la CLI (config.json). Stocke votre clé API, le projet actif et vos préférences. Les permissions des fichiers sont restreintes à 0600.
• ~/.openant/ — Données de projet. Chaque projet initialisé obtient un espace de travail sous ~/.openant/projects/<org>/<repo>/ contenant project.json et un répertoire scans/ avec les sorties par commit.

Analyse d'un projet

1. Initialiser

Pointez OpenAnt vers un dépôt. L'option -l (langage) est obligatoire — utilisez go ou 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>

Ceci crée un espace de travail pour le projet et le définit comme projet actif. Toutes les commandes suivantes opèrent automatiquement sur le projet actif — aucun argument de chemin n'est nécessaire.

2. Exécuter le pipeline

Chaque étape récupère la sortie de l'étape précédente depuis le répertoire de scans du projet :

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

Ou exécutez le pipeline complet en une seule commande :

openant scan --verify

Travailler avec plusieurs projets

Le pipeline opère sur un seul projet à la fois. Lancer openant init définit le projet nouvellement initialisé comme projet actif, de sorte que toutes les commandes suivantes le ciblent par défaut.

Si vous travaillez avec plusieurs projets, vous avez deux options :

# 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

Gestion des projets

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

Feuille de route

Ce qui figure sur la liste, sans ordre particulier :

• D'autres adaptateurs de fournisseurs. Ollama (modèles locaux), vLLM, Cohere, Mistral, Groq, Amazon Bedrock, Azure OpenAI — chacun est une petite recette d'adaptateur Python (plus quelques points d'accroche Go pour l'assistant/la sonde si vous souhaitez qu'il soit proposé par openant setup llm) conformément au guide du contributeur. Abaisser la barrière à l'inférence locale / sur site.
• Authentification par abonnement. Les abonnements ChatGPT / Codex, Claude Pro / Max et Gemini Advanced n'accordent actuellement aucun quota API — les utilisateurs doivent conserver une clé de niveau API distincte par fournisseur. Des adaptateurs basés sur OAuth qui s'appuieraient sur l'abonnement grand public combleraient cette lacune.
• Particularités d'appels d'outils selon les fournisseurs. Les trois adaptateurs fournis prennent en charge le tool calling, mais la longue traîne (appels d'outils parallèles, application des schémas en mode strict, sémantique de nouvelle tentative sur du JSON partiel) se comporte différemment selon le fournisseur. Les analyses sur des cas réels les font ressortir — les PR sont les bienvenues.
• Plus de langages. La liste des langages pris en charge ci-dessus constitue la couverture actuelle. Rust, Java, C# et Swift reviennent fréquemment.
• Service d'analyse hébergé. Knostic propose aujourd'hui des analyses gratuites pour les projets OSS via le formulaire lié ci-dessus ; une API en libre-service pour les partenaires de confiance est une possibilité future.

Les PR sont les bienvenues sur n'importe lequel de ces points — ouvrez d'abord une issue si le périmètre est conséquent, afin que nous puissions nous aligner avant que vous ne vous lanciez.

LICENCE

Ce projet est sous licence Apache 2. Consultez le fichier LICENSE pour plus de détails.

Avertissement et avis juridique

Ce projet est destiné exclusivement à des fins défensives et de recherche. OpenAnt est encore en phase de recherche ; utilisez-le avec précaution et à vos propres risques. Knostic, OpenAnt ainsi que les développeurs, chercheurs et mainteneurs associés déclinent toute responsabilité en cas d'utilisation abusive, de dommages ou de conséquences découlant de l'utilisation de cet outil.

Analysez uniquement du code que vous possédez ou pour lequel vous disposez d'une autorisation explicite de test. Si vous découvrez une vulnérabilité dans le projet de quelqu'un d'autre par des moyens légitimes, veuillez suivre les pratiques de divulgation coordonnée des vulnérabilités et la signaler aux mainteneurs avant de la rendre publique.