Trier un backlog

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.

En arrière-plan, Codex part du code ou des informations de version cités. Il retrace la source présumée contrôlée par l’attaquant, les contrôles de sécurité pertinents, le point d’exploitation dangereux et le chemin accessible. Il vérifie également la surface du produit et la frontière de confiance, recherche les éléments contradictoires et consigne les lacunes dans les preuves. Codex renvoie ensuite un verdict pour chaque constat et classe ceux qui nécessitent une action ou un examen supplémentaire.

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

Choisir les constats à trier

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

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.

Le workflow suit cet ordre :

1. Recueillir et organiser les constats

   Codex récupère tout contenu demandé provenant d’un ticket ou de GitHub, conserve les identifiants et références de la source, puis crée un élément de triage pour chaque entrée. Il établit la liste complète des éléments avant d’attribuer les verdicts.

2. Confirmer le contexte du dépôt

   Codex détermine le dépôt et la révision actuels lorsqu’ils sont disponibles. Il lit SECURITY.md lorsqu’il est présent, afin que les versions prises en charge, les entrées de confiance, les limites du produit et les surfaces hors périmètre éclairent l’évaluation.

3. Examiner les éléments statiques

   Pour chaque constat, Codex retrace la source présumée contrôlée par l’attaquant, le contrôle de sécurité pertinent, le point d’exploitation vulnérable, le chemin accessible et la frontière de sécurité prise en charge. Il consigne les éléments étayant l’affirmation, ceux qui la contredisent et les lacunes dans les preuves.

4. Attribuer les verdicts et les rangs

   Codex attribue un verdict et un niveau de confiance à chaque constat. Il classe les constats confirmed et needs_review selon leur exploitabilité dans des files distinctes.

Examiner les résultats

Pour chaque constat, examinez :

• la justification du verdict et du rang
• les éléments étayant l’affirmation et ceux qui la contredisent
• les questions ouvertes et les lacunes restantes dans les preuves
• l’emplacement et le composant affectés
• la surface du produit et le niveau de confiance de la source
• la prochaine étape recommandée
• la transmission $codex-security:fix-finding, lorsque le constat est confirmed

Le triage est terminé lorsque chaque constat fourni possède un résultat, que Codex conserve son identifiant source et que toute incertitude est explicite. Les enregistrements Jira, Linear et des autres backlogs restent inchangés, sauf si vous demandez à Codex de les mettre à jour après avoir examiné les résultats du triage.

Étapes suivantes

• confirmed : après qu’une personne a accepté la correction du constat, utilisez $codex-security:fix-finding pour le corriger et le vérifier. Le triage prépare une transmission prête à servir d’invite, mais n’appelle pas automatiquement la skill.

• needs_review : si l’exécution du code peut combler la lacune dans les preuves, utilisez $codex-security:validation pour effectuer une validation dynamique délimitée. Transmettez l’affirmation du constat, les emplacements affectés, les conditions préalables, les éléments statiques et les lacunes dans les preuves provenant du résultat du triage :

  Use $codex-security:validation to dynamically validate finding [triage item ID or source ID] from the backlog triage result. Use the strongest realistic, bounded method, record exactly what was tested, and preserve any remaining proof gaps.

  Contrairement au triage, la validation peut compiler ou exécuter du code, créer un test ciblé ou une preuve de concept, ou utiliser une interface réelle. Examinez les commandes proposées avant de les approuver et maintenez les règles d’approbation et de sécurité de Codex en vigueur.

• needs_review : si le constat dépend des règles du produit ou du contexte de déploiement, répondez aux questions ouvertes répertoriées avant de modifier le code.

• not_actionable : conservez les éléments probants avec votre enregistrement de triage. Codex ne ferme ni ne met automatiquement à jour le ticket source.

• Pour rechercher des vulnérabilités au-delà du backlog fourni, lancez une analyse de sécurité.