Scanner de vulnérabilités : déployer Codex Security en équipe

Qu’apporte Codex Security depuis DevDay ?

Codex Security permet de repérer du code vulnérable à trois endroits : dans le dépôt, dans une pull request et dans la copie de travail du développeur. C’est l’équivalent d’une inspection du bâtiment, d’un contrôle des travaux envisagés et d’une vérification avant que l’ouvrier quitte le chantier. Chaque contrôle porte sur une partie différente du même système.

Une pull request est une proposition de modification du code en attente de revue. La CLI est l’outil en ligne de commande que l’on lance dans un terminal ; la CI désigne le processus de vérification automatisé qui s’exécute lorsque le code change.

Cloud examine les problèmes détectés, élimine les doublons et prépare des correctifs même lorsque votre ordinateur est fermé. OpenAI le présente toujours comme une version expérimentale (« research preview »). L’annonce de DevDay du 29 septembre précise la disponibilité et la possibilité de programmer des scans ; elle ne fait pas de Cloud un produit disponible en version générale. Récapitulatif de DevDay, statut actuel du produit.

Pour une équipe sur GitLab, le point de départ est la CLI. La configuration actuelle de Security Cloud passe par GitHub. Le fait que Codex prenne en charge les merge requests GitLab de manière générale ne prouve pas que Security Cloud les prend en charge. Le guide GitLab CI/CD décrit, lui, une méthode prise en charge pour exécuter des contrôles de sécurité dans cet environnement.

Quels abonnements donnent accès au service, et combien coûtent cinq licences ?

Codex Security Cloud est accessible avec Pro, Business, Enterprise et Edu, selon l’annonce datée de DevDay et le centre d’aide actuel. Security Review mentionne les mêmes abonnements et exclut explicitement Plus. Il faut également activer les autorisations de l’espace de travail et l’accès aux dépôts. Disponibilité de Cloud, accès à Security Review.

Pour une petite entreprise, la comparaison pertinente porte sur cinq licences Standard Business :

La facturation en tokens dépend de la quantité de texte que le modèle lit et génère. Le prix des licences peut varier selon le pays et la devise. Le calcul de l’abonnement reprend la FAQ Business actuelle. Les consignes de facturation actuelles de Cloud indiquent que les clients existants sont prévenus et doivent accepter l’activation de l’usage payant avant son démarrage ; sans financement, les scans sont suspendus. Elles ne donnent pas de devis global incluant les scans pour cinq personnes. Facturation de Cloud, distinction entre abonnement et tarifs API.

Si vous payez déjà Business, le coût supplémentaire des licences peut être nul. L’usage des scans et des revues reste à prévoir dans le budget. Le total mensuel comprend les licences, l’usage Cloud applicable, les scans CI via l’API, le temps d’exécution du runner et, éventuellement, un abonnement à un tableau de bord de sécurité.

Ne comptez pas sur un nouveau premier mois gratuit. L’offre d’usage gratuit accompagnait le lancement du 6 mars et couvrait le mois suivant. Les pages actuelles du produit et de sa facturation ne permettent pas d’établir l’existence d’une offre renouvelée au 30 septembre. Conditions du lancement initial, conditions de facturation actuelles.

Pour disposer d’un point de comparaison, l’offre payante Code de Semgrep affiche $30 par contributeur et par mois, soit $150 pour cinq contributeurs. Sa Free Edition prend aussi en charge jusqu’à 10 dépôts et 10 contributeurs. Une équipe de cinq personnes peut donc évaluer les deux solutions sans supposer que tout scanner existant exige un achat. Leur couverture diffère : le prix ne suffit pas à choisir votre ensemble d’outils de sécurité. Tarifs Semgrep.

Configurer le scanner de vulnérabilités sur un dépôt et valider le correctif

Commencez par une application que vous connaissez et une personne capable d’expliquer ses règles d’accès. Un modèle de menace décrit brièvement ce que l’application protège, qui peut y accéder et à quels endroits elle fait confiance à un autre système. C’est le plan du bâtiment qui indique à l’inspecteur quelles portes doivent rester verrouillées.

