1. Périmètre et éléments de revue
La mission commence par le dépôt, la branche ou le commit, les points d'entrée, le modèle de déploiement et les parcours produit dont l'abus aurait le plus d'impact. Authentification, rôles, frontières tenant, actions d'administration, fichiers, requêtes sortantes et intégrations externes sont cartographiés avant de prioriser les findings.
Seuls les actifs autorisés entrent dans le périmètre. Un accès temporaire en lecture seule ou un ZIP suffit ; les identifiants de production, données client et dumps de base ne sont pas nécessaires.
2. Modèle de menace et carte du code
La revue identifie acteurs, actifs et transitions de confiance : anonyme vers authentifié, membre vers administrateur, tenant A vers tenant B, navigateur vers API, application vers service externe et entrée non fiable vers interpréteur ou client réseau.
Routes, middlewares, accès aux données, code d'authentification et de session, désérialiseurs, uploads, webhooks et configuration sensible sont suivis jusqu'au point d'utilisation réel.
3. Cartographie automatisée et revue manuelle
L'analyse automatisée peut repérer API dangereuses, signaux de dépendances, motifs de secrets et contrôles absents. Elle sert de carte, pas de preuve. Dans l'offre expert, une personne suit les données et l'identité entre les fichiers, compare les endpoints voisins et évalue les contournements dans le contexte produit.
Le plan automatisé est présenté séparément et ne revendique pas de validation humaine.
4. Validation et sévérité
Un candidat devient un finding confirmé lorsque les preuves établissent un chemin crédible entre une entrée ou identité contrôlée et un impact. La validation peut utiliser une requête minimale, un payload, un test unitaire ou une reproduction locale sur le code soumis. Toute action dangereuse sur la production est exclue.
La sévérité combine exploitabilité et impact dans l'application cadrée. Un contrôle manquant qui franchit une frontière tenant n'est pas classé comme une simple recommandation de durcissement sans impact démontré.
5. Rapport et remédiation
Chaque finding nomme la faiblesse, le code concerné, les préconditions, l'impact, les étapes de reproduction et une direction de correction concrète. Un développeur doit pouvoir confirmer le défaut et ajouter un test de non-régression sans réinterpréter le rapport.
Le rapport consigne aussi les zones revues et les limites explicites. L'offre expert inclut un debrief et des questions directes sur les findings.
6. Limites de couverture
Une revue de code apporte des preuves sur un instantané défini ; elle ne garantit pas qu'une application est sûre. Elle ne remplace ni pentest complet black box ou infrastructure, ni audit de conformité, revue cloud opérationnelle, ingénierie sociale ou analyse du code ajouté après le commit cadré.
Le comportement à l'exécution, la configuration de production et les systèmes externes peuvent modifier le risque. Ils nécessitent un périmètre autorisé et une méthode de test adaptés.