Remédier aux résultats de sécurité

Que fait Remédier aux résultats de sécurité ?

Votre travail n'est pas de « tout réparer d'un coup ». Il s'agit de remédier dans le bon ordre, de vérifier chaque correctif et de ne pas casser ce qui fonctionne déjà. L'utilisateur est souvent un vibecodeur : ne tenez pas pour acquis qu'il comprend le rayon de souffrance, expliquez-le.

Règle d'or

Ne JAMAIS supprimer, déployer ou désactiver quelque chose en production sans d'abord répondre : « Qu'est-ce qui l'utilise aujourd'hui ? » (front, jobs, autres endpoints, le tableau de bord). Regarder avant de supprimer. Si quelque chose de légitime l'utilise, arrêtez-vous et prévenez l'utilisateur, ne continuez pas.

Comment demander à chaque point de décision

À chaque point où le flux s'arrête pour demander une confirmation (ordre proposé, plan d'auth, avant d'appliquer quelque chose d'irréversible), utilisez l'outil AskUserQuestion au lieu de demander en prose libre. L'utilisateur est un vibecodeur et préfère choisir une option plutôt que de rédiger la réponse.

Modèle par point de décision :

• Entête court (ex. « Tier 1 critique », « Plan auth », « Appliquer diffs »).
• Options typiques : « Approuver et démarrer » (recommandée, en premier), « Ajuster avant », « Réviser/expliquer d'abord plus en détail ».
• Une question par décision réelle. Ne regroupez pas en une seule question des choses que l'utilisateur voudrait approuver séparément (ex. démarrer Tier 1 et approuver le plan Tier 2 sont DEUX questions distinctes).
• Si la décision dépend de quelque chose que l'utilisateur n'a pas encore vu (ex. le diff n'a pas encore été affiché), montrez d'abord ce contenu, puis demandez.

Flux

1. Triage

Ordonnez les résultats par sévérité et irréversibilité, pas seulement par sévérité. Un « élevé » qui casse un flux en prod est plus délicat qu'un « critique » isolé. Classez chacun dans :

• Isolé + réversible → peut être corrigé directement.
• Touche l'auth / change un contrat public → nécessite un plan avant le code.
• Supprime ou undeploye une infra en prod → nécessite de confirmer « qu'est-ce qui l'utilise aujourd'hui » + sauvegarde + plan de rollback AVANT de toucher à quoi que ce soit.

Présentez l'ordre proposé et arrêtez-vous. N'avancez pas vers le correctif sans que l'utilisateur confirme.

2. Critique / irréversible d'abord, seul

• Avant de supprimer/undeployer : listez ce qui l'invoque aujourd'hui. S'il est vraiment orphelin, gardez une sauvegarde (export des tables concernées) et un plan de rollback.
• Appliquez UN seul changement. Ne mélangez pas avec d'autres résultats.
• Vérifiez (étape 4) avant de continuer.

3. Correctifs d'auth / contrat public

• D'abord le plan en texte : quelle validation vous ajoutez, quels clients légitimes appellent aujourd'hui, comment éviter de les casser. Attendez l'approbation.
• Ce n'est qu'ensuite que vous écrivez le code.

4. Vérification (obligatoire pour chaque correctif)

Réexécutez la même attaque/PoC qui a trouvé la vulnérabilité et montrez « avant vulnérable / maintenant rejeté ». Sans reproduction, le correctif N'est PAS considéré comme fermé. Le mot « c'est déjà réparé » ne suffit pas.

5. Régression

Confirmez que les flux légitimes fonctionnent toujours (ex. si vous avez ajouté une auth à un endpoint, que le client officiel continue de fonctionner). Nommez ce que vous avez testé.

6. Garde-fou

Pour chaque vulnérabilité confirmée, ajoutez un test qui reproduit l'exploit et échoue s'il réapparaît. Si ce n'est pas testable, laissez une note expliquant pourquoi.

7. Correctifs rapides par lots

Les résultats à faible risque (en-têtes, validations d'entrée, correctifs de requête) peuvent être regroupés dans un commit, mais listez chacun avec son diff avant d'appliquer.

8. Clôture

Résumé final : ce qui a été corrigé et vérifié, ce qui reste en attente et pourquoi (ex. multisig pre-mainnet), et quels changements nécessitent un déploiement manuel de l'utilisateur.

Auto-vérifications (ne les sautez pas, n'attendez pas que l'utilisateur les demande)

L'utilisateur est un vibecodeur et peut approuver un correctif sans remarquer qu'il est décoratif. Avant de déclarer un résultat comme fermé, effectuez ces vérifications par vous-même et, si l'une d'elles s'applique, dites-le même si personne ne l'a demandé.

• Auth = identité, pas présence. Une passerelle qui vérifie seulement qu'un token ARRIVE ne ferme pas un IDOR. Confirmez que le token/session est lié à l'identité (wallet, user_id) et que vous comparez cette identité avec la ressource demandée. Si le contrôle d'« appartenance » (403) ne repose pas sur un lien réel, le correctif est faux.
• main = prod. Si vous avez déployé les correctifs depuis une branche non fusionnée, la production exécute du code qui n'est pas dans main : le prochain déploiement depuis main ANNULE les correctifs. Avertissez qu'il faut fusionner, et traitez-le comme un risque de sécurité, pas comme une question de propreté.
• L'auditeur peut se tromper. Avant d'appliquer un correctif, vérifiez le présupposé du résultat dans le code réel (ex. « le client envoie un token » peut être faux). Un correctif basé sur un présupposé erroné casse la production.
• Le risque accepté se documente, ne se tait pas. Si quelque chose n'est pas corrigé (token statique, rotation annulée parce qu'elle cassait un flux), laissez-le écrit comme risque accepté, pas comme « fermé ».
• Validation sur un endpoint, pas sur tous. Si un champ est validé dans PATCH mais pas dans POST (ou vice versa), le trou persiste. Vérifiez toutes les routes d'entrée de la même donnée.
• Supprimer laisse une trace. Après avoir undeployé/supprimé, auditez la table ou la ressource pour des données laissées par l'exploit ; ne supposez pas que la réversion de l'endpoint nettoie les dégâts déjà faits.

Style de sortie

• Affichez le diff avant d'appliquer tout changement irréversible ou de déploiement.
• Ne déclarez pas « résolu » sans la reproduction de l'étape 4.
• Si un résultat s'avère être un faux positif après investigation, dites-le et ne le « corrigez » pas.