1. Ouvrez Plugins dans ChatGPT, depuis l’application de bureau ou le web. Installez et activez Codex Security Cloud, puis ouvrez Security Cloud.
2. Sélectionnez New scan. Si l’interface vous le demande, connectez GitHub en accordant l’accès au dépôt à analyser.
3. Choisissez le dépôt et un Cloud environment compatible. Au besoin, créez un environnement avec les dépendances et la configuration de test nécessaires au projet.
4. Dans What to scan, choisissez Repository, puis Start scan. Suivez la progression dans Scans.
5. Ouvrez Findings. Examinez le code concerné, les éléments de validation et les recommandations de correction. Une tentative de validation qui échoue laisse les éléments de preuve en suspens ; elle ne permet pas d’écarter la vulnérabilité.
6. Lorsque Fix with Codex est proposé, générez le patch et examinez-le, puis utilisez Create draft pull request après cette revue. Exécutez vos tests habituels et faites intervenir le responsable du code avant de fusionner.

Ce sont les commandes de configuration actuelles de Cloud. L’environnement facilite la reproduction des failles présumées, sans garantir que chaque problème sera validé. Fonctionnement de la validation.

Pour poursuivre les contrôles, créez un autre scan avec Commit changes. Dans Repositories, ouvrez Monitoring settings pour choisir l’environnement, définir la période d’historique et activer ou suspendre la surveillance. Mettez à jour le modèle de menace dans Project context lorsque l’architecture évolue. Cloud permet aussi de programmer des scans du dépôt, comme annoncé à DevDay. Le guide de configuration actuel ne précise ni les fréquences ni les quotas : il ne faut donc pas supposer qu’un scan quotidien est inclus. Configuration de la surveillance, scans programmés.

Un cas réel : qualifier les vulnérabilités détectées dans Gogs

Gogs montre pourquoi il faut connaître le contexte de déploiement avant de transformer un résultat en ticket. OpenAI cite ce dépôt et les vulnérabilités ci-dessous parmi les découvertes publiées de Codex Security. Il s’agit d’un cas de scan publié par le fournisseur, pas d’un nouveau scan réalisé pour cet article. Les recommandations de qualification ci-dessous s’appuient sur les avis de sécurité des mainteneurs. Résultats divulgués par OpenAI.

Un identifiant CVE désigne une vulnérabilité divulguée. L’authentification à deux facteurs, ou 2FA, ajoute une seconde vérification à la connexion, en plus du mot de passe.

Le premier avis indique des correctifs dans 0.13.4 et 0.14.0+dev ; le second, dans 0.14.0. Ce sont les premières versions corrigées mentionnées par des avis historiques, pas des recommandations d’installation d’une ancienne version aujourd’hui. Vérifiez la version actuellement prise en charge par le projet avant de mettre à niveau. Avis Gogs sur les codes de récupération, avis Gogs sur les téléversements.

Gardez une fiche de qualification concise : révision déployée, point d’entrée accessible, preuves, responsable, action et test de validation du correctif. Un résultat peut être retenu, écarté avec une justification concrète ou laissé en attente d’investigation. Ne le marquez comme corrigé qu’après avoir vérifié le changement de comportement.

Appliquez la même rigueur à vos propres scans. Les rapports enregistrés par la CLI consignent les résultats et la couverture de l’analyse. Si un scan ultérieur ne mentionne plus une vulnérabilité signalée auparavant, cela ne prouve pas qu’elle a été corrigée. De même, un retour indiquant un faux positif ne désactive pas définitivement la détection de cette catégorie de vulnérabilités. Historique des résultats et retours.

Activer la revue de sécurité automatique des pull requests

Après l’analyse initiale du dépôt, ajoutez la revue des pull requests comme deuxième niveau de contrôle. Dans Codex settings, choisissez le dépôt. Sous Review security vulnerabilities, activez Auto security review et sélectionnez All PRs, ou les préférences personnelles si vous souhaitez que chacun active la fonction volontairement.

