Skip to main content

​
Introduction

La CLI Corgea est un outil puissant qui aide les développeurs à détecter et à corriger les vulnérabilités de leur code. Grâce à notre scanner optimisé par l’IA (BLAST) et à la plateforme Corgea, elle identifie des problèmes complexes tels que les failles de logique métier, les vulnérabilités d’authentification et d’autres bugs difficiles à repérer. La CLI permet de scanner le code, d’examiner les résultats, d’interagir avec les correctifs et bien plus encore, tout en offrant une excellente expérience développeur.
Renforcez les capacités de votre agent de développement IA. La CLI Corgea sert également de base à nos intégrations agentiques : installez l’Agent Skill Corgea et laissez votre agent IA (Cursor, Claude Code, Copilot, etc.) scanner, trier et corriger les vulnérabilités pour vous.

​
Fonctionnalités

  • Prise en charge de plusieurs scanners : scannez avec BLAST, notre scanner optimisé par l’IA, et chargez des rapports Semgrep, Snyk, Checkmarx, CodeQL, Fortify ou Coverity.
  • Gestion des problèmes : répertoriez, examinez et gérez les résultats de sécurité.
  • Intégration des correctifs : affichez et appliquez directement depuis le terminal les correctifs de vulnérabilités générés par l’IA.
  • Analyse des dépendances : créez des inventaires de dépendances hors ligne, examinez les graphes de dépendances, générez des SBOM et évaluez les politiques avec corgea deps.
  • Consultation des avis de sécurité des paquets : consultez les avis connus avant de choisir ou d’installer un paquet npm ou PyPI.
  • Contrôle des installations par les gestionnaires de paquets : avant leur installation, vérifiez et bloquez les paquets vulnérables, malveillants ou trop récents installés avec npm, yarn, pnpm, pip ou uv. Voir Contrôle des installations par les gestionnaires de paquets.
  • Formats de sortie flexibles : utilisez une sortie lisible ou JSON pour faciliter les intégrations CI.
  • Intégration CI/CD : faites échouer les builds selon les niveaux de sévérité ou des règles de blocage personnalisées.
  • Gestion des scans : suivez la progression et les résultats des scans de vos projets.
  • Installation d’Agent Skills : installez dans les agents de développement pris en charge les Agent Skills approuvés du registre Corgea.

​
Prérequis

  • Compte Corgea : un compte Corgea actif.
  • Token d’authentification : un token d’API Corgea ou un token d’accès JWT valide.
Les commandes hors ligne corgea deps scan, graph, explain, diff, sbom et policy init ne nécessitent ni compte Corgea, ni token, ni configuration, ni accès réseau.

​
Guide d’installation

​
Installer avec npm

Le package npm regroupe les binaires natifs des plateformes prises en charge et sélectionne à l’exécution celui qui correspond à votre système d’exploitation et à votre architecture.

​
Installer avec uv

Pour les utilisateurs de Python, il s’agit de la méthode recommandée. uv tool install crée à partir du paquet PyPI un environnement isolé pour l’outil et expose la CLI sous le nom corgea dans votre PATH.
Si uv signale que son répertoire d’outils ne figure pas dans votre PATH, exécutez :

​
Installer avec pip

Si vous n’utilisez pas uv, vous pouvez installer Corgea CLI avec pip, le gestionnaire de paquets Python :
Cette commande télécharge le paquet Corgea CLI depuis PyPI (Python Package Index) et l’installe sur votre système. Pour plus de détails, consultez sa page PyPI : https://pypi.org/project/corgea-cli/.

​
Installer avec Homebrew

Pour installer Corgea CLI avec Homebrew, ajoutez d’abord le tap Corgea, puis installez la CLI :

​
Installer manuellement

Téléchargez l’archive de votre plateforme depuis la dernière version, décompressez-la et placez le binaire corgea dans votre PATH. Les URL latest/download ci-dessous renvoient toujours vers la version la plus récente.
Une version Linux liée statiquement est également publiée comme corgea-x86_64-unknown-linux-musl.zip.

