Présentation de Codex Security en CI/CD

Choisissez une intégration CI, préparez les accès nécessaires aux analyses et décidez de l’incidence des résultats et de la couverture des analyses sur votre pipeline.

Exécutez Codex Security en CI pour examiner les modifications des pull requests ou des merge requests, analyser votre branche par défaut et conserver les résultats et la couverture. Consultez le guide de votre fournisseur CI pour connaître le workflow, la gestion des rapports et les options d’application des règles.

Préparer le workflow

L’exécution d’analyses nécessite un accès à Codex Security. Enregistrez une API key OpenAI dans le coffre de secrets de votre fournisseur CI sous le nom CODEX_SECURITY_API_KEY, puis associez-la à la variable d’environnement OPENAI_API_KEY du processus d’analyse.

N’exécutez des analyses que sur des dépôts et des modifications de confiance. Les analyses utilisent les autorisations locales du runner et ne s’interrompent pas pour demander une approbation. Placez les identifiants sans rapport avec l’analyse et les étapes de déploiement dans des jobs distincts.

Utiliser un modèle Daybreak approuvé

Pour accéder à Daybreak Blue via Trusted Access for Cyber, définissez le paramètre d’entrée de l’Action GitHub model sur gpt-6-sol et cyber-access-program sur daybreak_blue. Pour les analyses directes avec la CLI, utilisez --model gpt-6-sol et --cyber-access-program daybreak_blue.

Utilisez une API key issue d’un projet sur lequel Daybreak Blue est activé et qui a accès au modèle sélectionné. Définir le modèle ou le programme n’accorde aucun accès. Consultez Configurer l’accès facultatif à Daybreak pour connaître les paramètres de l’Action.

Choisir une intégration

Ajouter le workflow GitHub Actions

Consultez le guide GitHub Actions pour 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 du code source. Le guide couvre la configuration du runner, l’accès facultatif à Daybreak, l’envoi de SARIF et l’application des règles de sévérité.

Ajouter le pipeline GitLab CI/CD

Consultez le guide GitLab CI/CD pour les analyses des merge requests, de la branche par défaut et les analyses planifiées. Commencez par un pipeline limité à l’analyse, puis ajoutez la gestion des rapports, l’application des politiques et, si vous le souhaitez, des corrections vérifiées.

Utiliser un autre système CI

Installez le package public @openai/codex-security et exécutez directement la CLI. Utilisez --auth api-key, choisissez une analyse du dépôt ou des différences, et enregistrez la sortie dans un répertoire privé en dehors du worktree Git. Votre runner doit fournir les dépendances décrites dans le guide de démarrage rapide de la CLI.

Consultez la référence de la CLI pour les options d’analyse, les révisions à comparer, les formats de rapport, les répertoires d’état et de sortie, ainsi que le comportement des nouvelles tentatives.

Choisir une politique de sévérité

Commencez par des résultats à titre indicatif. Examinez des résultats représentatifs, la couverture des analyses, le coût et la durée d’exécution avant de décider quels résultats doivent bloquer une fusion.

Évaluez à la fois les problèmes détectés et l’exhaustivité de l’analyse. La politique de sévérité évalue les problèmes détectés par l’analyse en cours dont la sévérité atteint ou dépasse le seuil configuré. Les problèmes antérieurs encore ouverts dans le résumé du dépôt n’affectent pas cette politique. Une analyse incomplète peut laisser des zones sans examen même lorsqu’elle ne signale aucun problème.

Dans la version action-v0.3.0 de l’Action, une analyse terminée signifie que l’analyse configurée a produit un résultat valide. Les exclusions de périmètre, les investigations différées et les autres notes de couverture ne permettent pas de contourner la politique de sévérité. Les erreurs du scanner et celles liées aux rapports obligatoires font échouer le job. La CLI 0.3.0 renvoie le code de sortie 2 en cas d’échec lié aux entrées, à l’exécution, à l’intégrité des résultats ou aux sorties obligatoires. Consultez coverage.json lors de l’évaluation du résultat ; la fin de l’analyse ne garantit pas que toutes les vulnérabilités ont été détectées.

Configurez l’application des règles dans le guide GitHub Actions ou le guide GitLab CI/CD. Pour les intégrations directes de la CLI, consultez l’application des règles de sévérité et les codes de sortie.