Exécutez Codex Security dans votre pipeline CI pour examiner les modifications proposées dans les pull requests ou les merge requests, analyser votre branche par défaut et conserver la liste des problèmes détectés ainsi que les données de couverture. Consultez le guide de votre fournisseur CI pour configurer le workflow, gérer les rapports et choisir les règles à appliquer.
Préparez le workflow
Pour lancer des analyses, vous devez avoir accès à Codex Security. Enregistrez une clé API OpenAI dans le gestionnaire de secrets de votre fournisseur CI sous le nom CODEX_SECURITY_API_KEY, puis affectez sa valeur à la variable d’environnement OPENAI_API_KEY du processus d’analyse.
N’analysez que des dépôts et des modifications auxquels vous faites confiance. Les analyses s’exécutent avec les autorisations locales du runner sans s’interrompre pour demander une approbation. Réservez des jobs distincts aux identifiants sans rapport avec l’analyse et aux étapes de déploiement.
Utilisez un modèle Daybreak approuvé
Pour accéder à Daybreak Blue via le programme Trusted Access for Cyber, définissez le paramètre d’entrée model de la GitHub Action sur gpt-6-sol et cyber-access-program sur daybreak_blue. Pour lancer une analyse directement avec la CLI, utilisez --model gpt-6-sol et --cyber-access-program daybreak_blue.
Utilisez une clé API provenant d’un projet pour lequel Daybreak Blue est activé et qui a accès au modèle sélectionné. Le choix du modèle ou du programme ne suffit pas à obtenir cet accès. Consultez la section Configuration de l’accès facultatif à Daybreak pour connaître les paramètres de l’action.
Choisissez une intégration
Ajoutez le workflow GitHub Actions
Suivez le guide GitHub Actions pour configurer les vérifications des pull requests et les analyses planifiées du dépôt. L’action Codex Security installe la CLI, enregistre les rapports et ajoute un résumé du job ainsi que des annotations dans le code source. Le guide explique comment configurer le runner et l’accès facultatif à Daybreak, téléverser un rapport SARIF et appliquer un seuil de gravité.
Ajoutez le pipeline GitLab CI/CD
Suivez le guide GitLab CI/CD pour configurer les analyses des merge requests et de la branche par défaut, ainsi que les analyses planifiées. Commencez par un pipeline qui exécute uniquement l’analyse. Ajoutez ensuite la gestion des rapports, l’application des règles et, si vous le souhaitez, la correction des problèmes avec vérification des correctifs.
Utilisez un autre système CI
Installez le paquet public @openai/codex-security et exécutez directement la CLI. Utilisez --auth api-key, choisissez d’analyser le dépôt ou un diff, puis enregistrez les résultats dans un répertoire privé en dehors de l’arbre de travail Git. Votre runner doit fournir les dépendances indiquées dans le guide de démarrage rapide de la CLI.
Consultez la référence de la CLI pour connaître les options d’analyse, les révisions à comparer dans un diff, les formats de rapport, les répertoires d’état et de sortie, ainsi que le comportement en cas de nouvelle tentative.
Choisissez une politique de gravité
Dans un premier temps, utilisez les résultats à titre indicatif. Examinez un échantillon représentatif des problèmes détectés, la couverture des analyses, leur coût et leur durée avant de décider quels résultats doivent bloquer une fusion.
Tenez compte à la fois des problèmes détectés et du caractère complet de l’analyse. La politique de gravité évalue les problèmes détectés lors de l’analyse en cours dont la gravité atteint ou dépasse le seuil configuré. Les problèmes détectés précédemment qui restent ouverts dans le récapitulatif du dépôt n’entrent pas en ligne de compte. Une analyse incomplète peut laisser certaines parties du code sans examen, même si elle ne signale aucun problème.
Dans la version action-v0.3.0 de l’action, une analyse est considérée comme terminée lorsque l’analyse configurée a produit un résultat valide. La politique de gravité s’applique même si le rapport de couverture mentionne des éléments exclus du périmètre, des investigations reportées ou d’autres réserves. Le job échoue si l’outil d’analyse rencontre une erreur ou si la production d’un rapport obligatoire échoue. La version 0.3.0 de la CLI renvoie le code de sortie 2 en cas d’erreur liée aux entrées, à l’exécution, à l’intégrité des résultats ou à la production des sorties requises. Consultez coverage.json pour évaluer le résultat. Une analyse terminée ne garantit pas que toutes les vulnérabilités ont été détectées.
Pour configurer l’application de la politique de gravité, suivez le guide GitHub Actions ou le guide GitLab CI/CD. Si vous intégrez directement la CLI, consultez la section sur l’application du seuil de gravité et les codes de sortie.