Revue de code orientée sécurité (secure code review)
Description
Grille pour évaluer une revue de code : identification de vulnérabilités, gravité, correctifs et patterns sécurisés.
Contexte d'application
Module Secure Coding ou DevSecOps sur un dépôt vulnérabilisé ou un diff fourni.
Critères et rubrics
Couverture des risques
25 %Injection, auth, secrets, dépendances, logique métier.
Insuffisant
Seulement style ou bugs fonctionnels.
Acceptable
Quelques OWASP Top 10 repérés.
Bon
Couverture large avec priorités.
Excellent
Menaces contextuelles (abus métier, race conditions) identifiées.
Justification et exploitabilité
25 %Scénarios d'abus, préconditions, impact.
Insuffisant
Findings sans contexte d'exploitation.
Acceptable
Impact décrit qualitativement.
Bon
PoC textuelle ou pseudo-code d'abus.
Excellent
Chaîne d'attaque réaliste + facteurs atténuants existants.
Recommandations de correction
25 %Patch, refacto, lib, configuration.
Insuffisant
« Il faut valider les entrées » sans détail.
Acceptable
Correctifs génériques par famille de faille.
Bon
Snippets ou patterns sécurisés proposés.
Excellent
Correctif minimal + tests de régression sécurité suggérés.
Processus et outillage
15 %SAST/DAST, revue par pairs, secrets scanning.
Insuffisant
Revue manuelle uniquement sans méthode.
Acceptable
Outils cités sans intégration au flux dev.
Bon
Intégration CI/CD ou checklist OWASP ASVS évoquée.
Excellent
Politique de branches, approbations, et gates qualité sécurité.
Clarté du rapport
10 %Lisibilité pour l'équipe produit.
Insuffisant
Ton accusateur ou jargon opaque.
Acceptable
Correct mais dense.
Bon
Sévérité + effort de fix par finding.
Excellent
Format adapté dev (diff comments + synthèse RSSI).
Questions fréquentes
Comment utiliser cette grille avec un barème sur 20 ?
Attribuez une note partielle par critère selon le niveau (insuffisant à excellent), ou convertissez chaque critère en points proportionnels à son poids. Les pourcentages indiqués sur la grille servent de guide de pondération.
Cette grille convient-elle à une évaluation en groupe ?
Oui pour les parties méthodologie et documentation ; pour l'exécution technique, précisez si la note est collective ou individualisée (ex. contribution traçable dans le dépôt Git ou le rapport).
Comment lier cette évaluation au reste du cours ?
Référencez les objectifs pédagogiques du module dans le brief, et annoncez la grille avant le TP pour éviter les surprises. Un court auto-contrôle à remplir par les étudiants améliore la qualité des rendus.