Skip to main content

​
Vue d’ensemble

Clôturer un résultat crée un enregistrement d’audit permanent. Un commentaire comme « faux positif » ou « risque accepté » ne fait que répéter la décision déjà consignée dans le statut : la personne qui lira le résultat des mois plus tard — un collègue, un nouveau responsable, un auditeur — n’en apprendra rien. Corgea examine le commentaire que vous écrivez lors d’un changement de statut et le redemande lorsqu’il n’explique pas la décision. L’exigence reste minimale : une phrase précise et vérifiable suffit.
L’exigence de justification porte sur le commentaire d’un changement de statut. Elle ne modifie pas qui a le droit de changer un statut, ce qui reste contrôlé par la permission change_issue_status. Voir Groupes de permissions.

​
Où elle s’applique

La vérification s’exécute partout où un changement de statut est enregistré :
  • La fenêtre Change Decision sur la page de détails du résultat
  • Le panneau de détails du Workbench des vulnérabilités
  • La barre d’actions de triage en masse, y compris pour les résultats SAST, SCA et IaC
  • Les rejets demandés depuis une pull request via le Corgea Agent
La réouverture d’un résultat en est exemptée. Rouvrir ne rejette rien, et n’exige donc aucune justification.

​
Ce qui fait une bonne justification

Une justification est acceptée dès qu’elle nomme au moins un élément concret et vérifiable. L’un de ces points suffit :
  • Le contrôle qui rend le code sûr : validation des entrées, échappement des sorties, requête paramétrée, contrôle d’autorisation ou garantie du framework
  • Pourquoi l’entrée est fiable ou le chemin inatteignable dans ce déploiement
  • Un contrôle compensatoire ou une raison métier justifiant d’assumer le risque, idéalement avec un responsable, une échéance ou un périmètre
  • Où le correctif a été appliqué, ou quel résultat celui-ci duplique : un commit, une pull request, un ticket ou un identifiant de résultat
  • Ce que l’analyseur a mal interprété dans le code
Exemples acceptés :

​
Ce qui est refusé

Un commentaire est renvoyé lorsqu’il n’ajoute rien à la décision elle-même : Lorsqu’un commentaire est refusé, Corgea explique ce qui manque et conserve ce que vous avez saisi pour que vous puissiez le compléter. Le statut ne change qu’une fois le commentaire accepté.
La même formule suivie d’une vraie raison convient. « Faux positif — la valeur est échappée par le moteur de templates avant d’être rendue » est accepté ; « faux positif » seul ne l’est pas.

​
Ce qui ne motive jamais un refus

La vérification regarde si une raison est donnée, pas la qualité de sa rédaction.
Une justification n’est jamais refusée en raison de sa longueur, de son orthographe, de sa grammaire, d’un ton informel ou de la langue employée. Les justifications rédigées dans n’importe quelle langue sont examinées de la même façon. Corgea ne juge pas non plus si votre raisonnement est techniquement correct — cette appréciation reste celle de votre équipe — et accepte le commentaire en cas de doute.
Si la vérification est indisponible, le commentaire est accepté et le changement de statut est appliqué. Le triage n’est jamais bloqué par une vérification hors service.

​
Clôturer un résultat depuis une pull request

Le Corgea Agent écrit le même enregistrement d’audit lorsqu’il agit sur un commentaire de pull request : il demande donc la même raison. Un commentaire qui demande de rejeter un résultat sans dire pourquoi — @Corgea false positive, accept risk, not an issue, wontfix — reçoit une demande de raison au lieu d’un changement de statut. Indiquez la raison dans le commentaire et l’agent l’enregistre :
Une raison déjà donnée plus tôt dans le même fil compte. Cela s’applique aux rejets — faux positif et risque accepté — parce qu’ils clôturent un résultat réel. Marquer un résultat comme corrigé ou en doublon depuis une pull request reste inchangé.

​
Exiger un second relecteur

Une justification explique une décision, mais à elle seule personne ne la vérifie. Les administrateurs de l’entreprise peuvent aussi exiger qu’une seconde personne approuve un rejet avant qu’il prenne effet. Activez-le dans Settings → Company → Triage approvals (ouvrir). La page comporte deux commutateurs indépendants, tous deux désactivés par défaut :
  • False positive — rejeter un résultat comme faux positif attend une approbation.
  • Accepted risk — supprimer un résultat en risque accepté attend une approbation, avec ou sans date d’expiration.
Lorsqu’une décision est activée, la prendre depuis la page de détails du résultat, le panneau du workbench ou la barre de triage en masse crée une demande au lieu de changer le statut. Le résultat conserve son statut actuel et s’affiche comme Pending approval jusqu’à ce que quelqu’un l’examine. Votre justification accompagne la demande : c’est ce que lit le relecteur.

​
Examiner les demandes

L’examen se fait depuis la file d’approbation à l’adresse /approvals/, avec les onglets Pending, Approved, Rejected et Withdrawn. Filtrez par décision, projet et demandeur, restreignez à Everyone, Waiting on me ou Mine, et recherchez par CWE, CVE, chemin, projet, justification, note du relecteur et demandeur. Les filtres figurent dans la chaîne de requête, ce qui permet de partager une vue filtrée sous forme de lien. Le relecteur doit être une personne différente du demandeur, de la même entreprise, disposant de la permission d’approuver les demandes de triage et de modifier chaque type de résultat présent dans la demande. L’approbation comme le rejet peuvent porter une note facultative, et les demandeurs peuvent retirer leurs propres demandes.
Les personnes autorisées à approuver des demandes sont exemptées de leur propre contrôle : mettre leur décision dans la file reviendrait à leur demander de s’approuver elles-mêmes, elle s’applique donc immédiatement. Les administrateurs de l’entreprise voient toutes les demandes de la file ; les autres ne voient que celles qu’ils ont soumises.
Chaque étape — la demande, l’approbation ou le rejet, l’éventuelle note du relecteur et un retrait — est consignée dans l’historique du résultat.