Constats, priorisation et triage

Où se trouvent les constats : les onglets Repo, SCM, Cloud, Registry et App Pentest

Chaque résultat de scanner dans Plexicus est converti dans un format de constat commun, puis enrichi de correspondances et de scores, ainsi que d’un verdict de l’IA lorsqu’AI False-Positive Detection est activée. Tout aboutit sur une seule page : Findings . Cette page est divisée en cinq onglets, un pour chaque type d’actif que vous pouvez tester.

Onglet	Ce que vous y trouvez	Provenance de l’actif
Repo	Les constats de code issus des scans de dépôts : faiblesses du code, dépendances vulnérables, secrets codés en dur, ainsi que configurations d’infrastructure as code ou de conteneurs déclarées dans le dépôt	Assets, Repo Scan
SCM	Les constats de posture portant sur la configuration de votre gestion de code source plutôt que sur le code qu’elle contient	Votre fournisseur de gestion de code source connecté
Cloud	Les constats sur la configuration des comptes cloud, les identités et les accès, ainsi que les ressources exposées, vérifiés au regard de référentiels	Assets, Cloud Assessment
Registry	Les constats sur les images de conteneurs découvertes dans vos registres connectés, filtrables par image, tag et connexion au registre	Assets, Registry Audit
App Pentest	Les constats produits par les exécutions d’AI Pentest, avec les preuves et le chemin d’attaque qui les ont démontrés	La section Pentest

Une injection SQL dans un gestionnaire de connexion apparaît sous Repo, tout comme une image de base vulnérable déclarée dans le Dockerfile d’un dépôt. Une bibliothèque système vulnérable présente dans une image stockée dans votre registre de conteneurs connecté apparaît sous Registry. Une IDOR dans une API de factures, reproduite par l’AI Pentest contre votre cible autorisée, apparaît sous App Pentest. Dans l’interface du produit, AI Swarm Pentest s’affiche sous le nom « AI Pentest », dans la section Pentest.

Ce que partagent tous les onglets

Les onglets partagent un même tableau, un même système de filtres et une même vue détaillée : les compétences de triage de ce module s’appliquent donc partout. Les champs propres à un seul type d’actif, comme Region pour les constats cloud, sont masqués dans les onglets où ils ne s’appliquent pas.

Pour les scans natifs, le champ Tool indique le moteur Plexicus qui a produit le constat, par exemple plexicus-sast ou plexicus-iac ; les résultats importés indiquent le format d’origine de l’import, par exemple sarif. Le module 3 présente les moteurs disponibles et ce que couvre chacun d’eux.

Fonctions supplémentaires de l’onglet Repo

L’onglet Repo propose deux commandes supplémentaires dans sa barre d’outils :

• Upload Scan importe les résultats d’un scanner externe dans le dépôt de votre choix. Il accepte SARIF 2.1.0 et plusieurs formats de scanners commerciaux, et les constats importés arrivent dans l’onglet Repo, à côté des constats natifs.
• Add Repository lance le même parcours que sous Assets : vous pouvez ainsi ajouter un dépôt sans quitter Findings.

Columns to show vous permet d’ajouter et de réordonner des colonnes du tableau, comme Priority, Reachability, EPSS, CWE, Issue Owner ou Confidence. La disposition est enregistrée pour chaque utilisateur.

Anatomie d’un constat

Cliquez sur n’importe quelle ligne pour ouvrir le constat dans un panneau de détail, au-dessus de la liste. Appuyez sur K ou J pour passer au constat précédent ou suivant sans fermer le panneau.

Le bandeau d’en-tête affiche Severity, CVSS 3.1, Priority, EPSS, Reachability, Internet path et Occurrences. En dessous viennent les sections Code & taint trace (Evidence & attack path pour les constats de pentest), AI verdict, Risk & exposure, Exposure, Compliance & OWASP, Activity (lorsque votre rôle permet de consulter la piste d’audit) et Metadata & notes. Risk & exposure contient aussi un scénario d’attaque généré par l’IA ; vérifiez-le au regard de la trace avant d’agir en conséquence.

Référence : les signaux d’un constat