​
Authentification

​
Se connecter avec la CLI

Pour vous authentifier avec la CLI, exécutez la commande suivante. Vous serez redirigé vers l’application web afin d’autoriser la CLI :

​
Connexion avec un scope personnalisé (instances monolocataires)

Conseil : le scope de votre entreprise correspond au sous-domaine Corgea, par exemple https://your-company.corgea.app.

​
Connexion avec un token (API ou JWT)

Pour les pipelines automatisés et les environnements CI/CD, l’authentification par token fournit une procédure de connexion fiable et non interactive. Vous pouvez fournir un token d’API Corgea ou un token d’accès JWT :
Vous pouvez aussi définir le token dans une variable d’environnement :

​
Pointer vers une instance monolocataire

Les clients qui utilisent une instance monolocataire doivent faire pointer la CLI vers cette instance avec l’option --url :
Vous pouvez également définir l’URL dans une variable d’environnement ; la CLI la détectera automatiquement :

​
Utilisation

​
Commandes et options

​
Consulter les avis sur les paquets

Utilisez corgea advisories check pour consulter les avis connus avant de choisir ou d’installer un paquet npm ou PyPI. Une vérification sans version affiche l’historique des avis du paquet ; ajoutez une version exacte pour obtenir un verdict sur cette release.
L’écosystème peut être npm ou pypi (pip est également accepté comme alias). Pour npm, indiquez une version complète et exacte telle que 1.2.3 ; les plages, tags et versions partielles ne sont pas pris en charge. Pour PyPI, les syntaxes package@version et package==version, de style pip, sont acceptées. Les résultats obtenus sans version permettent d’examiner l’historique des avis avant de choisir une version. Pour une version exacte, les résultats incluent le détail des avis connus, les versions corrigées lorsqu’elles sont disponibles et une version sûre recommandée lorsque tous les avis disposent d’un correctif. Cette commande est en lecture seule et nécessite un accès réseau ; le contrôle des installations par les gestionnaires de paquets reste le mécanisme d’application. Utilisez --json pour obtenir une réponse exploitable par une machine selon le schéma version 1. La commande renvoie le code 0 si aucun avis n’est trouvé, 1 si elle en trouve et 2 en cas d’erreur. Un paquet absent de la base d’avis renvoie le code 0.

​
Contrôle des installations du gestionnaire de paquets

