Trier un backlog

Examinez les constats de sécurité existants à la lumière d’un dépôt et classez les travaux de suivi par ordre de priorité.

Utilisez $codex-security:triage-finding pour examiner les constats de sécurité existants à la lumière du dépôt actuel. Ce workflow effectue une analyse statique en lecture seule : Codex traite chaque constat comme une affirmation non prouvée et examine les éléments probants du dépôt sans exécuter le code.

Exécutez ce workflow depuis un projet Codex limité au dépôt que vous souhaitez évaluer. Codex doit pouvoir lire le code source du dépôt. Les connecteurs Jira et Linear peuvent fournir les données des constats, tandis que les constats GitHub nécessitent un accès GitHub REST authentifié. Aucun de ces accès ne remplace l’accès au code source.

Cette approche diffère de $codex-security:validation, qui peut compiler ou exécuter du code, créer un test ou une preuve de concept, ou solliciter une interface réelle pour reproduire ou réfuter un constat. Utilisez le triage pour classer et hiérarchiser un backlog existant. Utilisez la validation lorsque des preuves d’exécution peuvent trancher un constat que les preuves statiques laissent incertain.

Choisir les constats à trier

Vous pouvez fournir un constat ou un ensemble provenant des sources suivantes :

Source Éléments à fournir Prérequis
Constats collés ou locaux Résultats SARIF, CVE ou GHSA, avis de sécurité, ticket d’un outil d’analyse, rapport de bug bounty, artefact de constat Codex Security ou signalement de vulnérabilité en langage courant. Aucun connecteur requis.
Jira ou Linear URL ou identifiants exacts de tickets de sécurité ou de vulnérabilité, requête Jira JQL, ou équipe, projet ou expression de recherche Linear. Codex récupère le contenu des tickets sélectionnés avant le triage. Jira via Atlassian Rovo ou Linear avec accès en lecture.
GitHub Un dépôt et une source de constats : analyse de code, vulnérabilités et logiciels malveillants Dependabot, avis de sécurité et rapports de vulnérabilité privés, ou 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 est disponible. Les GitHub Issues ne sont pas incluses par défaut. Fournissez un ticket précis ou demandez explicitement les GitHub Issues. Accès authentifié à l’API REST de GitHub, par exemple via gh auth token, GH_TOKEN ou GITHUB_TOKEN, avec l’autorisation de lire le dépôt et le type de constat sélectionnés.

Codex conserve un résultat pour chaque constat fourni, dans l’ordre d’entrée, afin que chaque constat source reste traçable. Il ne fusionne ni ne supprime les constats qui semblent être des doublons.

Exécuter un triage en lecture seule

Pour les constats collés ou les artefacts locaux, envoyez une invite comme celle-ci :

Use $codex-security:triage-finding to triage these existing security findings against this repository:

[Paste the findings or provide the artifact path.]

Pour les tickets Jira ou Linear, identifiez l’ensemble de tickets et maintenez le système source en lecture seule :

Use $codex-security:triage-finding to import and triage the security findings from [Jira or Linear issue URLs, identifiers, or query] against this repository.
Do not change the source issues.

Pour les constats GitHub, indiquez le dépôt et la source :

Use $codex-security:triage-finding to import and triage [code scanning, Dependabot vulnerabilities and malware, security advisories and private vulnerability reports, or all] from [owner/repository] against this repository.

Pour utiliser le dépôt GitHub associé au projet Codex actuel, indiquez uniquement la source des constats :

Use $codex-security:triage-finding to import and triage [code scanning, Dependabot vulnerabilities and malware, security advisories and private vulnerability reports, or all] from GitHub against this repository. Use the GitHub repository attached to the current Codex project.

Codex vérifie le code source actuel et la politique SECURITY.md applicable, puis renvoie un verdict pour chaque constat fourni. Il consigne les éléments qui étayent ou réfutent le signalement, ainsi que les questions non résolues.

Examiner les résultats

Verdict Signification
confirmed Les éléments du dépôt montrent que le chemin vulnérable est accessible dans les conditions préalables indiquées et franchit une frontière de sécurité prise en charge.
not_actionable Les éléments du dépôt réfutent l’affirmation, par exemple en démontrant une version non affectée, un chemin inaccessible, une protection efficace ou une surface non distribuée.
needs_review Les éléments du dépôt ne suffisent pas pour trancher, car les informations requises sont manquantes, ambiguës ou dépendent de l’exécution, de l’environnement ou des règles applicables.

Utilisez les classements pour décider quels constats confirmed corriger en premier et quels constats needs_review examiner en priorité. Chaque groupe est classé séparément.

Lisez la justification du verdict en parallèle du code concerné et des conditions préalables nécessaires à l’attaquant. Vérifiez les éléments qui réfutent le signalement et les questions ouvertes avant d’agir selon le classement. Ici, confirmed signifie que le constat est étayé par des preuves statiques tirées du dépôt, sans avoir été reproduit par l’exécution de l’application.

Les entrées Jira, Linear et des autres backlogs restent inchangées, sauf si vous demandez à Codex de les mettre à jour après avoir examiné les résultats du triage.

Étapes suivantes

  • confirmed : Une fois qu’une personne a accepté le constat en vue de sa correction, utilisez $codex-security:fix-finding pour le corriger et le vérifier. Le triage prépare un relais prêt à servir de prompt, mais n’invoque pas le skill automatiquement.
  • needs_review : Si l’exécution du code peut combler la lacune de preuve, utilisez $codex-security:validation pour tester le constat sur du code en cours d’exécution. Transmettez le signalement, les emplacements concernés, les conditions préalables, les preuves statiques et les lacunes de preuve figurant dans le résultat du triage :
  Use $codex-security:validation to dynamically validate finding [triage item ID or source ID] from the backlog triage result. Reproduce or disprove the finding, record what you tested, and list any remaining uncertainty.

Contrairement au triage, la validation peut compiler ou exécuter du code, créer un test ou une preuve de concept, ou solliciter une interface réelle. Consultez les politiques d’approbation et de sécurité de Codex pour connaître les contrôles d’exécution.

  • needs_review : Si le constat dépend de la politique produit ou du contexte de déploiement, répondez aux questions ouvertes répertoriées avant de modifier le code.
  • not_actionable : Conservez les preuves avec votre dossier de triage. Codex ne ferme pas et ne met pas à jour automatiquement le ticket source.
  • Pour rechercher des vulnérabilités au-delà du backlog fourni, exécutez une analyse de sécurité.