Champ	Ce qu’il vous indique	Comment le lire
Severity (scanner)	La sévérité brute signalée par l’outil	Critical, High, Medium, Low ou Informational
Severity	La sévérité après validation par l’IA	Peut dépasser d’un niveau au maximum le libellé du scanner. Un verdict de faux positif de l’IA l’abaisse à Informational sans modifier la sévérité du scanner. Comparez les deux sous « Severity — scanner vs AI ».
Priority	L’urgence du constat dans votre contexte, de 0 à 100	Combine la sévérité et l’impact avec l’exploitabilité (EPSS, ou une estimation de l’IA). Fortement minorée lorsque le code n’est pas atteignable, légèrement lorsque l’atteignabilité est inconnue, et atténuée par une faible confiance. Les scores de 90 et plus s’affichent en rouge. Le score provient d’une formule fixe, et non d’un jugement de l’IA ; les faiblesses à fort impact comme l’injection SQL, l’injection de commandes OS, la traversée de répertoires, la SSRF et les identifiants codés en dur reçoivent un bonus.
AI confidence	Dans quelle mesure les signaux s’accordent sur la réalité du constat, de 0 à 100	Low en dessous de 40, Medium de 40 à 74, High à partir de 75. Un badge « Estimated » signifie qu’elle a été déduite de la sévérité, et non mesurée.
Reachability	Si le code vulnérable est effectivement atteint	Reachable, Not reachable, Unknown reachability ou N/A
Internet path	Si une route publique atteint la charge de travail concernée	exposed, ou none (None found sous Risk & exposure). Modifie la priorité, jamais la sévérité.
Section Exposure	Les contrôles de déploiement exécutés par l’analyse d’exposition pour la charge de travail	Une pastille indique Exposed, Not exposed ou Not analyzed yet ; le module 5 explique comment la lire conjointement avec Internet path
EPSS	La probabilité que la vulnérabilité soit exploitée en conditions réelles	Renseigné uniquement pour les constats associés à une CVE ; sinon « No data »
CVSS	Le score de sévérité standard et son vecteur	CVSS 3.1 dans le bandeau ; v3 et v4 en colonnes et en filtres. Peut porter la mention estimated (AI) ou estimated (severity).
CWE / OWASP	La classe de faiblesse et sa catégorie OWASP Top 10	Correspondance établie automatiquement à partir de la CWE, avec une brève justification, ainsi qu’avec l’OWASP CI/CD Top 10 et les contrôles de conformité que vous avez activés
Issue Owner	Le développeur auquel le code est attribué	Renseigné à partir du blame du fichier concerné dans votre SCM ; les filtres l’appellent « Assigned to »
Class	Problème exploitable ou observation de posture	Vulnerability ou Hardening
Occurrences	Le nombre d’instances existantes	Compte les instances du même problème dans le dépôt

L’atteignabilité en pratique

Pour un constat de dépendance, Reachable signifie que le symbole vulnérable est appelé depuis le code de votre application. Pour un constat de code, cela signifie qu’un flux de données allant de la source au sink a été confirmé. Unknown peut comporter un suffixe : « transitive » lorsque l’atteignabilité ne peut pas être confirmée pour une dépendance transitive, ou « evaluation error » lorsque la vérification a échoué et sera relancée.

Lire la trace de propagation

La section Dataflow & Taint Trace affiche des étapes numérotées intitulées Source, Propagation et Sink, avec la mention Cross-File lorsqu’une étape passe d’un fichier à un autre. Pour une injection SQL dans un gestionnaire de connexion, la source pourrait être le paramètre username, une étape de propagation la fonction utilitaire qui le concatène dans une chaîne de requête, et le sink l’appel de requête brute. Chaque étape porte un badge de provenance : Scanner dataflow, AI-verified ou AI-inferred (unverified). Le panneau n’affiche un chemin que lorsque sa source et son sink sont vérifiés par rapport au dépôt. Une trace vide signifie qu’aucun chemin vérifié n’existe encore, ou que ni AI False-Positive Detection ni une règle de scanner en mode taint n’en a produit pour ce constat. Le module 5 explique comment ces traces sont construites.

Statuts et cycle de vie d’un constat

Le statut d’un constat indique où il en est dans le workflow de remédiation. Tant que l’enrichissement par l’IA est en cours, un nouveau constat est masqué dans la liste par défaut. Cette étape n’a pas de libellé propre ; un constat ouvert directement affiche déjà AI-Analysed. Les libellés que vous voyez sont les suivants :

