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.
  • Analyse des images de conteneurs : scannez des images de conteneurs entièrement construites en même temps que votre code avec corgea scan --include-image.
  • 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.
Les builds GNU Linux nécessitent glibc 2.17 ou une version ultérieure. Des builds musl entièrement statiques, sans dépendance à libc, sont aussi disponibles pour les deux architectures : corgea-x86_64-unknown-linux-musl.zip et corgea-aarch64-unknown-linux-musl.zip. Ils conviennent aux conteneurs minimaux et aux runners CI.

​
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. Les commandes et options qui ne correspondent pas à une installation sont transmises au gestionnaire de paquets. Par exemple, corgea npm --version affiche la version npm installée, tandis que corgea --version affiche la version de la CLI Corgea. 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 écrit sur stderr la progression de la résolution et du contrôle des paquets, afin de laisser stdout disponible pour une sortie exploitable par machine. La sortie standard du gestionnaire de paquets est également redirigée vers stderr. 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 :
Vous pouvez également enregistrer la valeur par défaut au moment de l’installation en ajoutant --set-default, qui conserve l’--agent transmis :
La variable d’environnement CORGEA_DEFAULT_AGENT prime sur la valeur enregistrée, ce qui est utile en CI lorsque vous ne souhaitez pas écrire dans le fichier de configuration.

​
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.
Par défaut, la commande se termine après le chargement et affiche l’URL du scan. Ajoutez --wait pour attendre la fin du traitement et afficher les résultats :
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 :
La CLI détecte les modifications non committées dans l’arbre de travail. Les scans qui incluent ces modifications sont exécutés comme des scans complets afin que les résultats correspondent aux fichiers chargés, même si le SHA du commit actuel n’a pas changé. Pour spécifier un scanner différent, tel que Semgrep :
Vous pouvez aussi utiliser --fail-on (scans BLAST uniquement) 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 :
Par exemple, --fail-on ME échoue pour les résultats ME, HI ou CR. Lorsque plusieurs conditions sont indiquées, le scan échoue dès qu’une d’entre elles correspond. Une dépendance vulnérable qui n’est pas classée comme malveillante ne correspond pas à la condition malicious. Ou échouer selon chaque règle de blocage active définie dans l’application web, que la règle s’applique aux pull requests ou à CI :
--fail est obsolète à partir de la CLI 1.10.0. Préférez --block-on pour indiquer les règles CI qu’un pipeline doit appliquer. Pour appliquer des règles précises dans un pipeline CI, définissez la cible Applies To de chaque règle sur CI dans l’application web et passez le slug généré à --block-on (CLI 1.10.0 ou ultérieure) :
Vous pouvez indiquer plusieurs slugs séparés par des virgules, par exemple criticals,malicious-deps. Seules les règles CI actives peuvent être utilisées ; un slug inconnu, une règle inactive ou une règle de pull request provoque une erreur de configuration. --block-on n’est pris en charge que par le scanner BLAST et ne peut pas être combiné avec --fail ou --fail-on. --fail et --fail-on ne peuvent pas non plus être utilisés ensemble. Les règles de blocage sont évaluées dans le cloud Corgea : la commande attend donc la fin de cette évaluation, jusqu’à 15 minutes. Si le délai est dépassé, elle se termine avec le code 1 plutôt que de laisser passer un scan non évalué. Définissez CORGEA_BLOCKING_RULES_TIMEOUT_SECONDS sur le nombre de secondes à attendre :
Un scan qui déclenche une règle de blocage écrit malgré tout le rapport --out-file et la sortie --sbom avant de se terminer. 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. Dans l’application web Corgea, les métadonnées de scan apparaissent sous forme d’étiquettes en lecture seule sur la page Scans, dans les détails du scan et dans les détails du résultat.
Page Scans affichant des pastilles de métadonnées de scan en lecture seule sur chaque scan
En-tête des détails du scan avec pastilles de métadonnées
Panneau latéral des détails du problème avec pastilles de métadonnées de scan
Sur la page Scans, développez les filtres pour filtrer par une clé de métadonnées, par une clé et une valeur exactes, ou par une valeur parmi toutes les métadonnées.
Panneau de filtres de la page Scans avec les champs clé et valeur des métadonnées de scan
La recherche principale accepte aussi has:key et key:value, par exemple has:pipeline_url ou environment:production.
Recherche Scans filtrée avec has:version
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.
--scan-type et --policy s’appliquent uniquement aux scans BLAST. Si vous passez --policy sans --scan-type policy, les autres types de scan BLAST s’exécutent tout de même et la CLI affiche un avertissement.

