Ajoutez Codex Security à votre pipeline

Choisissez l’exemple correspondant à votre plateforme CI. Suivez-le pour installer la CLI de Codex Security et fournir une clé API via le gestionnaire de secrets de votre plateforme CI.

Choisissez votre point de départ :

• GitHub Actions : utilisez le workflow pour les pull requests pour analyser les changements proposés et conserver les résultats.
• GitLab CI/CD : consultez le guide du pipeline pour configurer les analyses des merge requests, celles de la branche par défaut et les analyses planifiées. Le guide fournit un pipeline téléchargeable et précise les options à activer.
• Autres plateformes CI : adaptez les commandes d’analyse et d’export du guide Exécutez Codex Security en CI aux déclencheurs, au gestionnaire de secrets et aux mécanismes de récupération du code et de gestion des artefacts de votre plateforme.

Configurez le déclencheur et le périmètre de l’analyse

Lorsque des changements arrivent sur main, analysez le dépôt à la révision correspondant au commit envoyé. Planifiez aussi des analyses régulières sur la branche de votre choix. Commencez par une analyse hebdomadaire, puis ajustez la fréquence selon l’activité du dépôt, la durée des analyses et leur coût.

Pour les pull requests et les merge requests, récupérez l’historique de la branche cible et de la branche source. Analysez le diff entre leur base de fusion et le commit proposé.

Configurez chaque tâche pour qu’elle analyse le code voulu : le dépôt entier pour les analyses planifiées et les commits envoyés sur main, ou les changements proposés pour les pull requests. Suivez l’exemple de votre plateforme pour configurer l’analyse correspondante.

Fixez un budget adapté au périmètre et à la fréquence des analyses. L’analyse du dépôt entier peut prendre plus de temps et coûter plus cher que celle d’un diff. L’option --max-cost limite le coût sur la base d’une estimation, sans garantir un plafond de dépenses strict. Si l’analyse atteint cette limite, la couverture peut être incomplète.

Exécutez le pipeline et examinez les résultats

Soumettez la modification du pipeline à votre procédure de revue habituelle, puis lancez une analyse. Vérifiez la révision ciblée et le périmètre de l’analyse dans les détails de l’exécution et dans scan-manifest.json.

Examinez les problèmes signalés et les éléments qui les étayent dans les rapports enregistrés. Consultez coverage.json pour repérer les parties du code dont l’analyse est incomplète ou a été reportée, même si aucun problème n’a été signalé. Vérifiez la durée d’exécution et le coût avant d’augmenter la fréquence des analyses ou de les étendre à d’autres dépôts.

Conservez les rapports sous forme d’artefacts CI. Adaptez les droits d’accès et la durée de conservation des artefacts au code source et aux éléments de preuve qu’ils contiennent.

Vous pouvez exporter les résultats au format SARIF, un format structuré de signalement des problèmes de sécurité, pour les afficher dans l’interface de sécurité de votre plateforme. Consultez le guide de la plateforme pour connaître les versions prises en charge, les permissions nécessaires et les exigences en matière de licence.

Décidez si les problèmes signalés doivent bloquer la fusion

Commencez par examiner les problèmes signalés sans bloquer les fusions. Une fois votre équipe familiarisée avec les résultats, vous pouvez exiger que les pull requests réussissent un contrôle de sécurité avant la fusion. Vous pouvez, par exemple, bloquer la fusion si l’analyse détecte une vulnérabilité de gravité élevée ou critique.

Vérifiez systématiquement si l’analyse est allée à son terme et quelles parties du code elle a couvertes. Si l’analyse a échoué ou ignoré une partie du code, examinez la cause, même si aucun problème n’a été signalé.

Pour plus de détails sur la configuration, consultez la section Configurez les seuils de gravité et interprétez les résultats de l’analyse.

Assurez le suivi des problèmes signalés

Suivez la procédure habituelle de votre équipe pour attribuer chaque problème à la personne chargée de l’examiner ou de le corriger. Indiquez le commit analysé, le code concerné et les éléments qui étayent le signalement pour qu’un autre développeur puisse mener l’enquête.

Vérifiez les correctifs avant de clore les signalements. Si la couverture est incomplète, lancez une nouvelle analyse pour couvrir les parties manquantes.