Tests de sécurité
Pentest vs analyse de vulnérabilités en continu : comment les combiner
Un pentest (test d’intrusion) est un exercice limité dans le temps au cours duquel des testeurs expérimentés tentent de s’introduire dans un système comme le ferait un attaquant. L’analyse de vulnérabilités en continu contrôle les logiciels de manière automatique et répétée à la recherche de faiblesses connues. Elles répondent à des questions différentes : la plupart des programmes de sécurité ont besoin des deux.
Offre Free, sans carte bancaire.
Qu’est-ce qu’un pentest ?
Le NIST décrit le test d’intrusion comme un test de sécurité dans lequel les évaluateurs imitent des attaques réelles pour trouver des moyens de contourner les fonctions de sécurité d’une application, d’un système ou d’un réseau. Les testeurs enchaînent de petites faiblesses, sondent la logique métier et jugent ce qu’un attaquant pourrait réellement obtenir.
Un pentest est cadré et autorisé par écrit, dure une période déterminée et se termine par un rapport des constats, de leur impact et des correctifs recommandés. Son résultat est un instantané : il décrit le système tel qu’il était pendant le test.
Qu’est-ce que l’analyse de vulnérabilités en continu ?
Le NIST définit l’analyse de vulnérabilités comme une technique servant à identifier des hôtes, leurs attributs et les vulnérabilités associées. L’analyse de la composition logicielle applique la même idée au code : elle liste les composants open source qu’un produit contient et les confronte à des avis publics comme les enregistrements CVE.
L’analyse est continue lorsqu’elle s’exécute à chaque changement et que l’inventaire continue d’être revérifié à mesure que de nouveaux avis sont publiés. Un composant sain à la sortie peut devenir vulnérable des mois plus tard sans qu’une seule ligne de votre code ait changé.
Pentest et analyse de vulnérabilités en un coup d’œil
Les deux méthodes diffèrent par qui fait le travail, ce qu’elles détectent et la durée pendant laquelle leur résultat reste vrai.
| Question | Test d’intrusion | Analyse en continu |
|---|---|---|
| Qui le réalise | Des personnes expérimentées, souvent un prestataire externe | Des outils automatisés |
| Ce qu’il détecte | Des chaînes exploitables, des failles de logique et des erreurs de configuration, avec leur impact réel | Des vulnérabilités connues dans les composants, des secrets exposés et des erreurs de configuration courantes |
| À quelle fréquence | Souvent chaque année, et après des changements importants | À chaque changement et de manière répétée entre les versions |
| Profondeur | En profondeur, sur un périmètre défini | Large, sur chaque produit et chaque version |
| Résultat | Un rapport à un instant donné | Une liste à jour des constats et de leur statut |
| Limites | Ne voit pas ce qui change après le test ; coûteux à répéter | Ne prouve pas l’exploitabilité et ne trouve pas de nouvelles failles de logique |
Pourquoi il vous faut les deux
Les deux couvrent les angles morts l’un de l’autre. Un pentest trouve ce qu’aucun scanner ne peut trouver : un contrôle d’autorisation défaillant, un processus détournable, une chaîne de problèmes mineurs qui aboutit à une compromission. L’analyse trouve ce qu’un pentest ne peut pas suivre : l’avis publié la semaine après le départ des testeurs, la dépendance ajoutée au sprint suivant, la version de firmware livrée à un nouveau client.
Les référentiels reflètent cette répartition. Le NIST SP 800-53 liste le test d’intrusion (CA-8) et la surveillance et l’analyse des vulnérabilités (RA-5) comme des mesures distinctes. Le guide OWASP Web Security Testing Guide plaide pour une approche équilibrée : les scanners ont leur place dans un programme de tests mais ne peuvent pas remplacer les tests manuels, et le test d’intrusion ne devrait pas être la seule technique.
Analyser en continu rend aussi un pentest plus rentable. Quand les vulnérabilités connues sont déjà corrigées, les testeurs consacrent leur temps aux problèmes que seules des personnes peuvent trouver.
Comment les combiner
Un rythme simple convient à la plupart des équipes produit :
- Analyser en continu dès le départ : chaque dépôt, chaque image de conteneur et chaque version de firmware, revérifiés à mesure que de nouveaux avis apparaissent.
- Corriger ou documenter les vulnérabilités connues avant un pentest, pour que le rapport se concentre sur ce que les scanners ne voient pas.
- Commander un pentest avant les versions majeures, après des changements d’architecture importants et aussi souvent que les clients, les assureurs ou les autorités l’attendent.
- Remettre aux testeurs votre SBOM et la liste actuelle des constats ouverts, pour qu’ils puissent cibler les composants les plus risqués.
- Intégrer les constats du pentest dans le même suivi que les constats d’analyse, et réanalyser après chaque correction.
Disponible aujourd’hui dans KROMSE
KROMSE n’est pas un test d’intrusion et n’en remplace pas un. Il couvre le volet de l’analyse continue : l’analyse d’URL contrôle ce que tout le monde peut voir depuis internet, et KROMSE contrôle le code, les dépendances, les images de conteneurs et le firmware qui se trouvent derrière un produit.
- Contrôle des dépendances auprès d’OSV.dev pour les lockfiles et les manifestes, dont npm, Yarn, pnpm, Poetry, uv, pip, Go, Cargo, Maven, Gradle, Composer, Bundler et .NET.
- Détection de secrets au commit analysé ; les valeurs des secrets sont masquées et jamais stockées.
- Images firmware basées sur Linux extraites de manière récursive, dont les paquets sont confrontés à OSV.dev et dont le système de fichiers racine est contrôlé pour détecter les erreurs de configuration et les secrets embarqués.
- Sur les offres payantes, le dernier SBOM de chaque source est recontrôlé auprès d’OSV.dev toutes les 6 heures, et les nouvelles correspondances apparaissent sous forme de notifications dans l’application.
- Un enrichissement CISA KEV, FIRST EPSS, NVD et ENISA EUVD sur les constats, les vulnérabilités connues pour être exploitées étant signalées.
Questions fréquentes
Une analyse de vulnérabilités est-elle la même chose qu’un pentest ?
Non. Une analyse est automatisée et recherche des faiblesses connues. Un pentest est mené par des personnes qui tentent d’exploiter des faiblesses, y compris des faiblesses qu’aucun scanner ne connaît, et qui en jugent l’impact. Les testeurs utilisent souvent des scanners en chemin, mais un rapport d’analyse n’est pas un rapport de pentest.
À quelle fréquence faut-il réaliser un pentest ?
Il n’y a pas d’intervalle unique. Le NIST SP 800-53 laisse la fréquence à l’appréciation de l’organisation, et de nombreuses organisations testent chaque année et après des changements importants. Les clients, les assureurs et les règles sectorielles fixent souvent un minimum.
L’analyse continue peut-elle remplacer un pentest ?
Non. L’analyse ne peut pas tester la logique métier, enchaîner des faiblesses ni montrer ce qu’un attaquant pourrait réellement obtenir. Elle réduit le nombre de problèmes connus sur lesquels un pentest doit passer du temps, et elle continue de surveiller une fois le test terminé.
Ai-je besoin d’une autorisation pour réaliser un pentest ?
Oui. Tester un système sans l’autorisation écrite de son propriétaire peut constituer une infraction pénale ; dans l’UE, la directive 2013/40/UE impose aux États membres de sanctionner l’accès illégal aux systèmes d’information. Un pentest commence toujours par un périmètre convenu et des règles d’engagement écrites.
KROMSE réalise-t-il des tests d’intrusion ?
Non. KROMSE ne réalise ni tests d’intrusion ni tests dynamiques complets d’applications (DAST). Il contrôle le code, les dépendances, les images de conteneurs et le firmware basé sur Linux pour y détecter des vulnérabilités connues, des secrets et des erreurs de configuration, ce qui complète un pentest mené par des testeurs qualifiés.
Guides associés
Sources
- Glossaire du NIST : penetration testing
- NIST SP 800-115 : Technical Guide to Information Security Testing and Assessment
- NIST SP 800-53 Rev. 5 : Security and Privacy Controls (CA-8, RA-5)
- OWASP Web Security Testing Guide
- Directive 2013/40/UE relative aux attaques contre les systèmes d’information, EUR-Lex