Publication de mission
Commission sur la mission
Dépôt sécurisé, versé à la livraison
Par proposition d'expert
L'audit de code source, c'est quoi ?
Un audit de code source est la relecture méthodique du code d'une application par un expert extérieur, pour y trouver les failles de sécurité, les erreurs de logique et les mauvaises pratiques. On parle aussi de code review de sécurité, ou d'audit de sécurité du code source.
Il se distingue du test d'intrusion : le pentesteur attaque l'application de l'extérieur, comme un pirate, sans voir le code. L'auditeur, lui, lit le code. Il voit donc ce qu'un test ne déclenche pas : une route d'administration oubliée, une clé d'API écrite en dur, un contrôle d'accès absent sur une fonction rarement appelée.
Les outils d'analyse automatique (SAST) donnent une première liste, souvent bruyante. La valeur de l'audit est dans la revue manuelle : l'expert trie les alertes, comprend la logique métier et suit le trajet des données jusqu'aux points sensibles.
Quand faire auditer son code source ?
Six situations où un audit de code apporte une réponse qu'un scan ou un test d'intrusion seul ne donne pas.
Avant une mise en production
Nouvelle application, refonte, ouverture d'une API aux partenaires : l'audit repère les failles pendant qu'elles coûtent encore peu à corriger.
Éditeur face à un client exigeant
Un grand compte, un appel d'offres ou un questionnaire de sécurité vous demande la preuve que votre logiciel a été audité. Le rapport d'un expert indépendant répond à cette demande.
Reprise de code ou rachat
Vous reprenez une application développée par un autre prestataire, ou vous rachetez une société : l'audit dit ce que vaut le code, où sont les risques et ce qu'il faudra reprendre.
Après un incident
Site piraté, fuite de données, compte détourné : l'expert remonte au défaut dans le code qui a permis l'attaque, et cherche les autres du même type.
Conformité et données sensibles
Paiement, santé, données personnelles : RGPD, PCI DSS, NIS2 ou ISO 27001 attendent des mesures de sécurité dans le développement. L'audit en fournit une preuve datée.
Code produit vite ou par une IA
Prototype devenu produit, code généré par un assistant d'IA, équipe sans spécialiste sécurité : une relecture extérieure trouve ce que personne n'a eu le temps de vérifier.
Ce que l'auditeur vérifie
Les points de contrôle d'un audit de sécurité du code source, inspirés de l'OWASP Top 10 et de l'OWASP ASVS.
Authentification et sessions
Stockage des mots de passe, réinitialisation, double authentification, durée et invalidation des sessions, jetons d'API.
Contrôle d'accès
Chaque route et chaque action vérifient-elles les droits de l'utilisateur ? Peut-on lire ou modifier la donnée d'un autre en changeant un identifiant ?
Injections
Requêtes SQL construites à la main, commandes système, modèles de pages, désérialisation : toute entrée de l'utilisateur suivie jusqu'à son usage.
Données affichées et envoyées
Échappement contre le XSS, protection CSRF, en-têtes de sécurité, téléversement de fichiers, appels sortants vers des adresses fournies par l'utilisateur (SSRF).
Secrets dans le code
Clés d'API, mots de passe, certificats écrits dans le code ou restés dans l'historique Git, fichiers de configuration versionnés par erreur.
Dépendances
Bibliothèques et paquets avec des vulnérabilités connues (CVE), versions abandonnées, paquets inutiles qui élargissent la surface d'attaque.
Cryptographie
Algorithmes dépassés, aléatoire prévisible, chiffrement fait maison, clés mal protégées, données sensibles stockées en clair.
Journaux et gestion des erreurs
Messages d'erreur trop bavards, mode débogage actif en production, données personnelles ou secrets écrits dans les journaux, événements de sécurité non tracés.
Comment se déroule un audit de code
Les grandes étapes d'une revue de code de sécurité, du cadrage au contre-test.
Cadrage
Choix du périmètre (dépôt, modules, version exacte), des risques prioritaires et du livrable. Accès en lecture seule au dépôt et accord de confidentialité signé.
Analyse automatique
Passage d'outils SAST et d'analyse des dépendances, comme Semgrep, SonarQube ou un scanner de secrets, pour obtenir une première liste de points à vérifier.
Revue manuelle
Lecture des parties sensibles : authentification, droits, paiements, téléversements, appels à la base. L'expert écarte les faux positifs et cherche les erreurs de logique qu'aucun outil ne voit.
Preuves
Pour chaque faille, l'emplacement exact dans le code, un scénario d'exploitation et, si un environnement de recette est fourni, une démonstration.
Rapport et contre-test
Remise du rapport, échange avec l'équipe de développement, puis vérification des corrections si elle est prévue dans la mission.
Livrables attendus
Fixez le livrable avant le début de la mission : c'est lui qui permet de juger le travail et de libérer le paiement.
Une synthèse pour la direction
Deux pages au plus : le niveau de risque global, les failles critiques et les décisions à prendre, sans jargon.
La liste des failles
Chaque faille avec son fichier et sa ligne, sa gravité (score CVSS ou grille équivalente), son impact concret et ses étapes de reproduction.
Les corrections recommandées
Pour chaque faille, la correction proposée, avec un exemple de code quand c'est utile, classée par priorité.
L'état des dépendances
Les bibliothèques vulnérables ou abandonnées, la version à installer et les éventuelles ruptures de compatibilité.
Le contre-test
Une seconde passe sur la version corrigée, qui confirme faille par faille ce qui est réglé. Utile à montrer à un client ou à un auditeur de conformité.
Le brief à fournir à l'auditeur
Un brief complet évite des jours de travail perdus. Rassemblez ces éléments avant de publier votre mission.
Le périmètre
Le dépôt ou les modules à auditer, la branche ou le commit figé, et ce qui est hors limites.
Le langage et le framework
PHP et Laravel ou Symfony, Python et Django, JavaScript et Node ou React, Java et Spring, Go, application mobile : l'expert choisi doit connaître votre pile.
La taille du code
Un ordre de grandeur du nombre de lignes et de fichiers, hors bibliothèques tierces. C'est ce qui fixe la durée de l'audit.
Les risques prioritaires
Les fonctions qui vous inquiètent le plus : paiement, espace client, API publique, back-office, données de santé.
Les accès et la confidentialité
Accès en lecture seule au dépôt, environnement de recette si vous en avez un, accord de confidentialité, destruction des copies à la fin de la mission.
Le délai et le livrable
La date à laquelle vous avez besoin du rapport, et le livrable attendu parmi ceux décrits plus haut, contre-test compris ou non.
Confier un audit de code source sur Hackersdate
Hackersdate met en relation des organisations avec des experts en cybersécurité indépendants. Voici comment confier votre audit.
Publiez votre mission
Reprenez les éléments du brief : périmètre, langage, taille, risques et livrable. Ne mettez aucun code ni accès dans l'annonce : ils se transmettent ensuite à l'expert retenu. La publication est gratuite.
Recevez des propositions d'experts
Des hackers éthiques vous répondent avec leur approche, leur délai et leur prix. Chaque expert dépense 1 crédit pour déposer une proposition : ceux qui répondent sont intéressés par votre mission.
Choisissez et cadrez
Comparez les profils et les avis, échangez dans la messagerie, puis acceptez la proposition retenue. Signez l'accord de confidentialité avant de donner accès au dépôt.
Payez en dépôt sécurisé
Le montant est réglé par Stripe et conservé en dépôt sécurisé. Il n'est versé à l'expert qu'à la livraison du rapport, quand vous libérez les fonds et laissez votre avis. Hackersdate prélève une commission de 2 %.
Experts en cybersécurité inscrits
Des hackers éthiques indépendants, avec leur profil et leurs avis
Questions fréquentes sur l'audit de code source
Faites auditer votre code source
Publiez gratuitement votre besoin et recevez les propositions de hackers éthiques indépendants.
Publier ma mission gratuitement
