Audit code source : évaluer la sécurité de votre application

Un audit code source examine l'implémentation de votre application pour rechercher des défauts de sécurité et comprendre les chemins qui les rendent possibles. Il complète les essais sur l'application en fonctionnement. Avant une revue grand compte, définissez les dépôts concernés, la version à auditer et les livrables attendus pour l'équipe de développement.

Audit code source : choisir les chemins critiques

Un audit de code se cadre par composants et par questions. Décrivez les langages, les frameworks, les services et les frontières de confiance. Demandez au cabinet de proposer une sélection motivée des chemins à examiner : attribution des droits, accès aux données, imports et exports ou opérations d'administration. Le pentest web observe l'application déployée ; la revue de code apporte une autre vue sur son fonctionnement.

L'OWASP Code Review Guide traite de l'identification de vulnérabilités dans le code. Pour votre consultation, faites préciser comment la lecture humaine se combine avec les outils d'analyse. Un résultat d'outil doit être examiné dans le contexte du produit avant d'être traité comme un défaut établi. Demandez comment le rapport distinguera constats confirmés et points qui exigent une investigation complémentaire.

Une lecture de code et des tests d'exécution

Le rapport doit expliquer le chemin concerné. Pour chaque constat retenu, demandez une référence au fichier et à la version, le contexte d'appel, l'impact envisagé et une recommandation adaptée à votre architecture. Lorsque le cabinet confirme le comportement en environnement de test, faites relier la preuve à cette même version. Une ligne isolée de son usage ne suffit pas à guider une correction.

Une application peut déléguer l'authentification à un service tout en appliquant ses droits dans plusieurs composants. Faites décrire ces responsabilités avant de réduire l'audit au dépôt principal. Le pentest API aide à identifier les interfaces exposées ; le pentest SaaS ajoute la question des organisations et des rôles. Les frontières retenues doivent figurer dans la commande.

• Nommer le responsable qui donnera accès au dépôt.
• Préparer un schéma des appels entre services.
• Fournir des données de test adaptées aux parcours retenus.
• Définir le canal des questions techniques et des alertes.

Protéger le dépôt pendant la mission

L'accès au code est un accès sensible. Demandez des comptes individuels, une portée limitée aux dépôts retenus et une procédure de révocation. Faites préciser le lieu de travail, la conservation des copies et l'utilisation éventuelle de services externes d'analyse. Ces éléments se négocient avant la remise des sources. Ne collez aucun secret ni archive de dépôt dans la demande de devis.

Si l'équipe modifie le produit pendant la revue, gardez une trace de la version initiale et des corrections. Demandez au cabinet comment un changement de branche affecte ses références et comment il vérifie le correctif. Une nouvelle lecture de la zone corrigée et une nouvelle exécution du scénario ne couvrent pas nécessairement les mêmes points : le retest doit préciser ce qui sera fait.

Transformer les constats en travail de correction

Demandez un classement exploitable par votre équipe et une réunion de restitution avec un développeur qui connaît le produit. Le rapport pentest peut intégrer ces résultats si le contrat prévoit les deux activités, en distinguant leur couverture. Le cahier des charges doit nommer la revue de code explicitement : une offre de test d'intrusion ne l'inclut pas automatiquement. Faites enfin chiffrer les options de vérification après correction dans des lignes identifiables.