Comprendre un finding GVO

Un finding (ou observation technique) est le résultat unitaire produit par l'évaluation d'une règle du catalogue GVO sur votre application. Il signale un comportement, une omission ou un schéma de code qui mérite votre attention.

GVO adopte une approche pragmatique de l'ingénierie : un finding ne doit jamais être une alerte anxiogène sans explication, mais une opportunité concrète de durcir l'architecture de votre projet.

Anatomie d'une carte de finding

Dans l'interface de rapport (/audit/[id]), chaque finding est structuré de manière uniforme pour faciliter sa lecture rapide :

flowchart TD
    F[Carte de Finding] --> E[1. En-tête : Titre, Sévérité, Domaine, Verdict]
    F --> C[2. Explication : Pourquoi c'est important & Ce qu'il faut faire]
    F --> P[3. Preuves : Emplacement précis, Ligne, Extrait Terminal]
    F --> A[4. Action : Prompt IA 1-Click Fix & Qualification]

1. Titre & Badges d'état

• Titre explicite : une description formulée en français sans jargon cryptique (ex. « Une information secrète semble exposée dans le code » ou « Un appel externe peut rester bloqué trop longtemps »).
• Badge de Sévérité :
  • Critique (rouge) : risque de compromission directe, de fuite de données massive ou de faille financière.
  • Élevé (orange) : absence de contrôle d'accès sur une mutation, injection potentielle, blocage de service.
  • Moyen (ambre) : manque de robustesse, politique trop permissive, absence de timeout réseau.
  • Faible / Info (zinc) : bonne pratique d'hygiène, code mort, optimisation recommandée.
• Badge de Domaine : Sécurité, Authentification, Données, Paiements, Fiabilité, Performance, Santé du code, etc.
• Badge de Statut / Niveau de Preuve : Problème confirmé, Risque probable, Protection non démontrée, ou À vérifier. Consultez le guide des Statuts GVO pour leur interprétation.

2. Le double bloc pédagogique

Lorsque vous dépliez la carte, deux sections vous guident immédiatement :

• Pourquoi c'est important : contextualise le risque métier. Pourquoi devez-vous vous en préoccuper ? Quelles peuvent être les conséquences en production (blocage serveur, surcoût API, vol de session) ?
• Ce qu'il faut faire : résume l'action corrective recommandée (ex. restreindre le schéma de validation, injecter un AbortSignal.timeout, déplacer la clé dans une variable privée serveur).

3. Extraits de code et preuves techniques

La section repliable « Extraits de code & preuves » présente la justification matérielle de la détection :

• Le chemin exact du fichier dans votre arborescence et le numéro de ligne.
• Un bloc de code terminal sombre affichant la ligne ou la fonction exacte interceptée par le moteur statique.
• Si le même problème se répète sur plusieurs fichiers ou lignes, les occurrences secondaires sont listées de manière synthétique pour éviter les redites.
• Si le signal est partiel, un encart indique les preuves manquantes qui empêchent le moteur de conclure avec une certitude absolue.

4. Le lien « Voir dans le Wiki »

Lorsqu'un finding correspond à une problématique architecturale documentée, un lien « Voir dans le Wiki » apparaît à côté du titre :

• Le Finding vous montre où et comment le problème apparaît précisément dans vos fichiers.
• Le Wiki vous explique le concept général en profondeur (ex. les mécanismes fondamentaux du Cross-Site Scripting, du SSRF ou de la signature des webhooks Stripe), avec des architectures recommandées et les erreurs courantes.

Méthode en 5 étapes pour traiter un finding

Pour corriger efficacement vos observations, suivez cette démarche méthodique :

[1. Lire le problème] ──► [2. Regarder la preuve] ──► [3. Évaluer le statut] ──► [4. Vérifier le contexte] ──► [5. Décider de l'action]

1. Lire l'intitulé et le contexte : identifiez la nature de la ressource concernée (route API, composant client, Server Action).
2. Examiner l'extrait de code : visualisez la ligne ciblée pour vérifier comment la variable ou la fonction est employée.
3. Consulter le niveau de preuve : si le statut est Confirmé, le risque est matériellement observable dans le code. S'il est À vérifier, examinez si une protection existe en amont (ex. middleware de routage).
4. Valider la logique métier : vérifiez si l'usage observé correspond à une intention légitime de votre produit.
5. Appliquer l'action adaptée :
   • Si le code doit être corrigé : copiez le Prompt de correction IA et soumettez-le à votre assistant (Cursor, Claude, Copilot).
   • Si la protection est assurée par une contrainte externe démontrable : utilisez le bouton « Importer qualification » pour l'enregistrer dans Review Memory.

Finding ≠ Vulnérabilité Exploitable Immédiate

Il est fondamental de maintenir une rigueur d'ingénierie : un finding n'est pas toujours synonyme d'intrusion immédiate.

• Une analyse de code statique relève des signaux observables. Par exemple, l'absence de vérification explicite d'un tenant sur une requête en base de données déclenche un finding d'autorisation.
• Cependant, si cette route n'est accessible qu'au travers d'un réseau privé interne ou protégée par une règle CDN spécifique non déclarée dans le dépôt, le risque réel en production peut être atténué.
• Inversement, ne minimisez jamais un signal sous prétexte que votre application n'a pas encore beaucoup d'utilisateurs : les attaquants et robots automatisés scannent les nouvelles applications dès leur mise en ligne.