Utilisez corgea npm, corgea yarn, corgea pnpm, corgea pip ou corgea uv pour faire vérifier par Corgea les commandes d’installation prises en charge avant que les dépendances ne soient installées.
Corgea compare chaque version résolue aux données publiques de vulnérabilités afin de détecter les releases vulnérables ou malveillantes, sans token, et bloque les releases anormalement récentes (voir Contrôle de récence ci-dessous). Une version vulnérable, malveillante ou trop récente bloque l’installation avant l’exécution du gestionnaire de paquets. Placez les options du wrapper entre le nom du gestionnaire et sa commande, par exemple corgea pip --force install requests. Contrôle de récence. En plus des vulnérabilités, Corgea bloque toute cible d’installation nommée dont la version résolue a été publiée pendant une période de récence donnée. Ce contrôle détecte les typosquats et détournements qui viennent d’être publiés avant leur référencement dans les flux d’avis. Il est activé par défaut avec une fenêtre de 14 jours. Configurez-le dans ~/.corgea/config.toml (recency_gate = false pour le désactiver, recency_threshold_days pour ajuster la fenêtre) ou avec les variables d’environnement CORGEA_RECENCY_GATE et CORGEA_RECENCY_THRESHOLD_DAYS. Un paquet dont la date de publication est inconnue ne déclenche jamais ce contrôle ; un verdict vulnérable ou malveillant prévaut sur la récence, et --force le contourne pour une seule installation. Couverture. pip install et npm install résolvent l’ensemble des paquets qui seraient installés, y compris les dépendances transitives. Une dépendance transitive vulnérable bloque donc la commande. Si le résolveur en mode simulation échoue, Corgea affiche un avertissement et se rabat sur la vérification des cibles nommées. npm ci est contrôlé à partir du lockfile du projet et uv sync à partir de uv.lock : tout l’ensemble verrouillé est ainsi vérifié, même si ces commandes ne nomment aucun paquet. Le contrôle uv couvre également les cibles nommées de uv add ... et uv pip install ..., tandis que uv lock est exécuté directement puisqu’il n’installe rien. yarn et pnpm ne vérifient que les cibles nommées, faute de résolveur sûr en mode simulation. Installations sans cible. Une commande npm install sans cible est contrôlée à partir du fichier package.json du projet. Les commandes yarn, pnpm et uv d’installation sans cible ne peuvent pas être vérifiées au préalable ; Corgea affiche alors un message et les exécute sans contrôle.
Mode public ou authentifié. Sans token, le contrôle fonctionne en mode public : les paquets vulnérables et malveillants restent bloqués, mais les paquets invérifiables et les échecs de recherche produisent seulement un avertissement et laissent l’installation se poursuivre. Les échecs répétés sont regroupés sur une seule ligne de synthèse. Avec un token fourni par CORGEA_TOKEN ou corgea login et l’API de vulnérabilités par défaut, le contrôle fonctionne en mode authentifié et applique une stratégie de refus par défaut : les paquets invérifiables, les échecs de résolution des dépendances, les indisponibilités de l’API de vulnérabilités et la couverture dégradée de l’arbre avec les gestionnaires qui le résolvent normalement en entier (pip, npm, uv) bloquent l’installation, sauf si vous indiquez --force. API de vulnérabilités personnalisée. Si CORGEA_VULN_API_URL pointe vers un endpoint personnalisé, Corgea n’y envoie pas votre token ; le contrôle reste donc en mode public. Définissez CORGEA_VULN_API_SEND_TOKEN_TO_CUSTOM_URL=1 pour activer le mode authentifié avec un endpoint de confiance. Environnements Python gérés en externe. Pour pip, Corgea refuse les installations dans les environnements gérés en externe (PEP 668) avant de consulter le registre. Activez un environnement virtuel ou indiquez --force pour contourner ce contrôle. Corgea exécute le gestionnaire de paquets correspondant depuis votre PATH. Pour corgea pip ..., il essaie pip3 si pip est absent. Si aucun des deux n’est disponible, la CLI renvoie le code 127 et indique le binaire manquant. Résultats. Lorsqu’un paquet résolu est vulnérable, les résultats dans l’arbre indiquent son origine :
  • (from requirements) — demandé dans un fichier requirements de pip.
  • (already in package.json) — déjà présent comme dépendance npm directe.
  • (transitive) — introduit par une autre dépendance.
Lorsque le paquet nommé est sain, mais que l’arbre résolu contient déjà un paquet vulnérable, le refus identifie l’arbre existant comme source. Les lignes d’avis indiquent la version corrigée publiée ou précisent qu’aucune n’est connue. Si tous les avis concernant un paquet indiquent un correctif, Corgea affiche safe version: axios@0.21.2. Pour une dépendance npm directe vulnérable, il peut également afficher fix with: corgea npm install package-name@version (advertised fix). Le décompte des vulnérabilités et le code de sortie dépendent de la cible d’installation initiale. Sortie JSON. --json renvoie un seul rapport sur stdout et redirige la sortie standard du gestionnaire de paquets vers stderr, afin de réserver stdout à Corgea. Le schéma version 2 contient manager, subcommand, args, recency_threshold_days (fenêtre de récence active, ou null si le contrôle est désactivé, à associer au champ age_seconds de chaque résultat), un objet summary séparant les décomptes named et tree, verdict_mode, un tableau results et un objet tree lorsque la résolution de l’arbre a été exécutée. Les entrées de l’arbre ont un champ origin égal à requested, pre-existing ou transitive. Les paquets malveillants connus renvoient un status distinct égal à malicious, un booléen malware pour chaque correspondance et un décompte malicious séparé dans chaque objet de synthèse. Leur champ remediation vaut toujours null, car le paquet doit être supprimé et non mis à niveau. Les verdicts de vulnérabilité ne proposent une version sûre que si elle corrige tous les avis.

