Pentest en boîte blanche : tester avec le code source en main

En boîte blanche, le pentester a tout : le code source, les schémas d’architecture, les comptes de test, souvent les fichiers de configuration et de déploiement. Il teste l’application en fonctionnement, comme en boîte grise, et il lit en parallèle le code qui la fait tourner.

On pourrait croire que c’est moins réaliste, puisqu’un attaquant n’a pas votre code. Deux remarques. D’abord, il l’a parfois : dépôt Git rendu public par erreur, ancien prestataire, fichiers source servis par un serveur mal configuré. Ensuite, et surtout, l’objectif d’un audit est de trouver les failles avant l’attaquant, dans un temps limité. Le code permet d’aller chercher directement ce qu’un attaquant mettrait des semaines à deviner.

Ce que vous fournissez

• Un accès en lecture au dépôt de code, ou une archive à jour de la version testée.
• Les schémas d’architecture, même sommaires : quels services se parlent, où sont stockées les données, ce qui est exposé à Internet.
• Les comptes de test, un par rôle, comme en boîte grise.
• Si vous en avez, les fichiers d’infrastructure (Terraform, pipelines CI/CD) et la liste des dépendances.
• Un développeur joignable pour répondre aux questions. Une question de cinq minutes économise souvent une demi-journée de lecture.

Le code reste chez vous si vous le souhaitez : la revue peut se faire sur un poste ou un environnement que vous fournissez.

Comment on lit le code

Personne ne lit 200 000 lignes de code ligne par ligne en quelques jours, et ce n’est pas l’objectif. La lecture suit les données.

Le pentester part des points d’entrée : les routes, les contrôleurs, les fonctions exposées par l’API. Il suit chaque donnée envoyée par l’utilisateur jusqu’aux endroits où elle devient dangereuse : une requête SQL, un chemin de fichier, une commande système, un gabarit HTML, un appel à un autre serveur. Entre les deux, il vérifie ce qui la contrôle, ou ce qui ne la contrôle pas.

Il regarde aussi comment les droits sont vérifiés. Dans beaucoup de frameworks, un middleware d’authentification ou un décorateur protège chaque route. Il suffit d’une route où il a été oublié. En boîte grise, il faut tomber dessus. Dans le code, une recherche suffit à lister toutes les routes qui n’en ont pas.

Les outils d’analyse statique (SAST), comme Semgrep ou CodeQL, font un premier passage. Ils remontent beaucoup de faux positifs, et chaque résultat est vérifié à la main. L’analyse des dépendances fait le reste : chaque bibliothèque est comparée aux failles connues, ce qui couvre la catégorie A03 du Top 10 OWASP 2025 sur la chaîne d’approvisionnement logicielle.

Enfin, tout ce qui est repéré dans le code est confirmé sur l’application qui tourne. Une faille vue dans le code, mais impossible à déclencher n’a pas la même priorité qu’une faille prouvée, et le rapport le dit.

Ce qu’elle trouve et que les autres approches ratent

Les fonctions cachées. Une route d’administration que l’interface n’appelle jamais, un paramètre de débogage resté actif, une ancienne version d’API encore branchée. En boîte grise, on les devine parfois ; dans le code, elles sont écrites noir sur blanc.

Les secrets. Clés d’API, mots de passe de base de données, jetons de service écrits en dur, dans le code actuel ou dans l’historique Git. Supprimer un secret d’un fichier ne le retire pas de l’historique.

Les erreurs de cryptographie. Un jeton de réinitialisation de mot de passe généré avec un aléatoire prévisible, des mots de passe hachés en MD5, une signature vérifiée avec la mauvaise fonction. Vu de l’extérieur, tout semble fonctionner.

Les cas rares. Une condition de concurrence qui ne se déclenche qu’en envoyant deux requêtes au même instant, une branche de code qui ne s’exécute que pour un type de client particulier, une erreur mal gérée qui laisse passer une requête au lieu de la bloquer. La gestion des erreurs fait d’ailleurs son entrée dans le Top 10 2025 (A10), et c’est typiquement en lisant le code qu’on la juge.

Il y a aussi un bénéfice pour l’équipe de développement : le rapport indique le fichier et la ligne en cause. La correction va plus vite, et elle traite la cause plutôt que le symptôme. Si la même erreur se répète dans quinze contrôleurs, le rapport le dit aussi.

Ce que ça coûte

La boîte blanche est nettement plus longue qu’une boîte grise sur la même application, parce qu’elle ajoute la revue de code au test dynamique. La taille du code, le nombre de langages et la qualité de la documentation font varier la durée. Le formulaire de devis en tient compte quand vous choisissez cette option.

En France, le référentiel PASSI de l’ANSSI traite d’ailleurs l’audit de code source comme une activité à part entière, distincte du test d’intrusion. C’est un bon indicateur : on ne parle pas du même volume de travail.

Quand la choisir

La boîte blanche a le plus de valeur :

• sur une application qui a déjà passé un audit en boîte grise, pour aller chercher ce qui reste ;
• sur une application qui manipule des données sensibles (paiement, santé, données RH) ou dont une fuite mettrait l’entreprise en difficulté ;
• avant une version majeure ou une refonte, quand corriger coûte encore peu ;
• pour une équipe qui veut comprendre ses erreurs récurrentes et pas seulement corriger une liste.

Pour un premier audit d’une application jamais testée, nous recommandons en général de commencer par la boîte grise : elle trouve vite les failles les plus grossières, et l’argent économisé paie les corrections. La boîte blanche vient ensuite, quand les évidences sont réglées.

Un dernier point. Un audit, même en boîte blanche, reste une photo à un instant donné. Le code continue de changer après. Pour garder le niveau, il faut que la sécurité entre dans le cycle de développement : relecture des modifications sensibles, analyse statique dans la chaîne d’intégration, dépendances surveillées.

Pour comparer avec les autres approches : le pentest en boîte noire, le pentest en boîte grise, et la vue d’ensemble dans Audit d’intrusion (pentest), approches et méthodologie. Nos pentests d’application web proposent la boîte blanche en option.