Choisissez On PR open pour une première revue à l’ouverture, On every push pour répéter la revue à chaque modification du code, ou Whenever code review runs pour l’associer à Code Review. Un scan Security Cloud préalable est facultatif. Vous pouvez réutiliser son modèle de menace ou indiquer le chemin d’un fichier de modèle de menace dans le dépôt. Configuration de Security Review.

Par défaut, les revues automatiques signalent les vulnérabilités de gravité élevée et critique, soit High et Critical. Les revues demandées manuellement incluent aussi, par défaut, le niveau moyen, Medium. Ces seuils se règlent indépendamment. Pour lancer une revue manuelle, ajoutez le commentaire @codex security review à la pull request, puis ouvrez le Security Report de la tâche associée pour consulter l’ensemble des preuves. Les résultats publiés sur GitHub héritent de la visibilité de la pull request.

Cette revue se concentre sur la sécurité. Code Review peut également signaler des problèmes de sécurité : certains résultats peuvent donc se recouper. Le guide général de la revue avec Codex aide à déterminer le rôle de chaque revue.

Installer la CLI pour les scans locaux et les contrôles avant commit

La CLI permet de mener le même type d’investigation sur un dépôt dans un outil pilotable par script. Le code source est sous licence Apache 2.0 et le paquet npm public est @openai/codex-security. La disponibilité du code source ne donne pas un accès illimité aux scans. Code source et licence officiels, prérequis de la CLI.

L’accès au modèle Daybreak Blue inclus dans Cloud reste limité à Cloud ; il ne donne pas accès à ce modèle via les autres produits Security ou l’API. Vérifiez votre mode de connexion et vos droits d’accès au modèle avant de déplacer un scan en CI. Limites d’accès entre les produits.

Il faut distinguer plusieurs dates : le dépôt GitHub a été créé le 13 juillet 2026 ; son historique public actuel commence par un commit d’initialisation du 15 juillet, et les publications npm débutent le 28 juillet. La date du 13 juillet ne suffit pas à prouver que la CLI npm sous cette licence était disponible ce jour-là. Fixez la version du paquet pour rendre l’installation reproductible. Métadonnées du dépôt, commit initial, historique des publications npm.

Utilisez Node.js 22.13.0 ou une version ultérieure de la branche 22, Node 24 ou Node 26, ainsi que Python 3.10 ou une version ultérieure. Depuis votre dépôt, connectez-vous et placez les résultats hors de la copie de travail :

npx @openai/codex-security@0.1.31 login
npx @openai/codex-security@0.1.31 scan . --auth chatgpt \
  --output-dir ../codex-security-results --dry-run
npx @openai/codex-security@0.1.31 scan . --auth chatgpt \
  --output-dir ../codex-security-results

Examinez report.md, findings.json et coverage.json. La couverture peut être complète, partielle ou inconnue. Lisez les zones dont l’analyse a été reportée et les questions ouvertes, même si aucune vulnérabilité n’a été signalée. Ces commandes suivent le guide de démarrage de la CLI.

Installez le contrôle avant commit avec npx @openai/codex-security@0.1.31 install-hook. Il analyse les changements indexés et non indexés, bloque par défaut les vulnérabilités de niveau High ainsi que les erreurs de scan, et préserve un script pre-commit existant. Comme il examine les deux types de changements, évitez de laisser des expérimentations sans rapport dans la copie de travail lorsque vous interprétez le résultat. Fonctionnement du hook.

La version du paquet et les commandes ci-dessus ont été vérifiées pendant la préparation de cet article. Celui-ci ne présente aucun scan local authentifié, aucune durée de scan mesurée ni aucun coût de scan constaté.

Intégrer la CLI à la CI et conserver les rapports SARIF

SARIF est un format de fichier standard pour les résultats d’analyse de sécurité. Il permet à un autre outil d’afficher chaque problème à côté de son emplacement dans le code source. Exporter ce fichier et acheter un tableau de bord hébergé sont deux décisions distinctes.

