Comprendre les statuts et le langage de preuve GVO

Pour rester digne de confiance, un outil d'audit ne doit jamais prétendre savoir ce qu'il ne peut pas prouver. Dans l'écosystème GVO, chaque observation technique est donc qualifiée par un verdict de preuve précis.

Ce système de statuts permet de distinguer immédiatement ce qui est matériellement démontré dans votre code source de ce qui nécessite une vérification de contexte de votre part.

La Grille des Verdicts GVO

Les statuts exposés dans les rapports d'audit (GvoVerdict et GvoFindingVerdict) représentent les verdicts canoniques de l'analyse :

flowchart TD
    O[Observation Détectée] --> V{Niveau de Preuve Canonique}
    V -->|Preuve complète & chaîne observable| C[Problème confirmé\nCONFIRMED]
    V -->|Faisceau d'indices concordants| P[Risque probable\nPROBABLE]
    V -->|Zone sensible sans preuve de garde| G[Protection non démontrée\nCOVERAGE_GAP]
    V -->|Signal ambigu dépendant du contexte| T[À vérifier\nTO_VERIFY]

État projet issu de Review Memory (REVIEWED_SAFE)

Il est important de distinguer le verdict canonique de l'audit (figé dans le rapport d'exécution) de la projection de revue :

• Revue qualifiée (REVIEWED_SAFE) : ce n'est pas un verdict brut produit par le moteur lors de l'analyse initiale, mais un état accordé dans la vue projet lorsqu'une décision humaine préalable a été enregistrée et revalidée formellement par le résolveur statique sur le code actuel.
• Si le code source est modifié ultérieurement et rompt la condition de protection, la revue devient invalidée et le finding réapparaît avec son verdict canonique d'origine.

Détail de chaque statut

1. Problème confirmé (CONFIRMED)

Ce statut est réservé aux détections pour lesquelles le moteur dispose d'une preuve matérielle indiscutable dans le périmètre audité :

• Exemple : une clé secrète Stripe (sk_live_...) écrite en clair dans un composant React client avec préfixe public.
• Ce que cela signifie : la vulnérabilité existe telle quelle dans le fichier analysé.
• Ce que cela ne signifie pas nécessairement : cela n'implique pas que la faille a déjà été exploitée par un attaquant, mais que l'opportunité d'exploitation est ouverte.

2. Risque probable (PROBABLE)

Utilisé lorsque la chaîne de données présente des caractéristiques très proches d'une faille avérée, mais qu'un élément indirect (comme un helper d'emballage ou un typage partiel) laisse subsister un doute :

• Exemple : une Server Action effectue une mise à jour d'un enregistrement sans filtre explicite sur l'utilisateur courant, mais en appelant une fonction utilitaire intermédiaire.

3. Protection non démontrée (COVERAGE_GAP)

Ce verdict reflète une exigence de transparence méthodologique. Il ne signifie pas que votre application est trouée, mais que la preuve de sa protection est absente de la base de code analysée :

• Exemple : une table Supabase sensible est requêtée dans votre code TypeScript, mais aucune politique de sécurité Row Level Security (RLS) n'est définie dans les migrations locales du projet. Si vous avez configuré la RLS manuellement sur le dashboard en ligne de Supabase sans la versionner dans Git, GVO ne peut pas l'attester statiquement.
• Vous pouvez résoudre un COVERAGE_GAP en intégrant vos migrations SQL au dépôt ou en associant une preuve d'infrastructure via Review Memory.

4. À vérifier (TO_VERIFY)

Le statut À vérifier indique que le moteur a détecté un appel ou une configuration sensible qui peut être légitime selon le cas d'usage :

• Exemple : une fonction effectue une requête fetch vers un domaine externe dynamique. S'il s'agit d'un proxy de webhook délibéré, le comportement est attendu ; s'il s'agit d'un appel arbitraire déclenché par un paramètre d'URL utilisateur, il s'agit d'un risque SSRF.
• GVO vous fournit un prompt de vérification conçu pour vous aider à auditer l'intention réelle du flux.

Statut de Preuve vs Niveau de Sévérité

Il est crucial de ne pas confondre le Statut et la Sévérité d'un finding :

• La Sévérité (CRITICAL, HIGH, MEDIUM, LOW, INFO) mesure l'impact potentiel du problème sur le système s'il venait à se manifester (perte financière, vol de session, indisponibilité).
• Le Statut (CONFIRMED, PROBABLE, COVERAGE_GAP, TO_VERIFY) mesure le degré de certitude du moteur quant à la présence réelle du problème dans le code observé.

Un problème peut ainsi être de sévérité Critique tout en ayant le statut À vérifier (impact dévastateur si avéré, mais nécessité de confirmer le contexte), ou inversement de sévérité Faible tout en étant Confirmé (certitude absolue sur la présence d'un script en doublon sans impact sécuritaire majeur).