Review Memory : la mémoire de qualification déterministe

Dans les cycles de développement modernes, l'un des plus grands irritants des outils d'analyse de code est la répétition des mêmes alertes d'un audit à l'autre sur des points que l'équipe d'ingénierie a déjà examinés, compris et qualifiés comme sûrs.

La réponse habituelle des scanners classiques consiste à proposer un bouton « Ignorer » (Dismiss). Or, masquer aveuglément une alerte crée une dette de sécurité majeure : si le code évolue demain et que la protection disparaît, l'alerte reste ignorée à jamais.

Review Memory est le système développé par GVO pour résoudre ce dilemme. Il s'agit d'un mécanisme de qualification persistante et de revalidation statique déterministe.

Le Principe Fondamental : Fail-Closed et Zéro Magie

flowchart TD
    F[Finding signalé à l'audit N] --> Q[1. Qualification avec justification technique]
    Q --> S[(Persistance dans Review Memory)]
    S --> A[2. Audit N+1 sur nouveau commit]
    A --> R{3. Revalidation statique du code actuel}
    R -->|Condition de protection toujours vérifiée| OK[Statut REVIEWED_SAFE dans le projet]
    R -->|Code modifié ou condition rompue| KO[Review INVALIDATED : Finding redevient actif !]

Review Memory repose sur trois règles inviolables :

1. Un commentaire ou une annotation de code n'est jamais une preuve : inscrire // ignore dans un fichier ne trompe pas le moteur.
2. Revalidation statique déterministe à chaque analyse : pour qu'une décision passée reste appliquée, le moteur ré-analyse le fichier source lors de chaque nouvel audit. Si la condition technique (allowlist d'hôtes, assainisseur HTML, garde de session) n'est plus démontrable, la décision est immédiatement invalidée.
3. Le rapport canonique reste immuable : l'audit brut scellé au moment du commit conserve son intégrité d'origine. Review Memory intervient comme une couche de projection sécurisée lors de la restitution sur votre espace projet.

Les motifs de qualification autorisés (Reason Codes)

Pour éviter les déclarations de conformité arbitraires, Review Memory encadre les justifications possibles à travers des contrats de qualification stricts par famille de règles :

1. Sur les flux réseau et SSRF

• FIXED_EXTERNAL_HOST : la destination réseau est codée en dur vers un point de terminaison tiers fixe et audité.
• STRICT_HOST_ALLOWLIST : le domaine est validé dynamiquement contre une liste stricte d'adresses autorisées.
• PRIVATE_NETWORK_GUARD : une barrière réseau explicite bloque les adresses privées (RFC 1918), boucles locales (localhost, 127.0.0.1) et plages réservées.

2. Sur l'injection de contenu et XSS

• SANITIZED_HTML : la donnée injectée passe obligatoirement par un assainisseur DOM reconnu (ex. DOMPurify) avant d'atteindre le composant.
• SAFE_JSON_LD : les balises de données structurées appliquent un échappement Unicode strict neutralisant la rupture de balise script.
• STATIC_CONFIGURATION : le contenu affiché provient exclusivement d'une configuration statique interne sans aucune origine utilisateur.

3. Sur l'authentification et les mutations

• OWNERSHIP_GUARD_PRESENT : le contrôle d'appartenance utilisateur (user_id) et la session serveur sont formellement validés avant l'écriture.
• UPSTREAM_AUTH_GUARD : la session est contrôlée en amont dans un middleware bloquant ou un layout serveur parent.
• RLS_POLICY_EXTERNAL : la protection au niveau des lignes est garantie et auditée directement sur la base PostgreSQL distante.

Exemple concret : de l'alerte à la qualification revalidée

Prenons un cas pratique réaliste sur un appel réseau sortant :

1. L'Observation initiale : GVO détecte un appel fetch(url) dans une route API et émet le finding GVO-SEC-SSRF-HOST-CONTROL-V3 avec le statut À vérifier.
2. L'Analyse de l'ingénieur : vous inspectez le fichier et constatez que l'URL est vérifiée quelques lignes plus haut par une fonction personnalisée qui n'autorise que api.fournisseur-agree.com.
3. La Soumission de qualification : depuis l'interface de l'audit, vous cliquez sur « Importer qualification ». Le payload de review enregistre le code motif STRICT_HOST_ALLOWLIST, l'identifiant du dépôt et l'empreinte contextuelle du code.
4. Le Résultat immédiat : sur votre tableau de bord projet, le finding bascule dans la catégorie Reviewé Sûr (REVIEWED_SAFE). Vos compteurs de risques sont mis à jour sans masquer l'historique technique.
5. Le Comportement au prochain commit :
   • Si un collègue refactorise la route tout en conservant la validation d'hôte, GVO revalide le contrat : la review reste active (VALID).
   • Si une modification supprime accidentellement la vérification d'hôte, GVO constate lors de l'audit suivant que le contrat n'est plus rempli : la review est marquée INVALIDATED et le finding réapparaît immédiatement comme un problème critique actif.

Review Memory n'est pas un système basé sur l'IA

Il est primordial d'écarter toute confusion :

• GVO n'utilise aucun modèle de langage pour approuver ou revalider une review.
• Review Memory ne repose sur aucun entraînement opaque, aucun prompt probabiliste et aucune décision floue.
• La persistance est assurée dans votre base sécurisée (tables dédiées de votre espace de travail) et la revalidation est exécutée par le moteur de parsing statique d'AST de GVO.

C'est cette rigueur mathématique qui garantit que votre conformité technique est vérifiable, traçable et défendable lors de tout audit de sécurité externe ou réglementaire.