Statut	Signification	Comment un constat y arrive
AI-Analysed	L’enrichissement est terminé : les scores et les correspondances sont en place, ainsi que le verdict de l’IA si AI False-Positive Detection est activée	Prêt pour votre triage
Needs Input	Le modèle de remédiation a besoin d’informations de votre part	Le bouton de remédiation propose Enter details
Ready to Fix	Une remédiation a été générée, ou le constat a été envoyé aux développeurs	Après la génération d’une remédiation, ou après Send to Dev Team
Fix Submitted	Une pull request (une merge request sur GitLab) a été ouverte avec le correctif	Après la soumission d’une remédiation à votre SCM
Issued	Une issue a été créée pour le constat	Utilisé lorsque le type de remédiation est Issue
Fixed	Le correctif a été intégré	Le webhook de votre SCM signale que la pull request de remédiation a été fusionnée ou que l’issue associée a été fermée

Le passage à Fixed dépend de votre équipe : ce sont vos relecteurs qui décident s’il faut fusionner, et à quel moment.

Les indicateurs qui accompagnent le statut

Faux positif. Un constat peut être jugé non réel de deux façons. AI False-Positive Detection est un paramètre d’organisation facultatif, sous Settings Platform , désactivé par défaut et disponible selon votre offre ; il exécute une passe d’IA après chaque scan. Vous pouvez aussi trancher vous-même avec Mark as false positive dans le panneau de détail du constat. Un marquage humain ferme les pull requests de correctif ouvertes pour ce constat, supprime ses remédiations générées, met à jour les compteurs du dépôt et enregistre le verdict comme humain. Il ouvre également une pull request qui ajoute un commentaire de suppression en ligne pour cette règle, sans consommer votre quota d’utilisation de l’IA (module 7). Le verdict n’est mémorisé qu’au sein de votre organisation : les scans ultérieurs neutralisent automatiquement la même règle lorsqu’elle se déclenche sur du code structurellement identique. Avec les rôles intégrés, Admin et Cyberoper peuvent marquer des faux positifs ; les utilisateurs ayant le rôle Developer ne le peuvent pas.

Revert false positive annule ce marquage : le constat revient à AI-Analysed et sa Severity est réinitialisée à la sévérité du scanner. Les faux positifs sont masqués dans la liste par défaut ; conservez donc un lien vers tout constat que vous pourriez devoir réexaminer.

Les verdicts automatisés font l’objet de contrôles supplémentaires avant de masquer un constat, mais ne considérez pas ces contrôles comme une garantie. Si votre organisation active AI False-Positive Detection, convenez de la manière dont les verdicts de l’IA portant sur des constats Critical, High, atteignables ou exposés sont revus par un humain. Un constat encore en attente de revue de faux positif ne peut pas encore faire l’objet d’une remédiation, et le bouton de remédiation vous l’indique.

Mitigated. Mark as mitigated active l’indicateur Mitigated Externally du constat. Utilisez-le lorsque le risque est traité en dehors du code, par exemple par une règle WAF. Il ne modifie pas le statut du workflow, et le constat reste dans votre liste. Une fois l’action utilisée, le bouton disparaît et l’indicateur ne peut pas être annulé dans la console : assurez-vous donc de votre choix avant de cliquer. Plexicus n’a pas de statut distinct d’acceptation du risque ou de mise en veille ; consignez la mesure compensatoire dans votre ticket.

Doublon et sous-constat. Ces indicateurs sont définis par Plexicus, pas par vous. Les doublons sont expliqués ci-dessous, dans « Nouvelle détection », et les sous-constats dans la leçon suivante.

Demande de revue

Lorsque le statut d’un constat est Ready to Fix, un utilisateur ayant le rôle Developer voit Request review dans le panneau de détail. Cette action envoie une notification Review Request, et les relecteurs retrouvent ces demandes sous Notifications Review Requests , accessible depuis la cloche de l’en-tête.

Nouvelle détection

Un nouveau constat situé dans le même dépôt, le même fichier et à la même ligne, avec la même CVE ou le même type de constat, est marqué comme doublon (Duplicate) du constat antérieur, et le constat conservé garde la sévérité la plus élevée des deux. Selon la configuration de votre organisation, un scan ultérieur qui détecte un constat Fixed ou Issued peut le rouvrir : le constat repasse par l’analyse et est enregistré comme rouvert.

