OpenAnt de Knostic est le principal produit open source de découverte de vulnérabilités basé sur LLM, aidant les défenseurs à détecter 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. L'étape 1 détecte. L'étape 2 attaque. Ce qui survit est réel.
OpenAnt de Knostic est le premier produit open source de découverte de vulnérabilités basé sur un LLM (aujourd'hui appelé un harness) qui aide les défenseurs à trouver proactivement des failles de sécurité vérifiées tout en minimisant à la fois les faux positifs et les faux négatifs. L'étape 1 détecte. L'étape 2 attaque. Ce qui survit est réel.
Gardez à l'esprit que ce projet a débuté comme un projet de recherche, et à mesure que nous développons de nouvelles capacités, nous les publions souvent en version bêta. Les contributions sont les bienvenues.
Vous pouvez trouver notre article de recherche sur la construction d'OpenAnt sur arXiv : OpenAnt: LLM-Powered Vulnerability Discovery Through Code Decomposition, Adversarial Verification, and Dynamic Testing, par Nahum Korda et Gadi Evron.
C'était une question pertinente dans le readme lors de notre première publication d'OpenAnt, puisque de nombreux autres harnesses ont été publiés. Nous espérons toujours qu'avec l'explosion des vulnérabilités découvertes par l'IA, OpenAnt 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 un scan gratuit.
Il y a aussi le fait que l'attention de Knostic porte sur la protection des agents et des assistants de codage, et non sur la recherche de vulnérabilités ou la sécurité applicative, et que nous aimons l'open source, donc nous avons décidé de publier OpenAnt sous licence Apache 2. Par 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 rivaliser avec eux.
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 au scan : https://knostic.ai/blog/oss-scan
Maintenance et recherche : Gadi Evron
Recherche originale, idéation et prototype original : Nahum Korda. Productisation originale : Alex Raihelgaus, Daniel Geyshis.
Avec nos remerciements à : Michal Kamensky, Imri Goldberg, Daniel Cuthbert. Josh Grossman, et Avi Douglen.
Si vous aimez 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 contrôler les risques associés de chaîne d'approvisionnement tels que les serveurs MCP, les extensions et les skills.
Compilez le binaire CLI (nécessite Go 1.25+) :
cd apps/openant-cli && make build
Cela 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 pour 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 pour que $(pwd) se résolve vers le bon chemin absolu.
OpenAnt route chaque phase du pipeline via 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 par phase du pipeline (l'un des adaptateurs fournis ci-dessous), saisissez sa clé API une fois par fournisseur (Bedrock utilise la chaîne d'identification AWS à la place — laissez la clé vide), et l'assistant teste chaque paire unique fournisseur+modèle avec une requête de 1 token avant d'écrire ~/.config/openant/config.json. Lancez un scan avec cette configuration via --llm-config :
openant scan /path/to/repo --llm-config my-llm
Les valeurs par défaut de l'assistant reflètent les recommandations par phase du projet (modèles de raisonnement plus puissants pour la détection / la vérification / la revue d'accessibilité ; modèles plus légers pour le contexte, le rapport et la génération de tests) — remplacez toute réponse selon vos préférences.
| Type de fournisseur | Clé API depuis | Remarques |
|---|---|---|
anthropic | console.anthropic.com | Adaptateur de référence. NON inclus dans les abonnements Claude Pro / Max — facturation séparée. |
openai | platform.openai.com | NON inclus dans les abonnements ChatGPT / Codex — facturation séparée. |
google | aistudio.google.com | NON inclus dans Gemini Advanced — facturation séparée. |
bedrock | — (chaîne d'identification AWS) | Claude sur AWS Bedrock. Pas de api_key : les identifiants proviennent des variables d'environnement AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY ou d'un profil ~/.aws, la région depuis AWS_REGION. Les ID de modèle sont des profils d'inférence (us.anthropic.claude-sonnet-4-6, global.anthropic.claude-haiku-4-5-20251001-v1:0, ...) — activez-les sous « Model access » dans la console Bedrock et listez-les avec aws bedrock list-inference-profiles. Proposé par openant setup llm (laissez la clé API vide — chaîne d'identification AWS, test ignoré) — guide complet : utilities/llm/providers/BEDROCK.md. |
openrouter | openrouter.ai | Passerelle vers de nombreux fournisseurs avec une seule clé et un seul solde prépayé (lit aussi OPENROUTER_API_KEY). Les ID de modèle sont des slugs vendor/model (anthropic/claude-sonnet-4.6, openai/gpt-4o-mini, ...) — parcourez-les sur openrouter.ai/models. Proposé par openant setup llm (laissez l'URL de base vide pour la valeur par défaut d'OpenRouter) — guide complet : utilities/llm/providers/OPENROUTER.md. |
ollama | — (serveur local) | Modèles locaux via Ollama. Pas de api_key : laissez-la vide (un espace réservé est envoyé automatiquement) ; l'URL de base par défaut est http://localhost:11434/v1. Les modèles doivent d'abord être téléchargés (ollama pull <model>) ; les ID de modèle sont exactement ce qu'affiche ollama list. L'inférence locale est gratuite — rapport de coût à $0. Proposé par openant setup llm — guide complet : utilities/llm/providers/OLLAMA.md. |
Tous prennent en charge l'appel d'outils, donc n'importe lequel peut piloter les phases enhance et verify qui utilisent la boucle agentique d'utilisation d'outils. Pour Ollama, choisissez un modèle compatible avec les outils pour ces phases — les très petits modèles locaux peuvent ne pas gérer les appels d'outils de manière fiable.
Si vous voulez les valeurs par défaut actuelles de Claude par phase et rien d'autre, ignorez l'assistant :