Une chaîne open source de scan de vulnérabilités pour les PME
La gestion des vulnérabilités n'est pas un outil unique. Les failles connues se cachent à quatre endroits : vos dépendances, vos images de conteneurs, vos serveurs et services réseau, et ce que vous exposez sur internet. Chacun demande son scanner, et tous ont besoin d'un endroit unique où trier les résultats. Bonne nouvelle : une chaîne solide se construit entièrement avec des outils open source, et elle répond directement à ce qu'attendent les auditeurs, NIS2 et le Cyber Resilience Act.
Quatre couches, quatre outils
- Dépendances et images : Trivy ou Grype. Exécutez-les en CI à chaque build. Ils lisent les fichiers de verrouillage et les images, comparent les composants aux bases de vulnérabilités et font échouer le build au-delà d'une sévérité choisie. Trivy vérifie aussi l'infrastructure as code et les manifestes Kubernetes.
- L'inventaire : SBOM et OWASP Dependency-Track. Générez un SBOM CycloneDX pour chaque version (Syft ou Trivy le font) et envoyez-le à Dependency-Track. Quand une nouvelle CVE sort le mois suivant, il indique quelles versions déployées sont touchées, sans rien reconstruire.
- Serveurs et réseau interne : Greenbone OpenVAS. Les scans authentifiés des hôtes trouvent les correctifs manquants et les configurations faibles que les scanners d'images ne voient jamais : l'appliance VPN, le vieux serveur de fichiers, la VM de base de données.
- La surface exposée : Nuclei. Des vérifications à base de templates sur vos noms d'hôtes publics : CVE connues, interfaces d'administration exposées, identifiants par défaut, en-têtes mal configurés. Assez rapide pour tourner chaque jour.
Extrait de la fiche « Vulnerability and Configuration Scanners for Your Own Estate » · Demander la fiche complète
Des résultats aux correctifs
Les scanners produisent du bruit ; c'est le processus qui réduit le risque.
- Trier selon l'exploitabilité, pas seulement le CVSS. Priorisez les vulnérabilités du catalogue Known Exploited Vulnerabilities de la CISA et celles à score EPSS élevé, sur les systèmes exposés à internet.
- Fixer des délais par sévérité : par exemple critique et exposée en 7 jours, haute en 30, le reste à la prochaine fenêtre de maintenance. Écrivez-les ; un auditeur les demandera.
- Consigner les exceptions avec un responsable et une date d'expiration plutôt que d'ignorer les résultats en silence.
- Mesurer : les vulnérabilités ouvertes par âge et par sévérité, et le délai moyen de correction. Ces deux chiffres montrent à une direction si le dispositif fonctionne.
- Finding on a host
- → Detected by version banner only?
- Yes: Package changelog shows the fix (backport)?
- Yes: False positive: override with reason
- No: Service reachable by an attacker?
- Yes: Ticket, SLA by exposure
- No: Accept or schedule, owner + expiry
- No: Service reachable by an attacker? (see above)
- Yes: Package changelog shows the fix (backport)?
- → Detected by version banner only?
Extrait de la fiche « Vulnerability and Configuration Scanners for Your Own Estate » · Demander la fiche complète
Pourquoi maintenant : NIS2 et le Cyber Resilience Act
NIS2 impose aux entités essentielles et importantes de traiter les vulnérabilités dans leur gestion des risques. Le Cyber Resilience Act va plus loin pour quiconque met sur le marché européen des logiciels ou des produits connectés : la déclaration des vulnérabilités activement exploitées s'applique depuis le 11 septembre 2026, et l'ensemble des obligations, dont un SBOM et des mises à jour de sécurité pendant la période de support, à partir du 11 décembre 2027. La chaîne décrite ici produit exactement les preuves que ces textes demandent : SBOM, rapports de scan, délais de correction.
En résumé
Scannez dépendances et images en CI, conservez les SBOM dans Dependency-Track, scannez les hôtes avec OpenVAS et votre surface publique avec Nuclei, puis triez selon l'exploitabilité avec des délais écrits. L'open source fournit les outils ; la discipline de correction est la seule partie qui ne se télécharge pas.