​
Installer des Agent Skills

Installez un Agent Skill approuvé du registre Corgea dans le répertoire de skills de votre agent de développement :
Les ID d’agent pris en charge sont cursor, claude-code, codex, github-copilot, gemini-cli, windsurf, opencode et universal. Utilisez --scope project pour installer le skill dans le dépôt actuel, --scope user pour l’installer pour votre compte utilisateur, ou --dir pour choisir un répertoire de skills personnalisé. Pour installer une version spécifique, ajoutez-la au nom de la compétence :
Vous pouvez également sauvegarder un agent par défaut pour les futures installations :

​
Charger un rapport de scan

Chargez un rapport de scan dans Corgea par STDIN ou depuis un fichier (JSON, SARIF, FPR ou XML Coverity) :
Pour définir le nom du projet affiché dans Corgea pour les rapports chargés, utilisez --project-name. Sans cette option, la CLI utilise le nom du dépôt Git s’il est disponible, puis le nom du répertoire courant.
Pour les rapports volumineux, la CLI charge les données par blocs. Elle vérifie la progression signalée par le serveur et renvoie un code différent de zéro si le serveur indique un offset inattendu ou si le chargement se termine sans renvoyer d’ID de scan.

​
Scanner votre code

Pour scanner le répertoire actuel avec le scanner BLAST par défaut :
Pour spécifier un scanner différent, tel que Semgrep :
Vous pouvez aussi utiliser --fail-on avec une ou plusieurs conditions séparées par des virgules : CR, HI, ME, LO ou malicious. Une condition de sévérité correspond aux résultats de ce niveau ou d’un niveau supérieur ; par exemple, ME correspond aussi à HI et CR. La condition malicious correspond à une dépendance classée comme malveillante. La commande renvoie un code différent de zéro si l’une des conditions indiquées correspond. Exemples :
Ou échouer selon les règles de blocage définies dans l’application web :
Par défaut, la commande scanne tout le projet. Pour ne scanner que vos modifications avant de les committer, utilisez l’option --only-uncommitted.
Vous pouvez aussi cibler des fichiers ou des sous-ensembles précis du projet avec l’option --target (scans BLAST uniquement). Elle accepte des valeurs séparées par des virgules : chemins de fichiers ou de répertoires, motifs glob, sélecteurs Git ou stdin. Exemples :
Vous pouvez exclure des fichiers des scans BLAST avec l’option --exclude. Elle accepte des motifs glob séparés par des virgules et peut être utilisée avec ou sans --target.
Note : --only-uncommitted et --target ne peuvent pas être utilisés ensemble. Pour ignorer des fichiers pendant un scan BLAST, utilisez --exclude avec des motifs glob séparés par des virgules. Combinez cette option à --target pour scanner un sous-ensemble tout en excluant les correspondances qu’il contient.
Pour définir le nom du projet affiché dans Corgea, utilisez --project-name. Sans cette option, la CLI utilise le nom du dépôt Git s’il est disponible, puis le nom du répertoire courant.
Pour associer des métadonnées personnalisées à un scan BLAST, répétez l’option --metadata avec des paires KEY=VALUE. Ces valeurs sont associées au scan et incluses dans la sortie JSON de la liste des scans.
--metadata est uniquement pris en charge par le scanner BLAST. Chaque entrée doit avoir une clé non vide. Si une clé est fournie plusieurs fois, la dernière valeur l’emporte. Un scan BLAST standard comprend plusieurs analyses :
  • Scan IA BLAST de base
  • Scan PolicyIQ
  • Détection de code malveillant
  • Détection de secrets
  • Détection des informations personnelles identifiables (PII)