Créez un secret CI nommé CODEX_SECURITY_API_KEY pour un compte ou une organisation API disposant de l’accès requis aux scans. La clé permet au runner de s’authentifier sans connexion interactive à ChatGPT. Cet exemple GitHub Actions analyse les pull requests de confiance issues du même dépôt, compare précisément leur base et leur tête, exporte le SARIF et conserve les résultats. Il adapte le modèle CI officiel, fixe la version du paquet vérifiée pour cet article et bloque au seuil de gravité High. Retirez --fail-on-severity high pour commencer par un déploiement purement informatif ; les erreurs de scan et la couverture incomplète demandent tout de même votre attention.

Enregistrez-le dans .github/workflows/codex-security.yml :

name: Codex Security
on:
  pull_request:
jobs:
  security:
    if: github.event.pull_request.head.repo.full_name == github.repository && github.actor != 'dependabot[bot]'
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020
        with:
          node-version: '26'
      - uses: actions/setup-python@5fda3b95a4ea91299a34e894583c3862153e4b97
        with:
          python-version: '3.14'
      - name: Install trusted CLI outside the checkout
        run: npm install --prefix "$RUNNER_TEMP/security-cli" --ignore-scripts --no-audit --no-fund @openai/codex-security@0.1.31
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1
        with:
          ref: ${{ github.event.pull_request.head.sha }}
          fetch-depth: 0
          persist-credentials: false
      - name: Scan and export
        env:
          OPENAI_API_KEY: ${{ secrets.CODEX_SECURITY_API_KEY }}
          CODEX_SECURITY_STATE_DIR: ${{ runner.temp }}/security-state
          BASE_SHA: ${{ github.event.pull_request.base.sha }}
          HEAD_SHA: ${{ github.event.pull_request.head.sha }}
        run: |
          set -euo pipefail
          cli="$RUNNER_TEMP/security-cli/node_modules/.bin/codex-security"
          out="$RUNNER_TEMP/security-results"
          base="$(git merge-base "$BASE_SHA" "$HEAD_SHA")"
          scan_exit=0
          "$cli" scan . --diff "$base" --head "$HEAD_SHA" \
            --auth api-key --output-dir "$out" \
            --fail-on-severity high --json \
            > "$RUNNER_TEMP/security-result.json" || scan_exit=$?
          if test -f "$out/scan-manifest.json"; then
            "$cli" export "$out" --export-format sarif \
              --source-root "$GITHUB_WORKSPACE" \
              --output "$out/results.sarif"
          fi
          exit "$scan_exit"
      - name: Keep reports, including SARIF when available
        if: always()
        uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a
        with:
          name: codex-security-results
          path: |
            ${{ runner.temp }}/security-results
            ${{ runner.temp }}/security-result.json
          retention-days: 7

Le workflow conserve le code de sortie du scan tout en exportant les résultats scellés disponibles. Le code de sortie 0 indique que la couverture du périmètre choisi est complète et que votre politique de gravité est respectée. Le code de sortie 1 indique qu’un résultat atteint le seuil. Le code de sortie 2 indique une erreur ou une couverture incomplète, y compris partielle ou inconnue. Un scan informatif au vert reste un rapport sur le périmètre sélectionné, pas un certificat de sécurité. Exports des résultats et codes de sortie.

Pour afficher le SARIF sous forme d’alertes d’analyse de code dans GitHub, ajoutez l’étape upload-sarif du modèle officiel ainsi que les autorisations correspondantes. Les dépôts publics sont pris en charge ; pour les dépôts privés et internes, GitHub Code Security doit être activé. Conserver le SARIF dans l’artefact ci-dessus permet de l’examiner sans promettre un tableau de bord gratuit pour les dépôts privés. Conditions d’utilisation du SARIF dans GitHub.

