En bref : test d'intrusion ou scan de vulnérabilités n'est pas une question d'alternative, mais d'ordre. Un scan de vulnérabilités trouve de façon automatisée des failles connues et des erreurs de configuration, vite et à bas coût, mais avec des fausses alertes et des angles morts. Un test d'intrusion examine de façon ciblée ce qu'un attaquant pourrait réellement atteindre. Un programme de bug bounty ouvre l'examen à des chercheurs externes et ne vaut la peine que lorsque scans et tests d'intrusion font partie de la routine. Pour la plupart des PME, l'ordre est : scanner régulièrement, corriger les constats, faire tester de façon ciblée, mettre en place un point de signalement des vulnérabilités.
Pourquoi la question est posée à nouveau après PHP2Shell
Celui qui examine son site avec un scanner en ligne après PHP2Shell peut obtenir des résultats déroutants. Un scanner signale peut-être une faille critique alors que l'hébergeur a confirmé le correctif. Un autre ne signale rien alors que le serveur utilise encore une ancienne version de PHP, parce que l'indication de version est masquée.
La raison tient à la méthode de travail. De nombreux scanners déduisent la vulnérabilité de la version affichée. Or les distributions installent des rétroportages sans changer le numéro de version ; selon des rapports, Ubuntu 24.04 continue par exemple d'afficher 8.3.6 après la mise à jour. Pourquoi il en est ainsi est expliqué dans Pourquoi php -v affiche le même numéro après la mise à jour. La preuve fiable est fournie par le journal des modifications du paquet, voir Vérifier correctement la version de PHP et l'état des correctifs.
Ce n'est pas un argument contre les scanners, mais un argument pour en connaître les limites et les combiner avec d'autres méthodes.
Test d'intrusion ou scan de vulnérabilités : les trois méthodes comparées
| Critère | Scan de vulnérabilités | Test d'intrusion | Bug bounty |
|---|---|---|---|
| Qui examine ? | Outil automatisé | Spécialistes mandatés | Chercheurs externes, souvent via une plateforme |
| Qu'est-ce qui est trouvé ? | Failles connues, versions obsolètes, erreurs de configuration | Vulnérabilités exploitables, erreurs de logique, enchaînements | Ce que les chercheurs trouvent et signalent, souvent de l'inhabituel |
| Profondeur | Large, mais superficielle | Profonde dans le périmètre convenu | Variable, dépend des participants |
| Fausses alertes | Fréquentes | Rares, les constats sont prouvés | Nombreux signalements à évaluer |
| Planifiabilité | Élevée, répétable à volonté | Élevée, durée et périmètre fixes | Faible, les signalements arrivent en continu |
| Conditions préalables dans l'entreprise | Quelqu'un qui évalue les résultats | Périmètre convenu, environnement de test ou fenêtre de maintenance | Processus mûr d'évaluation, de correction et de récompense |
| Usage typique | En continu, par exemple mensuel ou après modifications | Avant le lancement, après des modifications importantes, régulièrement | En complément pour des applications mûres et exposées |
Aucune des méthodes ne remplace les autres. Le scan montre beaucoup en peu de temps, le test d'intrusion montre ce qui compte vraiment, et le bug bounty trouve ce à quoi personne n'a pensé.
Pour les scanners, un second regard sur le type de scan vaut aussi la peine. Un scan de l'extérieur ne voit que ce que voit tout visiteur et doit souvent deviner les versions à partir des réponses du serveur. Un scan authentifié, où l'outil lit avec ses propres identifiants les paquets installés sur le serveur, fournit des résultats nettement plus fiables, justement pour l'état réel des paquets de PHP. Il suppose toutefois que vous mettiez en place pour cela un accès restreint et le protégiez bien. Pour les dépendances de vos propres applications PHP, il existe à leur tour des outils d'examen spécifiques, par exemple composer audit pour les paquets de Composer.
L'ordre judicieux pour les PME
- Inventaire et scan : d'abord savoir quels sites et serveurs existent, puis scanner régulièrement. Ne pas reprendre les constats sans vérification, mais les évaluer.
- Corriger les bases : supprimer les logiciels obsolètes, les mises à jour manquantes et les erreurs de configuration évidentes. Lancer un test d'intrusion sur des systèmes non corrigés gaspille du budget.
- Test d'intrusion ciblé : pour les applications les plus importantes, par exemple boutique, portail client ou interfaces, avec un périmètre clairement convenu et un contre-test.
- Revue de code pour les développements propres : celui qui exploite ses propres applications PHP complète le test par une relecture du code source. Le déroulement est décrit dans Revue de code de sécurité pour les projets PHP.
- Point de signalement des vulnérabilités : une politique expliquant comment des tiers peuvent signaler des failles, et un fichier security.txt selon la RFC 9116 sous
/.well-known/security.txtavec contact et date d'expiration. - Bug bounty, quand les bases sont posées : seulement quand les signalements sont évalués de façon fiable et les failles corrigées sans tarder.
Pour que cela devienne une procédure durable, voyez La gestion des vulnérabilités dans les PME.
Ce qu'aucune des méthodes ne fait
Aucune méthode d'examen ne prouve qu'un système est sûr. Elle montre seulement ce qui a été trouvé à un moment donné avec certaines méthodes. Un rapport de test d'intrusion propre du printemps ne dit rien d'une faille comme PHP2Shell, connue en octobre.
De même, ni le scan ni le test d'intrusion ne répondent à la question de savoir si un serveur est déjà compromis. Il faut pour cela une recherche de traces sur le système lui-même : processus, fichiers, tâches cron, comptes, connexions. C'est une tâche à part avec ses propres méthodes.
Ne faites examiner que des systèmes pour lesquels vous êtes habilité, et clarifiez au préalable, pour les systèmes hébergés, les règles du prestataire. Un test d'intrusion exige un mandat écrit avec périmètre, période et interlocuteurs.
Quand vous n'avez pas besoin de test externe
Pour un simple site d'entreprise sans formulaire avec des données sensibles, chez un hébergeur qui installe les mises à jour de façon fiable, un scan régulier avec évaluation critique des résultats suffit souvent. Un test d'intrusion serait ici le plus souvent disproportionné. Plus importants sont des logiciels à jour, des accès solides et des sauvegardes.
Un test externe vaut la peine pour les boutiques, les portails, les développements propres, les interfaces avec des systèmes internes et partout où des clients ou des normes exigent une preuve indépendante.
Comment PHP SOS aide-t-il concrètement ?
- Nous mettons en place des scans réguliers et évaluons les résultats, y compris les fausses alertes dues aux rétroportages.
- Nous aidons à corriger les bases avant que de l'argent ne soit investi dans un test d'intrusion.
- Avec des partenaires spécialisés, nous réalisons des audits de sécurité et tests d'intrusion avec périmètre convenu et contre-test.
- Nous aidons à mettre en place un point de signalement des vulnérabilités et un security.txt.
Conclusion
Scan, test d'intrusion et bug bounty sont des niveaux, pas des concurrents. Celui qui commence par des scans réguliers, corrige les bases puis fait tester de façon ciblée obtient le plus de sécurité pour son budget. Le bug bounty est la cerise pour les organisations dont l'essentiel est déjà acquis.
Questions fréquentes
Quelle est la différence entre test d'intrusion et scan de vulnérabilités ?
Un scan de vulnérabilités vérifie de façon automatisée si des failles connues ou des erreurs de configuration sont reconnaissables. Un test d'intrusion va plus loin : des spécialistes tentent, dans un cadre convenu, d'exploiter réellement des vulnérabilités et de les enchaîner, et évaluent les conséquences.
Un scanner détecte-t-il si mon serveur est corrigé contre PHP2Shell ?
Seulement de façon limitée. De nombreux scanners lisent la version de PHP affichée. Lorsque la distribution installe un rétroportage, le numéro reste souvent identique, et le scanner signale une faille depuis longtemps fermée. Inversement, un nouveau numéro peut s'afficher alors que d'anciens processus tournent encore.
Un programme de bug bounty convient-il aux petites entreprises ?
Le plus souvent pas encore. Le bug bounty suppose que les signalements soient évalués rapidement et les failles corrigées sans tarder. Une bonne entrée est une politique simple de signalement des vulnérabilités avec un fichier security.txt.
Puis-je examiner moi-même mon site avec un scanner ?
En règle générale oui pour vos propres systèmes, si vous y êtes habilité. Si le site est chez un hébergeur, clarifiez au préalable si les scans sont autorisés ou à annoncer. N'examinez des systèmes tiers qu'avec l'autorisation écrite de l'exploitant.
À quelle fréquence faut-il un test d'intrusion ?
Il n'existe pas de règle fixe. Il est d'usage de faire un test avant le lancement d'une nouvelle application, après des modifications importantes et à intervalles réguliers, déterminés par votre risque et le cas échéant par les exigences de clients ou de normes.