Modifier une application de formation à la sécurité aux failles voulues sans casser ses défis

## Distinguer les défis voulus des failles accidentelles Traitez une application de formation intentionnellement vulnérable différemment d’une application de production ordinaire. Certains comportements non sécurisés constituent un contenu pédagogique délibéré, tandis que d’autres faiblesses sont des défauts involontaires. - Avant de le modifier, déterminez si le comportement concerné est un défi prévu, une infrastructure de soutien ou une vulnérabilité accidentelle. - Ne supprimez, n’affaiblissez ni n’ajoutez aucun comportement de défi sur la seule base d’une suggestion automatisée. - Les nouvelles vulnérabilités et les nouveaux défis nécessitent l’approbation des responsables de maintenance et une documentation claire. - Confirmez qu’un défi proposé est distinct, résoluble, fonctionnel et adapté aux objectifs d’apprentissage. - Préservez les indices, les métadonnées et les parcours de résolution du défi, ainsi que les commentaires liés à la sécurité qui expliquent une intention non évidente. - Examinez le code généré avec un regard critique. L’auteur de la contribution et la personne chargée de la revue restent responsables de la correction, de la sécurité et de la valeur pédagogique. Lorsque l’intention n’est pas claire, retracez le chemin d’exécution, les tests, les métadonnées du défi et les artefacts de correction répliqués avant de décider ce qui doit changer. ## Planifier une modification qui règle un seul problème Commencez par repérer le composant pertinent, retracer son flux de données et trouver les modèles d’implémentation et de test établis. 1. Définissez l’unique problème que la modification doit résoudre. 2. Identifiez les artefacts de serveur, de client, d’API, de données, de modèle, de configuration et de défi affectés par ce problème. 3. Recherchez du code similaire et suivez les modèles actuels du dépôt. 4. Examinez les implications pour la sécurité avant l’implémentation. 5. Proposez des tests qui distinguent le comportement prévu des régressions. 6. Excluez de la même contribution les nettoyages sans rapport et les modifications insignifiantes. Consultez les responsables de maintenance avant de créer des défis, de modifier l’architecture ou de changer le modèle de dépendances. Vérifiez toute mise à jour de paquet par rapport à chaque manifeste de dépendances et plage de versions d’exécution pertinents. N’ajoutez pas d’options de configuration ni de dépendances spéculatives sans besoin démontré ni preuve de compatibilité. Travaillez à partir de la branche d’intégration désignée du dépôt en utilisant une branche de fonctionnalité ciblée. Faites référence à l’issue concernée et limitez la contribution à un seul objectif cohérent. ## Retirer le superflu généré par l’IA et passer le linter Nettoyez la sortie automatisée avant la revue. Supprimez les commentaires verbeux qui ne font que reformuler un code évident, les espaces réservés génériques, les docstrings excessives pour les fonctions simples, les explications répétitives, les journaux de débogage et les autres résidus générés. Conservez les commentaires qui expliquent une logique complexe, l’intention du défi, les contraintes de sécurité ou une solution de contournement nécessaire. Exécutez l’outil de linting du dépôt pour chaque modification de code, sauf si la modification se limite à de la documentation explicitement exemptée par le dépôt. Le code généré doit suivre les mêmes règles de style que le code écrit manuellement. - Corrigez les échecs de linting au lieu de supposer que la suggestion est correcte. - Ne conservez pas du code inutile simplement parce qu’un assistant l’a généré. - Vérifiez dans le diff l’absence de changements de formatage étendus et de modifications de fichiers sans rapport. - Utilisez des noms clairs et des commentaires concis qui aideront les futurs responsables de maintenance à comprendre l’intention. - Veillez à ce que la documentation et le texte du commit décrivent la modification réelle plutôt que le processus de l’assistant. ## Lancer les tests qu’exige chaque type de modification Les exigences de test dépendent de la partie modifiée, mais la confiance d’un assistant ne remplace jamais l’exécution. - Ajoutez ou mettez à jour les tests unitaires de la logique modifiée. - Exécutez des tests d’intégration de l’API lorsque le traitement des requêtes, la persistance, l’autorisation ou le comportement des réponses change. - Exécutez des tests unitaires frontend pour les composants et services côté client. - Exécutez des tests de bout en bout pour les défis nouveaux ou modifiés et les comportements entre plusieurs couches. - Exécutez la suite de tests complète du dépôt avant la soumission, sauf si le dépôt exempte explicitement la documentation modifiée. - Vérifiez manuellement le flux visible par l’utilisateur ou le parcours de résolution du défi. - Exécutez le filet de sécurité de refactorisation des défis chaque fois qu’un code source existant lié à un défi change. Utilisez la plus petite suite ciblée pendant les itérations, puis exécutez la matrice requise complète avant la revue. Consignez les commandes et les résultats exacts. Ne revendiquez pas de réussite sur la seule base d’une analyse statique et ne sautez pas une suite lente parce que le code généré semble plausible. ## Garder le code des défis et ses fichiers de correction synchronisés Le code source lié à un défi peut être répliqué dans des extraits, des corrections attendues, des métadonnées ou des artefacts du filet de sécurité mis en cache. Une refactorisation est incomplète si ces représentations divergent. 1. Exécutez le filet de sécurité de refactorisation des défis du dépôt après avoir modifié du code lié à un défi. 2. S’il échoue, examinez chaque différence signalée au lieu d’actualiser immédiatement le cache. 3. Déterminez si la différence est une régression involontaire ou une partie intentionnelle de la modification. 4. Pour une refactorisation intentionnelle, appliquez la modification équivalente aux artefacts de correction et extraits correspondants. 5. Ne mettez à jour le cache des différences approuvées qu’une fois le code source, le comportement du défi et les artefacts répliqués cohérents. 6. Réexécutez le filet de sécurité et le flux de défi pertinent. N’utilisez jamais une mise à jour du cache pour dissimuler des différences inexpliquées. Tout comportement de défi nouveau ou modifié exige aussi une preuve de bout en bout que le défi reste accessible, résoluble et correctement détecté. ## Passer les traductions par la plateforme approuvée et faire les dernières vérifications Ne modifiez pas directement les fichiers de localisation générés ou gérés à l’extérieur. Soumettez les modifications de traduction via la plateforme de localisation approuvée par le dépôt afin que le texte source, l’historique des revues et les fichiers générés restent synchronisés. Avant la soumission : - Confirmez que les vérifications de style réussissent et que le bruit généré a disparu. - Confirmez que toutes les vérifications unitaires, d’intégration, frontend, de bout en bout et du filet de sécurité exigées par la modification réussissent. - Vérifiez le comportement manuellement et examinez le diff final à la recherche de modifications involontaires. - Confirmez la compatibilité des dépendances et de l’environnement d’exécution. - Assurez-vous que les commits respectent la politique de signature du dépôt. - Basez la contribution sur la branche d’intégration requise et faites référence aux issues associées. - Documentez la logique complexe, l’intention en matière de sécurité, les tests exécutés et toute exception approuvée. - Confirmez que toutes les vérifications d’intégration continue réussissent. Si une vérification requise n’a pas pu être exécutée, indiquez explicitement cette limitation. Ne présentez pas une vérification partielle comme une revue complète de la sécurité ou de l’intégrité du défi.