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 et de remédiation 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 analyse gratuitement.
Il y a aussi le fait que l'objectif de Knostic est de protéger les agents et les assistants de codage, et non la recherche sur les vulnérabilités ou la sécurité des applications, 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 (aujourd'hui 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 à l'analyse : 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 la chaîne d'approvisionnement tels que les serveurs MCP, les extensions et les skills.
Compiler le binaire CLI (nécessite Go 1.25+) :
cd apps/openant-cli && make build
Cela compile la source Go et génère le binaire dans apps/openant-cli/bin/openant.
Créez un lien symbolique vers celui-ci dans 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 ceci depuis la racine du dépôt afin que $(pwd) se résolve au bon chemin absolu.
OpenAnt achemine 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 de pipeline (l'un des adaptateurs fournis ci-dessous), saisissez sa clé API une fois par fournisseur (Bedrock utilise plutôt la chaîne d'identification AWS — 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 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 par phase du projet (modèles de raisonnement plus puissants pour la détection / vérification / 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'identifiants 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'identifiants AWS, sonde ignorée) — 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 est par défaut 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 d'entre eux 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 :