Utilisez $codex-security:triage-finding pour vérifier les signalements de sécurité existants à partir du code du dépôt actuel. Ce workflow effectue une analyse statique en lecture seule. Codex traite chaque signalement comme une hypothèse à vérifier et examine les éléments du dépôt sans exécuter le code.
Lancez ce workflow depuis un projet Codex dont le périmètre correspond au dépôt à évaluer. Codex doit pouvoir lire le code source du dépôt. Les connecteurs Jira et Linear peuvent fournir les données des signalements. Pour récupérer les signalements GitHub, Codex doit disposer d’un accès authentifié à l’API REST de GitHub. Dans tous les cas, l’accès au code source reste nécessaire.
Le workflow $codex-security:validation, lui, peut compiler ou exécuter du code, créer un test ou une preuve de concept, ou encore tester une interface réelle pour reproduire le problème signalé ou réfuter le signalement. Utilisez le tri pour classer les signalements en attente par catégorie et par priorité. Utilisez la validation lorsque les observations à l’exécution pourraient lever un doute que l’analyse statique laisse subsister.
Le tri porte sur des signalements existants. Pour rechercher de nouvelles vulnérabilités dans le dépôt, lancez une analyse de sécurité. Le tri ne modifie pas le dépôt et n’applique aucun correctif.
Choisissez les signalements à trier
Vous pouvez fournir un ou plusieurs signalements provenant des sources suivantes :
| Source | Éléments à fournir | Prérequis |
|---|---|---|
| Signalements collés ou fournis dans un fichier local | Des résultats SARIF, une référence CVE ou GHSA, un avis de sécurité, un ticket issu d’un outil d’analyse, un rapport de bug bounty, un artefact de signalement Codex Security ou une description de la vulnérabilité présumée en langage courant. | Aucun connecteur requis. |
| Jira ou Linear | Les URL ou les identifiants exacts des tickets de sécurité ou de vulnérabilité, une requête JQL pour Jira, ou une équipe, un projet ou des termes de recherche pour Linear. Codex récupère le contenu des tickets sélectionnés avant le tri. | Jira via Atlassian Rovo ou Linear avec un accès en lecture. |
| GitHub | Indiquez un dépôt et choisissez une source de signalements : analyse du code, vulnérabilités et logiciels malveillants détectés par Dependabot, ou avis de sécurité et rapports privés de vulnérabilité. Vous pouvez aussi sélectionner toutes les sources. Si vous ne précisez pas de dépôt, Codex utilise le dépôt GitHub associé au projet Codex actuel, s’il y en a un. Les issues GitHub sont exclues par défaut. Indiquez une issue précise ou demandez explicitement à inclure les issues GitHub. |
Un accès authentifié à l’API REST de GitHub, par exemple via gh auth token, GH_TOKEN ou GITHUB_TOKEN, avec les autorisations de lecture nécessaires pour le dépôt et le type de signalement sélectionnés. |
Codex conserve un résultat par signalement, dans l’ordre fourni, pour que vous puissiez retrouver le signalement d’origine. Il ne fusionne ni ne supprime les signalements qui semblent faire doublon.
Lancez le tri en lecture seule
Pour des signalements collés dans le prompt ou des artefacts locaux, envoyez un prompt de ce type :
Utilisez $codex-security:triage-finding pour trier les signalements de sécurité existants ci-dessous à partir du code de ce dépôt :
[Paste the findings or provide the artifact path.]Pour les tickets Jira ou Linear, indiquez les tickets à traiter et précisez que le système source doit rester en lecture seule :
Utilisez $codex-security:triage-finding pour importer les signalements de sécurité correspondant à [Jira or Linear issue URLs, identifiers, or query], puis triez-les à partir du code de ce dépôt.
Ne modifiez pas les tickets d’origine.Pour les signalements GitHub, indiquez le dépôt et la source :
Utilisez $codex-security:triage-finding pour importer les signalements de la source [code scanning, Dependabot vulnerabilities and malware, security advisories and private vulnerability reports, or all] depuis le dépôt [owner/repository], puis triez-les à partir du code de ce dépôt.Pour utiliser le dépôt GitHub associé au projet Codex actuel, indiquez uniquement la source des signalements :
Utilisez $codex-security:triage-finding pour importer depuis GitHub les signalements correspondant à la sélection suivante : [code scanning, Dependabot vulnerabilities and malware, security advisories and private vulnerability reports, or all]. Triez-les à partir du code de ce dépôt. Utilisez le dépôt GitHub associé au projet Codex actuel.Codex examine le code source actuel et la politique de sécurité applicable dans SECURITY.md, puis rend un verdict pour chaque signalement fourni. Il consigne les éléments qui étayent le signalement, ceux qui le contredisent et les questions en suspens.
Examinez les résultats
| Verdict | Signification |
|---|---|
confirmed |
Les éléments du dépôt montrent que le chemin d’exécution vulnérable est accessible dans les conditions indiquées et qu’il franchit une frontière de sécurité couverte par la politique applicable. |
not_actionable |
Les éléments du dépôt permettent d’écarter le signalement. Par exemple, la version utilisée n’est pas touchée, le chemin d’exécution est inaccessible, une protection est efficace ou la partie du produit concernée n’est pas distribuée. |
needs_review |
Les éléments du dépôt ne permettent pas de trancher. Certaines informations nécessaires manquent, sont ambiguës ou dépendent des conditions d’exécution, de l’environnement ou de la politique applicable. |
Utilisez les classements pour décider quels signalements confirmed corriger en priorité et quels signalements needs_review examiner en premier. Chaque groupe fait l’objet d’un classement distinct.
Lisez la justification du verdict en examinant le code concerné et les conditions que doit réunir un attaquant. Avant de suivre l’ordre de priorité, confrontez les éléments recueillis au signalement et examinez les questions en suspens. Ici, confirmed indique que l’analyse statique du dépôt étaye le signalement. Ce verdict ne signifie pas que le problème a été reproduit en exécutant l’application.
Les tickets Jira et Linear ainsi que les autres entrées du suivi restent inchangés, sauf si vous demandez à Codex de les mettre à jour après avoir examiné les résultats du tri.
Étapes suivantes
-
confirmed: Une fois qu’une personne a validé la prise en charge du signalement, utilisez$codex-security:fix-findingpour corriger le problème et vérifier le correctif. Le tri prépare les informations à transmettre sous forme de prompt, sans lancer automatiquement le skill. -
needs_review: Si l’exécution du code peut apporter les preuves manquantes, utilisez$codex-security:validationpour vérifier le signalement en exécutant le code. Transmettez les informations issues du tri : le problème signalé, les emplacements concernés, les conditions préalables, les éléments recueillis par l’analyse statique et les preuves qui manquent encore.Utilisez $codex-security:validation pour vérifier à l’exécution le signalement [triage item ID or source ID] figurant dans les résultats du tri. Reproduisez le problème signalé ou réfutez le signalement, consignez ce que vous avez testé et indiquez les incertitudes qui subsistent.Contrairement au tri, la validation peut compiler ou exécuter du code, créer un test ou une preuve de concept, ou tester une interface réelle. Consultez les politiques d’approbation et de sécurité de Codex pour connaître les contrôles qui encadrent l’exécution.
-
needs_review: Si le signalement dépend de la politique du produit ou du contexte de déploiement, répondez aux questions en suspens relevées lors du tri avant de modifier le code. -
not_actionable: Conservez les éléments recueillis avec le compte rendu du tri. Codex ne ferme ni ne met à jour automatiquement le ticket d’origine. -
Pour rechercher d’autres vulnérabilités que celles déjà signalées, lancez une analyse de sécurité.