Re-Scan sous Assets Repo Scan efface les constats d’un dépôt ainsi que leurs statuts (module 2) ; utilisez Relaunch scan dans l’Activity Center pour les conserver. Les marquages de faux positifs effectués par des personnes sont mémorisés et appliqués de nouveau lorsque le même code, inchangé, est scanné.

Lorsque votre rôle permet de consulter la piste d’audit, la section Activity du constat en retrace l’historique, du plus récent au plus ancien : changements de statut, remédiations générées, créées ou mises à jour, demandes de remédiation groupée et exports, chacun attribué à Pipeline ou à User.

Trouver ce qui compte : pastilles, barre de requête, filtres, vues et filtre IA

Personne ne lit tous les constats. La barre d’outils vous offre cinq façons de faire passer les bons en premier.

La barre de requête et les pastilles de triage

La barre de requête recherche dans les titres des constats, les CVE, les paquets et les fichiers. À côté, les pastilles Triage appliquent des filtres en un clic, chacune avec un compteur en temps réel : Critical, High, Medium, Reachable, EPSS ≥ 0.5, Vulnerability et New 7d. Combiner Critical, High et Reachable permet de voir rapidement le travail réel et urgent. New 7d affiche ce qui est arrivé au cours des sept derniers jours. Les pastilles Reachable, EPSS, Vulnerability et New 7d ajoutent leur condition au filtre déjà actif : elles affinent la vue actuelle au lieu de la remplacer.

Les pastilles de sévérité filtrent sur Severity (scanner) ; pour filtrer sur la valeur validée par l’IA, utilisez Severity dans All filters.

Filtres groupés

All filters ouvre la fenêtre Filters, où les champs sont regroupés selon la question à laquelle ils répondent :

• What to look at first : Severity, Severity (scanner), Priority, Finding confidence, Class et Finding status
• Real risk : Reachable, EPSS, CVSS v3, CVSS v4 et Occurrences
• Weakness type : CWE, CVE, OWASP Top 10, Type et Category
• Compliance : Regulation, Control et Control category, limités aux réglementations activées par votre organisation
• Where it lives : Repository, File, Language et autres champs de localisation similaires
• Dependencies : Library et Library version
• Scanner : Tool, Rule et Provider
• Team & flow : Assigned to, Tags, Remediation type et Fixing effort
• Container registry : les champs relatifs aux images, affichés dans l’onglet Registry

Chaque valeur peut être incluse ou exclue. Cliquez sur le nom de champ d’une pastille dans la barre de requête pour basculer son opérateur entre is et is not, ou entre in et not in. Le bouton d’application indique « View N findings » et son compteur se met à jour au fil de vos réglages : vous n’appliquez donc jamais un filtre à l’aveugle.

Vues enregistrées et liens partagés

Une fois un filtre au point, enregistrez-le : Findings Views Save view , donnez-lui un nom, par exemple « Triage quotidien », puis cliquez sur Save. Appliquer ensuite une vue enregistrée ne demande qu’un clic. L’URL contient toujours le filtre actuel : Copy link partage donc exactement la même vue avec un collègue.

Le filtre IA en langage naturel

Selon votre offre, l’icône en forme de baguette magique dans la barre de requête ouvre « Describe what you want to see ». Saisissez une demande telle que « critical injection findings in the payments repo from the last week » et cliquez sur Build filter. Plexicus transforme la phrase en filtre structuré. Chaque demande consomme une conversion de filtre IA. Les conversions disposent de leur propre quota mensuel, distinct du quota d’utilisation de l’IA sur lequel s’imputent les correctifs et l’analyse des faux positifs. Vérifiez le filtre généré avant d’agir sur les résultats, et enregistrez-le comme vue pour le réutiliser.

Ce qui est masqué par défaut, et pourquoi

La liste par défaut masque cinq types de constats :

• Les faux positifs, parce qu’ils sont jugés non réels
• Les doublons, parce que le constat conservé les représente déjà
• Les sous-constats : les constats de dépendance portant sur la même bibliothèque, la même version et la même CVE au même emplacement sont regroupés sous un constat principal, et corriger le constat principal les corrige également. Le détail d’un sous-constat affiche Go to Parent Finding.
• Les constats supprimés
• Les constats encore en cours d’enrichissement, parce que leur priorité et le verdict de l’IA ne sont pas encore prêts