​
Scanner des images de conteneurs

Par défaut, Corgea détecte les images référencées par votre projet dans les fichiers Dockerfile et Docker Compose. Pour scanner à la place une image entièrement construite — par exemple une image que vous venez de construire en CI et qui n’a jamais été poussée vers un registre — transmettez-la avec --include-image :
L’option est répétable, ce qui vous permet d’inclure plusieurs images dans un même scan :
Votre moteur de conteneurs local exporte chaque image et la CLI l’envoie avec votre projet : elle est donc scannée exactement telle qu’elle est livrée. Lorsque vous utilisez --include-image, Corgea scanne les images que vous fournissez au lieu de rechercher des images de base dans votre code. Prérequis et comportement :
  • Le scan de conteneurs doit être activé pour votre compte.
  • docker ou podman doit être disponible dans votre PATH. Corgea utilise le premier trouvé ; définissez CORGEA_CONTAINER_ENGINE pour le choisir explicitement.
  • Une image absente en local est d’abord récupérée : les images d’un registre privé fonctionnent donc tant que votre moteur de conteneurs y est déjà authentifié.
  • --include-image n’est pris en charge que par le scanner BLAST.
Consultez Analyse des images de conteneurs pour savoir comment les résultats de conteneurs sont signalés et suivis.

​
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.
Pour un scan BLAST, --sbom génère une SBOM CycloneDX à la fin du scan. Le fichier par défaut est bom.json, mais vous pouvez indiquer un autre chemin :
Les rapports et les SBOM sont écrits avant l’évaluation de --fail et --block-on. Un scan qui se termine avec un code de sortie différent de zéro parce qu’une règle de blocage s’est déclenchée laisse malgré tout son rapport et sa SBOM sur le disque, afin qu’une étape CI ultérieure puisse toujours les récupérer.

​
Réutiliser un scan récent du même commit

Un pipeline qui se relance sur un commit inchangé peut réutiliser le scan que Corgea possède déjà au lieu de payer pour un doublon. Ajoutez --skip-if-commit-scanned-recently à un scan BLAST :
Lorsque le projet dispose déjà d’un scan terminé du commit actuel dans la fenêtre de réutilisation, ce scan prend la place du nouveau : le tableau de résultats, le contrôle --block-on et son code de sortie, ainsi que tout rapport --out-file en proviennent. Le pipeline se comporte de la même manière, qu’un scan ait réellement été exécuté ou non. Utilisez --scanned-within pour définir la fenêtre. Elle n’est valable qu’avec --skip-if-commit-scanned-recently. Elle accepte des valeurs telles que 90s, 30m, 24h et 7d, et interprète un nombre seul comme des heures. La valeur par défaut est 24h, car un code inchangé reste exposé aux avis publiés depuis son dernier scan.
Pour réutiliser un scan récent même si ce worktree est sale, ou si le scan précédent a enregistré worktree_dirty=true, passez --ignore-dirty-worktree (CLI 1.11.1 ou plus récente). Cette option ne peut être utilisée qu’avec --skip-if-commit-scanned-recently. Un nouveau scan signale toujours à Corgea l’état dirty réel.
Pour qu’une étape ultérieure puisse distinguer les deux cas, la commande affiche CORGEA_SCAN_SKIPPED=true accompagné de CORGEA_SCAN_ID=<id> lorsqu’elle a réutilisé un scan, et CORGEA_SCAN_SKIPPED=false lorsqu’un scan a été exécuté. Ces lignes sont des marqueurs stdout, pas des variables d’environnement. Elles ne s’affichent pas si la commande se termine parce que le commit actuel ne peut pas être résolu. Si le contrôle de réutilisation n’atteint pas l’API, la CLI avertit et lance un nouveau scan. Ce qui peut être réutilisé. Corgea ne réutilise qu’un scan qui répond à la même question, ce qui est plus strict qu’une simple correspondance de commit. Un candidat doit être un scan BLAST terminé du commit actuel, exécuté sur une branche et non dans une pull request, depuis un worktree propre et sans problème de scanner signalé. Dans tous les autres cas, un vrai scan est lancé : rien dans la fenêtre, un scan en échec ou encore en cours, ou un worktree qui ne correspond pas au commit. --ignore-dirty-worktree contourne la moitié de ce test relative au worktree sale : la réutilisation a lieu si ce worktree est sale ou si le scan précédent a enregistré worktree_dirty=true. Un scan précédent qui n’a jamais signalé l’indicateur n’est toujours pas réutilisé, car sa portée est inconnue. Options non combinables. Aucune API n’indique comment un scan antérieur avait été délimité. --skip-if-commit-scanned-recently ne peut donc pas être combiné avec --only-uncommitted, --target, --scan-type, --policy ou --include-image, et la commande échoue si vous en transmettez une. --exclude est autorisé mais affiche un avertissement en cas de réutilisation : le scan réutilisé couvre des fichiers que cette exécution aurait ignorés, de sorte que les résultats peuvent en signaler trop, jamais trop peu. Si le commit actuel ne peut pas être résolu — le répertoire n’est pas un dépôt git, ou le dépôt ne contient encore aucun commit — la commande se termine avec un code de sortie différent de zéro au lieu de lancer silencieusement un scan complet. Lorsqu’un scan est réutilisé, --sbom reflète toujours l’espace de travail actuel, et non le SBOM antérieur du scan réutilisé.