Pour GitLab, utilisez le modèle CI/CD de production d’OpenAI. Il couvre les diffs des merge requests, les scans de la branche par défaut protégée et les scans programmés à activer volontairement. L’import natif de SARIF exige GitLab Ultimate 19.2 ou une version ultérieure. Si cet accès au tableau de bord n’est pas disponible, les artefacts de rapport ordinaires constituent une autre solution.

Les exécutions CI utilisent les autorisations du runner et peuvent hériter de son environnement. Écartez du job les identifiants sans rapport avec l’analyse et utilisez des modifications du code source auxquelles vous faites confiance. Ajoutez une valeur --max-cost après avoir défini votre budget. Il s’agit d’une limite estimée, qui peut être dépassée par les requêtes déjà en cours. Prérequis CI, contrôle des coûts.

Cinq usages de l’analyse de vulnérabilités, classés par bénéfice attendu

1. Une équipe SaaS qui modifie la connexion ou les accès entre clients. Lancez l’analyse initiale, affinez le modèle de menace et activez Security Review sur ses pull requests. L’intérêt : augmenter les chances de repérer une erreur de cloisonnement entre comptes avant qu’elle touche les clients. Faites participer le responsable de l’authentification à la revue.
2. Un fondateur qui reprend une application ancienne. Analysez le dépôt une fois et attribuez les résultats retenus avant d’ajouter des fonctionnalités. Cela peut transformer une liste de problèmes inconnus en un ensemble limité de travaux étayés, plutôt qu’en une demande de réécriture globale.
3. Une équipe GitLab sans scanner de sécurité géré. Lancez les contrôles CLI sur les diffs des merge requests et conservez le SARIF et la couverture sous forme d’artefacts. Vous obtenez ainsi une trace de revue reproductible dans le système CI que l’équipe exploite déjà.
4. Une agence qui maintient plusieurs dépôts clients. Utilisez les scans en lot de la CLI, qui peuvent reprendre après interruption, et conservez pour chaque client un contexte d’architecture et un historique des résultats distincts. Cela pourrait limiter les configurations répétées et rendre la passation de maintenance plus précise. Scans en lot.
5. Une équipe dont la liste de problèmes de sécurité contient beaucoup de bruit. Utilisez le workflow de qualification du backlog de Codex Security pour confronter les résultats des scanners au code et aux contrôles actuels. L’intérêt : disposer de preuves pour déterminer quels tickets méritent du temps de développement. Gardez les scanners d’origine en service. Qualification du backlog.

Deux services à construire autour de Codex Security

L’opportunité la plus solide est un déploiement de sécurité suivi dans la durée pour les petites équipes. Un fondateur paie pour la configuration, le travail sur le modèle de menace, l’intégration CI et la qualification humaine régulière des résultats, plutôt que pour une interface de plus autour d’un bouton de scan.

Lors de cette étude, les estimations Google aux États-Unis de DataForSEO ont donné 720 recherches mensuelles pour « software vulnerability scanning » et 90 pour « code security scanner ». Ce sont des recherches, pas des clients prêts à payer. La formulation la plus large englobe aussi des travaux qui ne relèvent pas de l’analyse de dépôts. Le tarif Semgrep Code de $150 par mois pour cinq contributeurs fournit un point de comparaison concret pour un service au périmètre limité. Repère tarifaire Semgrep.

La version minimale commercialisable pourrait couvrir un dépôt appartenant au client, un modèle de menace documenté, le workflow CI et une file de résultats examinés. Utilisez les accès du client et rendez les coûts d’usage visibles. La difficulté est opérationnelle : il faut suffisamment connaître l’application pour rejeter les résultats trompeurs et examiner les correctifs sensibles. Vendre une garantie de sécurité irait au-delà de ce que les preuves permettent d’affirmer.

Une seconde piste est un dossier de preuves de sécurité à la livraison pour les agences. Une agence pourrait proposer, à chaque passation client, un état daté du périmètre analysé, des résultats retenus, des lacunes restantes et des corrections vérifiées. La requête large « vulnerability scanning tools » représente environ 1,900 recherches mensuelles aux États-Unis, mais elle mesure l’intérêt pour des outils de plusieurs domaines de sécurité. Elle étaye une hypothèse à tester auprès de clients potentiels, pas une demande pour ce produit précis.

