Trouver des bogues

Analysez les changements de cette branche pour identifier les bogues, les vulnérabilités de sécurité et les problèmes de qualité de code.

Phase 1 : Collecte complète des informations

1. Obtenez la DIFF complète : git diff $(gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name')...HEAD
2. Si la sortie est tronquée, lisez chaque fichier modifié individuellement jusqu'à avoir vu chaque ligne modifiée
3. Listez tous les fichiers modifiés dans cette branche avant de continuer

Phase 2 : Cartographie de la surface d'attaque

Pour chaque fichier modifié, identifiez et listez :

• Toutes les entrées utilisateur (paramètres de requête, en-têtes, corps, composants d'URL)
• Toutes les requêtes de base de données
• Tous les contrôles d'authentification/autorisation
• Toutes les opérations de session/état
• Tous les appels externes
• Toutes les opérations cryptographiques

Phase 3 : Liste de vérification de sécurité (vérifiez CHAQUE élément pour CHAQUE fichier)

• [ ] Injection : injection SQL, commande, template, en-tête
• [ ] XSS : Toutes les sorties dans les templates correctement échappées ?
• [ ] Authentification : contrôles d'auth sur toutes les opérations protégées ?
• [ ] Autorisation/IDOR : accès contrôlé vérifié, pas seulement l'auth ?
• [ ] CSRF : opérations modifiant l'état protégées ?
• [ ] Conditions de concurrence : TOCTOU dans les patterns lecture-puis-écriture ?
• [ ] Session : fixation, expiration, drapeaux sécurisés ?
• [ ] Cryptographie : aléa sécurisé, algorithmes appropriés, pas de secrets dans les logs ?
• [ ] Divulgation d'informations : messages d'erreur, logs, attaques temporelles ?
• [ ] DoS : opérations illimitées, rate limits manquants, épuisement des ressources ?
• [ ] Logique métier : cas limites, violations de machine d'état, débordement numérique ?

Phase 4 : Vérification

Pour chaque problème potentiel :

• Vérifiez s'il est déjà géré ailleurs dans le code modifié
• Cherchez les tests existants couvrant le scénario
• Lisez le contexte environnant pour confirmer que le problème est réel

Phase 5 : Audit pré-conclusion

Avant de conclure, vous DEVEZ :

1. Lister chaque fichier que vous avez examiné et confirmer que vous l'avez lu complètement
2. Lister chaque élément de la liste de vérification et noter si vous avez trouvé des problèmes ou confirmé que c'est bon
3. Lister les domaines que vous N'avez PAS pu vérifier complètement et pourquoi
4. Ensuite seulement fournir vos conclusions finales

Format de sortie

Priorisez : vulnérabilités de sécurité > bogues > qualité de code

Ignorez : problèmes de style/formatage

Pour chaque problème :

• Fichier:Ligne - Brève description
• Sévérité : Critique/Haute/Moyenne/Basse
• Problème : Ce qui ne va pas
• Preuve : Pourquoi c'est réel (pas déjà corrigé, pas de test existant, etc.)
• Correction : Suggestion concrète
• Références : OWASP, RFC ou autres standards si applicable

Si vous ne trouvez rien de significatif, dites-le - n'inventez pas de problèmes.

Ne faites pas de modifications - signalez simplement les résultats. Je déciderai de ce qu'il faut corriger.