​
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 :
corgea wait, corgea scan et corgea upload --wait se terminent avec le code 1 si le scan échoue, en affichant la raison ainsi que les scanners ayant signalé un problème. Un scan qui se termine sans les résultats de l’un des scanners se termine avec le code 0 et un avertissement. L’attente s’arrête au bout de 10 heures, afin qu’un scan qui ne signale jamais de statut final ne bloque pas indéfiniment un job de CI. En cas de dépassement, la commande se termine avec le code 1. Le scan continue de s’exécuter dans le cloud Corgea. Si vos scans nécessitent plus de temps, définissez CORGEA_SCAN_TIMEOUT_SECONDS avec le nombre de secondes à attendre :
La CLI résout normalement le projet depuis l’URL distante du dépôt actuel. Utilisez --repo org/repo (ou une URL) pour un autre dépôt, ou --project-name pour un nom de projet exact. corgea wait SCAN_ID --project-id PROJECT_ID ignore la résolution du projet. corgea scan, corgea wait et corgea upload --wait se terminent tous avec un code de sortie différent de zéro lorsqu’un scan échoue, en affichant la raison et en nommant les scanners qui ont rencontré des problèmes. Un scan qui se termine avec un scanner manquant sort plutôt en 0 avec un avertissement. L’attente s’arrête au bout de 10 heures ; ajustez ce budget avec CORGEA_SCAN_TIMEOUT_SECONDS. Avec --fail ou --block-on, la CLI attend ensuite jusqu’à 15 minutes l’évaluation des règles de blocage ; modifiez cette valeur avec CORGEA_BLOCKING_RULES_TIMEOUT_SECONDS.

​
Lister les scans et les problèmes de sécurité, SCA ou qualité du code

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, la valeur worktree_dirty, qui peut être null, et les éventuelles metadata du scan renvoyées par Corgea. worktree_dirty vaut true lorsque le scan inclut des modifications locales non committées et peut valoir null pour les scans créés par d’anciennes versions de la CLI. Pour lister les problèmes SCA d’un projet ou d’un scan, utilisez --sca-issues ou son alias -c. Le tableau inclut la classification de chaque problème, et la sortie JSON inclut le champ classification lorsqu’il est fourni.
ou
Utilisez --code-quality (ou --quality/-q) pour lister les problèmes de qualité du code. --scan-id permet de les limiter à un scan.
Les commandes de liste résolvent le projet depuis l’URL distante. Utilisez --repo org/repo (ou une URL) pour un autre dépôt, ou --project-name pour un nom de projet exact.

​
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 :

​
Variables d’environnement

​
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.