Les constats non atteignables ne sont jamais masqués par défaut. L’atteignabilité abaisse leur priorité, mais un verdict statique est un indice, et non une preuve d’absence de risque : le constat reste donc visible. Si vous souhaitez les exclure d’une vue particulière, filtrez vous-même sur Reachable.

Agir sur les constats : responsables, tickets, remédiation, rapports et exports

Le triage ne porte ses fruits que lorsque chaque constat important aboutit à un responsable et à une prochaine étape.

Responsables

Le champ Issue Owner de chaque constat de code provient du blame du fichier concerné dans votre SCM. Utilisez le filtre « Assigned to » pour constituer la file d’un développeur ou vérifier la charge d’une personne.

Pour confier explicitement du travail aux développeurs, sélectionnez des constats et utilisez Send to Dev Team. Cette action s’applique aux constats qui disposent déjà d’une remédiation générée : ils sont attribués aux utilisateurs ayant le rôle Developer, passent à Ready to Fix et enregistrent qui a demandé la revue. Les utilisateurs ayant le rôle Developer ne voient que les constats qui leur sont attribués.

Actions groupées et rôles

Les actions groupées nécessitent au moins deux lignes sélectionnées, et ce que vous voyez dépend de votre rôle :

Rôle	Actions groupées
Admin	Remediate, Send to Dev Team, Create Pull Request
Cyberoper (opérateur sécurité)	Remediate, Send to Dev Team
Developer	Create Pull Request, activé uniquement lorsque la sélection comprend un constat Ready to Fix

Tickets

Dans l’en-tête du panneau de détail, Create Ticket propose les intégrations de ticketing actives de votre organisation : Jira ouvre un formulaire de ticket, ServiceNow crée un incident et Webhook envoie le constat au webhook d’issues que vous avez configuré. Si rien n’est configuré, le menu renvoie vers la page des intégrations de ticketing. Le module 9 explique comment les configurer.

Lancer la remédiation

Chaque constat a un type de remédiation. Pull request désigne une modification de code ; le bouton indique Create AI Remediation. Issue est utilisé lorsqu’il n’y a aucune ligne source à modifier, pour les artefacts malveillants et pour les fournisseurs sans pull requests ; le bouton indique Create Issue. Le lien de pied de page « Open in », suivi du nom de votre fournisseur et du numéro de ligne, mène directement au fichier dans votre SCM.

Les constats Cloud et SCM n’ont pas de bouton de remédiation, car il n’y a aucun fichier de dépôt à modifier. Un constat Registry propose Remediate in repo dès que son image est liée à un dépôt source.

Pour traiter plusieurs constats à la fois, sélectionnez-les et choisissez Remediate. Plexicus les regroupe par dépôt, et vous indiquez si vous voulez Automatically create pull requests ainsi que le mode de pull request à utiliser (Single PR ou One PR per remediation, le mode par défaut). Le module 7 explique ces deux modes et le panneau Bulk remediation status. La remédiation par IA est décomptée de votre quota d’utilisation de l’IA.

Dans les deux cas, Plexicus prépare une modification soumise à revue et ne pousse jamais rien en production ; votre équipe garde la maîtrise de la fusion. Le module 7 traite la remédiation en détail.

Rapports et exports

Votre besoin	Ce qu’il faut utiliser	Ce que vous obtenez
Un rapport partageable de la vue actuelle	Download, puis PDF	Généré en arrière-plan ; un message temporaire indique « We’ll email you when it’s ready », puis une notification Report Ready suit
Des constats lisibles par une machine	Download, puis JSON	Un fichier SARIF 2.1.0 (findings.json) correspondant à l’onglet et aux filtres actuels, téléchargé immédiatement. Par défaut, il ne contient que les constats au statut AI-Analysed (module 8).
Un seul constat pour un ticket ou une revue	Download report, dans le panneau de détail	Ce constat sous la forme d’un document SARIF
L’inventaire de vos dépôts	Download, sous Assets, Repo Scan	repositories.csv

Les deux exports de liste respectent l’onglet et les filtres actifs. Les exports JSON sont consignés dans la piste d’audit. La lecture des constats via l’API REST est traitée dans le module 9.

Mesurer les progrès sur le Dashboard

Le module 2 a présenté les onglets et les filtres du Dashboard ; cette leçon porte sur les widgets qui suivent les progrès du triage. Le triage est une habitude quotidienne, et Dashboard vous indique s’il porte ses fruits.