Par défaut, toutes ces analyses sont exécutées si elles sont incluses dans le forfait de votre entreprise. L’option --scan-type permet toutefois d’en cibler une ou plusieurs.
ou plusieurs types :
Pour cibler des politiques précises avec un scan PolicyIQ, utilisez l’option --policy et transmettez leur ID.

​
Exporter un rapport de scan

La CLI Corgea permet d’exporter les résultats dans un fichier, ce qui est particulièrement utile dans un pipeline CI. Utilisez pour cela les options --out-format et --out-file.
La CLI prend actuellement en charge les formats de sortie HTML, JSON, SARIF et Markdown.

​
Inventaire des dépendances

Utilisez corgea deps pour constituer hors ligne un inventaire des dépendances à partir des manifestes et lockfiles npm, Python et Java. La commande évalue la politique de verrouillage des dépendances, peut faire échouer la CI selon les résultats et ne nécessite ni authentification ni accès réseau.
Commandes courantes d’inventaire des dépendances :
Utilisez --format human, agent, json ou quiet pour contrôler la sortie dans le terminal des commandes scan, graph, explain, diff et policy init. Lorsqu’un environnement d’agent est détecté, corgea deps utilise par défaut le format compact agent. Indiquez --format human pour forcer la sortie normale du terminal. Pour exporter un rapport avec corgea deps scan, utilisez --out-format table, json ou sarif, éventuellement avec --out-file. Ne combinez pas --format et --out-format dans la même commande deps scan. Pour personnaliser la politique de dépendances, initialisez .corgea/deps.yml :
La politique générée détermine si les lockfiles sont obligatoires, si leur absence ou leur obsolescence doit provoquer un échec, et si les dépendances directes utilisant des wildcards, latest ou des plages semver doivent être signalées. Consultez Analyse des dépendances pour des exemples d’intégration CI, la configuration des politiques et le dépannage.

​
Attendre un scan

Pour attendre le dernier scan en cours :
Ou spécifiez un identifiant de scan à attendre :

​
Lister les scans, les problèmes ou les problèmes SCA

Pour lister tous les scans d’un répertoire courant (pagination par défaut) :
Pour lister les problèmes d’un scan spécifique :
Vous pouvez aussi contrôler la pagination :
Remarque : l’option --json est disponible pour des commandes telles que list et inspect. Elle produit des résultats au format JSON, utiles pour les intégrations et l’automatisation.
Le tableau des scans affiche les huit premiers caractères du SHA du commit de chaque scan, ou N/A si aucun SHA n’est disponible. La sortie JSON contient la valeur git_sha complète et les éventuelles metadata du scan renvoyées par Corgea. Pour lister les problèmes SCA d’un projet ou d’un scan, utilisez --sca-issues ou son alias -c :
ou

​
Inspecter un scan ou un problème

Pour inspecter un scan spécifique :
Pour inspecter les problèmes avec une sortie détaillée :
Pour des explications ou diffs de correction :

​
Intégration aux hooks Git

Pour assurer la qualité et la sécurité du code, intégrez la CLI Corgea à votre workflow Git au moyen de hooks de pré-commit. Vous pourrez scanner vos modifications avant de les committer ou de les pousser. Pour configurer le hook, exécutez :
Lors de la configuration du hook de pré-commit, vous êtes invité à choisir les paramètres du scan. Pour utiliser rapidement les paramètres par défaut, qui activent les scans PII et de secrets et définissent les niveaux d’échec sur CR, HI, ME et LO, exécutez :
Pour contourner la vérification de pré-commit lors d’un commit, utilisez :

​
Mode de débogage

Pour activer les logs de débogage, définissez CORGEA_DEBUG=1 avant d’exécuter une commande.
Lorsque le mode débogage est activé, les requêtes de chargement en échec incluent dans la sortie de débogage le statut HTTP et le corps de la réponse, ce qui facilite le diagnostic.

​
Options supplémentaires

Pour plus d’options et de commandes, utilisez :

​
Notes de version

Consultez la page des versions GitHub pour les notes de version complètes.