Le MVP pourrait rassembler les artefacts de scan enregistrés et les décisions de qualification approuvées dans un rapport client concis. La difficulté tient à la portabilité et à la confiance : le SARIF se transporte, mais la valeur de votre service repose sur une interprétation honnête, y compris lorsque la couverture est incomplète. Un rapport généré seul est facile à copier. Tous les volumes de recherche sont des estimations mensuelles par mot-clé de DataForSEO, obtenues le 30 septembre 2026 ; aucun ne démontre une croissance du marché ou une intention d’achat.

Quels contrôles conserver en complément de cet audit de code ?

Conservez l’analyse des dépendances, qui contrôle les paquets et les versions importés par votre application, ainsi que la détection des secrets, qui repère les identifiants exposés. L’analyse raisonnée d’un dépôt peut examiner un problème lié à ces sujets, mais elle ne remplace ni l’inventaire complet des paquets ni le système de surveillance des identifiants.

Conservez le SAST déterministe lorsque ses contrôles étendus et reproductibles, ou vos exigences d’assurance, comptent. OpenAI indique explicitement que Codex Security complète le SAST. Vous pouvez essayer l’agent sans acheter de suite payante ; cela ne rend pas la couverture existante superflue. FAQ Cloud.

Maintenez une revue humaine du code d’autorisation. L’authentification vérifie qui vous êtes ; l’autorisation détermine à quelles données client vous pouvez accéder et quelles actions vous pouvez effectuer. Ces règles dépendent des objectifs métier et des hypothèses de déploiement qu’un scanner peut mal interpréter. Faites examiner par le responsable le cloisonnement entre clients, les permissions d’administration, les parcours de récupération et les tests de non-régression. C’est une recommandation d’ingénierie, cohérente avec le besoin d’une évaluation humaine des menaces indiqué par le fournisseur.

Encadrez aussi l’environnement de scan. Cloud utilise des conteneurs isolés ; les scans locaux et CI utilisent vos autorisations locales. Le guide de sécurité des sandbox traite de cette autre tâche : contrôler ce à quoi un agent peut accéder.

Faut-il choisir Codex ou la revue de sécurité de Claude Code ?

Restez sur Claude Code si votre besoin immédiat est de vérifier la sécurité de changements en attente et que votre équipe l’utilise déjà. Lancez /security-review localement ou configurez l’Action GitHub de revue de sécurité d’Anthropic pour publier des commentaires sur les pull requests et filtrer les faux positifs. Ces fonctions sont accessibles aux utilisateurs de Claude Code, y compris avec les abonnements payants Pro/Max et les comptes API Console. Configuration de la revue de sécurité Claude.

Choisissez Codex Security Cloud si vous recherchez un workflow associant analyse initiale gérée du dépôt, surveillance des commits, scans programmés et préparation de correctifs. Choisissez sa CLI si l’historique des résultats, les artefacts de couverture et les exports SARIF répondent à vos besoins locaux ou CI. Cette comparaison ne permet de désigner aucun gagnant en précision ou en coût.

Vérifiez la politique de filtrage des deux solutions. L’Action de revue de sécurité d’Anthropic documente des exclusions, notamment le déni de service et l’épuisement des ressources. Un risque de saturation du disque comme celui des téléversements Gogs exige donc un examen explicite de cette politique. L’Action est une offre distincte du produit Code Review hébergé de Claude. Dépôt de revue de sécurité d’Anthropic.

Lundi, confiez un dépôt à une personne responsable. Lancez l’analyse initiale, corrigez le modèle de menace, qualifiez les premiers résultats et ajoutez une CI informative avant de choisir un seuil de gravité bloquant. Consignez le coût d’usage et les lacunes de couverture non résolues avant de passer à un autre dépôt.

Pour intégrer ce workflow au processus de développement de votre équipe, je conçois des systèmes d’IA pour la production.