Ce que comptent les totaux

Les totaux du Dashboard reflètent le travail encore ouvert. Ils excluent les doublons, les sous-constats, les faux positifs, les constats supprimés et les constats déjà marqués Fixed. Les constats de durcissement (Hardening) sont comptés à part des chiffres de vulnérabilités. C’est pourquoi une bonne semaine de triage fait baisser les chiffres : marquer des faux positifs et fusionner des correctifs retirent tous deux des constats du décompte des constats ouverts.

Les widgets qui répondent à la question « Progressons-nous ? »

Widget	Onglet	Ce qu’il affiche
Risk Posture Score	CISO	Un score de 0 à 100 (plus il est élevé, plus la situation est dégradée), calculé à partir des constats ouverts pondérés par sévérité, les constats atteignables pesant davantage. Il affiche une ligne d’appétence au risque, une tendance et une indication telle que « Fix N findings to reach appetite ». La ligne d’appétence est fixe pour le moment et ne peut pas être configurée.
New vs Fixed	CISO	Les constats créés par jour, comparés aux constats ayant atteint Ready to Fix, Fix Submitted, Issued ou Fixed, datés selon leur remédiation
Top Risky Repositories	CISO	Les dépôts classés selon un score de risque calculé à partir de la sévérité et de l’EPSS de leurs constats, avec une flèche de tendance. L’infobulle affiche le score et le nombre de constats Critical et High. Il s’agit d’un instantané de la situation actuelle : le filtre de dépôt s’applique, mais pas la plage de dates.
MTTR / Remediation Velocity	DevSecOps	Deux courbes en jours : Time to attempt, de la date d’un constat jusqu’au lancement d’une remédiation, et Time to fix, de cette remédiation jusqu’à son achèvement
Aging Buckets	DevSecOps	Les constats ouverts par sévérité, répartis en quatre tranches d’ancienneté : moins de 7 jours, 7 à 30 jours, 30 à 90 jours, et 90 jours ou plus
Reachability Split	DevSecOps	Les constats par sévérité, répartis entre Reachable, Unreachable et Unknown

Parmi les autres widgets figurent Total Findings, Supply Chain, Internet exposure, Scanner Coverage et les vues OWASP. Dans Total Findings, Prioritized Vulnerabilities compte les constats ouverts dont la priorité est de 80 ou plus.

Lire le MTTR

Les deux courbes du MTTR révèlent des goulets d’étranglement différents. Un Time to attempt long signifie que les constats attendent avant que quiconque ne commence un correctif : c’est un problème de triage ou d’attribution. Un Time to fix long signifie que des remédiations ont été lancées mais mettent longtemps à aboutir ; comparez-le au Time to attempt pour savoir si le travail stagne avant ou après le lancement d’une remédiation.

New vs Fixed compare les arrivées aux constats ayant reçu une remédiation. Si New reste au-dessus de Fixed pendant des semaines, la remédiation ne suit pas le rythme des nouveaux constats.

Plexicus n’assure aucun suivi de SLA ni d’échéances ; utilisez Aging Buckets et le MTTR pour voir combien de temps les constats restent ouverts.

Points clés à retenir

• Les constats se répartissent dans cinq onglets (Repo, SCM, Cloud, Registry et App Pentest) qui partagent un même tableau, un même système de filtres et une même vue détaillée.
• La sévérité indique à quel point un constat pourrait être grave ; le score de priorité de 0 à 100 indique son urgence dans votre contexte, ajustée par l’exploitabilité, l’atteignabilité, la confiance et l’exposition.
• Les statuts vont d’AI-Analysed à Fixed. Faux positif et Mitigated Externally sont des indicateurs, et un marquage humain de faux positif peut être annulé.
• Les faux positifs, les doublons, les sous-constats, les constats supprimés et les constats encore en cours d’enrichissement sont masqués par défaut. Les constats non atteignables voient seulement leur priorité abaissée.
• Enregistrez vos meilleurs filtres sous forme de vues, partagez-les avec Copy link, et donnez à chaque constat important un responsable, un ticket ou un correctif soumis à revue.
• Les totaux du Dashboard ne comptent que le travail encore ouvert. Utilisez New vs Fixed, le MTTR, Aging Buckets et Risk Posture Score pour suivre vos progrès.