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 Rôles.

​
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 page de détails d’un résultat avec l’explication, le code et les informations Overview
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 fenêtre Change Decision refuse un commentaire qui se limite à false positive
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 rules (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.
La page Triage rules avec False positive et Accepted risk activés et deux règles de triage automatique
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.
Un résultat reste Open pendant qu’une demande de faux positif attend une approbation

​
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, demandeur, gravité et recommandation, 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.
La file d’approbation sur Pending, filtrée sur Waiting on me
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.

​
Examiner les demandes en groupe

Dans Pending, sélectionnez des demandes individuelles, toutes les demandes que vous pouvez examiner sur la page actuelle ou toutes celles correspondant aux filtres. Vos propres demandes sont exclues de la sélection à examiner. Choisissez Approve ou Reject, vérifiez la boîte de dialogue de confirmation et confirmez la décision. Vous pouvez envoyer la même note pour toutes les demandes ou personnaliser les notes par demande ; les notes individuelles nécessitent une sélection explicite plutôt que toutes les demandes correspondantes. Les demandes en attente soumises par un agent peuvent également être approuvées par une personne autorisée. La boîte de dialogue de confirmation identifie ces demandes avant l’application de la décision.

​
Suggestions de triage facultatives

Les suggestions de triage ne sont disponibles que si elles sont activées pour votre entreprise. Corgea peut rédiger une justification pour une sélection de faux positifs ou de risques acceptés dans le workbench ; vérifiez-la et modifiez-la avant de l’envoyer. Pour les personnes chargées de l’examen, une demande en attente peut afficher Corgea recommends avec Approve ou Reject, un indicateur de confiance et le raisonnement envoyé au demandeur. Submit recommendation applique cette suggestion. Override change la décision ou la note. Sélectionnez plusieurs demandes pour utiliser Apply suggestions, qui applique la recommandation de chaque demande sélectionnée après confirmation. Les demandes sans recommandation nécessitent toujours une décision manuelle. Les suggestions n’approuvent ni ne rejettent jamais une demande de manière autonome.
File d’approbation sur Pending, avec des recommandations Corgea pour approuver un risque accepté et rejeter un faux positif
Les nouvelles demandes soumises par une personne lancent la génération d’une suggestion d’examen après l’envoi. Les demandes soumises par un agent ne le font pas. Une demande en attente plus ancienne, encore sans suggestion, lance la génération lorsque vous ouvrez la page de l’onglet Pending qui la contient, ou lorsque vous ouvrez le résultat. Ouvrir une page ne génère pas de suggestions pour les demandes d’une autre page. Les demandeurs reçoivent les e-mails d’approbation et de rejet selon leurs préférences de notification. Les examens groupés regroupent les résultats dans un résumé par demandeur et par résultat.