Gestion des vulnérabilités open source : ce que vous pouvez monter vous-même avant un audit SOC 2 ou ISO 27001

Qu'est-ce que la gestion des vulnérabilités open source ?

La gestion des vulnérabilités, c'est la boucle qui suit la détection : rassembler les résultats de chaque scanner, retirer les doublons, les classer, donner à chacun un responsable et un délai, corriger ou accepter le risque, et garder la preuve. En open source, on monte cette boucle avec des outils gratuits hébergés chez soi, sans plateforme commerciale.

Les scanners sont la partie facile, et nous les avons testés : les outils SCA open source sur un même dépôt et les scanners de secrets open source comparés. Ce qu'ils ne vous donnent pas, c'est une mémoire. Le 3 novembre 2026, nous avons lancé Trivy, Gitleaks et Opengrep sur OWASP Juice Shop pour notre guide sur les scans exigés par SOC 2 : 383 résultats dans quatre fichiers JSON, et aucun ne portait de commit, de responsable, de délai ni de statut. La couche de gestion comble ce manque.

Que demandent SOC 2 et ISO 27001 ?

Aucun des deux ne nomme d'outil. Le critère CC7.1 de SOC 2 demande de détecter les nouvelles vulnérabilités et votre exposition à celles qui viennent d'être découvertes. La mesure A.8.8 d'ISO 27001:2022 demande d'obtenir l'information sur les vulnérabilités techniques, d'évaluer votre exposition et d'agir. Les deux laissent les délais à votre politique, puis vérifient que vous les avez tenus.

Le texte de SOC 2, tel que le reproduisent les cabinets d'audit, demande des procédures de détection et de surveillance qui repèrent les changements de configuration introduisant de nouvelles vulnérabilités, et la sensibilité aux vulnérabilités nouvellement découvertes. L'annexe A 8.8 d'ISO 27001, gestion des vulnérabilités techniques, commence par l'obligation d'obtenir l'information sur les vulnérabilités techniques des systèmes en service, puis demande d'évaluer l'exposition et de prendre les mesures appropriées. HighTable, un cabinet de conseil ISO 27001, rappelle que la norme n'impose aucun nombre d'heures : les délais de correction viennent d'un accord de niveau de service que vous fixez par gravité.

L'auditeur lit donc d'abord votre politique, puis tire des résultats au hasard et compare chacun à ce qu'elle prévoit. Notre guide sur ce que demandent les auditeurs ISO 27001 et SOC 2 quand des agents IA écrivent le code couvre les mesures de développement sécurisé autour, de A.8.25 à A.8.29.

Quel outil open source couvre quelle partie ?

Chaque outil ci-dessous couvre une partie de la boucle, et le registre au milieu est la pièce la plus facile à oublier.

Dependency-Track répond à « laquelle de nos applications embarque un composant qui vient de devenir vulnérable ? », et un registre répond à « où en est chaque résultat, de chaque outil, et est-il dans son délai ? ». DefectDojo est un registre que vous alimentez avec l'export de chaque scanner, alors que CybeDefend Open Source lance lui-même les scanners et remplit sa file à chaque passage, sans export ni import entre les deux.

DefectDojo ne scanne pas : il importe ce que les autres outils exportent, retire les doublons et suit le statut de chaque résultat. Il existe en édition Community gratuite à héberger soi-même, sous licence BSD-3-Clause, et en édition Pro payante, et son dépôt contient des parseurs pour Trivy, Grype, OSV-Scanner, Gitleaks, Semgrep, SARIF et Dependency-Track, entre autres.

OWASP Dependency-Track se décrit comme une plateforme d'analyse de composants. Il surveille l'usage des composants dans toutes les versions de chaque application de son portefeuille, lit et produit des SBOM et des VEX CycloneDX, et tire ses données de vulnérabilités de la NVD, des GitHub Advisories, d'OSV et d'autres sources. La version 5.2.1 est sortie le 25 octobre 2026.

OpenCVE couvre un trou que les autres outils laissent. Il vous permet de surveiller vos éditeurs et vos produits et de recevoir les alertes CVE qui les concernent, envoyées par e-mail, Slack ou webhook selon des règles que vous définissez, avec le contexte CVSS, EPSS et KEV réuni en signaux de risque. Ce n'est pas un scanner SCA et il ne lit pas vos fichiers de dépendances. Sa place, c'est la veille entre deux scans, et sur les logiciels qui vivent hors de vos dépôts : le moteur de base de données, le VPN, le runner de CI. OpenCVE tourne en service cloud avec une offre gratuite, ou sur vos propres serveurs selon ses conditions de licence, qui exigent une licence commerciale pour un usage commercial sur site.

Que vérifie l'auditeur ?

L'auditeur prend des résultats de la période et suit chacun : quand il est apparu, sur quel commit ou quel actif, qui en était responsable, quel délai votre politique fixait pour sa gravité, et comment il a été clos. Une correction demande le changement qui l'a corrigé. Un risque accepté demande une raison, un approbateur et une date d'expiration.

Sur une période SOC 2 Type II, ou entre deux audits de surveillance ISO 27001, cette trace doit exister sur des mois, pas sur la semaine qui précède l'audit. Trois documents font l'essentiel du travail :

• La politique : les niveaux de gravité, le délai par niveau, qui peut accepter un risque et pour combien de temps.
• Le registre : chaque résultat avec ses dates, son responsable, son statut et le lien vers le scan qui l'a produit.
• Les exceptions : chaque risque accepté avec son périmètre, sa justification, son approbateur et son expiration.

Combien coûte vraiment le faire soi-même ?

Les outils sont gratuits. Le travail, non : héberger et mettre à jour le registre, garder les parseurs en phase avec ce que sortent les scanners, relier les gravités à vos délais, et trier chaque semaine pour que le registre reste vrai. Chaque scanner et le registre publient leurs propres versions, et quelqu'un dans l'équipe doit les appliquer.

Ce choix est souvent le bon pour une équipe qui a un ingénieur plateforme et quelques dépôts. Il devient plus dur quand le nombre de dépôts et le rythme des changements montent, parce que le registre ne vaut que ce que vaut le dernier tri.

Qu'est-ce qui change quand des agents IA écrivent le code ?

Les agents de code comme Claude Code, Cursor, GitHub Copilot et OpenAI Codex multiplient les changements chaque semaine, donc les résultats arrivent plus vite et le registre doit suivre. Deux traces comptent davantage : le scan de chaque changement avant la fusion, et la personne qui a approuvé le changement écrit par un agent.

L'agent qui écrit le code peut aussi lancer l'audit. Avec CybeDefend Open Source, /cybedefend lance les scanners AppSec depuis l'agent de code à chaque changement, puis envoie ce même agent chercher les failles qu'ils ne voient pas et lui fait prouver chacune par un exploit écrit sous forme de test. Chaque résultat arrive dans la file avec le scan qui l'a produit, et le registre suit le rythme des agents. L'agent peut aussi proposer la correction, et le registre doit quand même montrer qui l'a relue et fusionnée, parce que l'auditeur contrôle l'approbation, pas le correctif. Notre guide SOC 2 sur les scans et les tests d'intrusion montre comment un résultat passe du scan d'un changement au rapport de la période.

Où se place CybeDefend ?

CybeDefend Open Source arrive bientôt, et il est fait pour la boucle que ce guide décrit. Une commande dans votre agent de code, /cybedefend, lance un audit complet en deux couches. D'abord les scanners AppSec, open source, en un docker compose up, dont Opengrep, Trivy, Gitleaks et zizmor, pour le code, les dépendances, les secrets, l'infrastructure as code, la CI/CD et les conteneurs. Vous gardez ceux que vous voulez et vous ajoutez les vôtres. Ensuite le scanner IA, lancé par votre agent de code. Les scanners cherchent des motifs. Le scanner IA lit ce que votre code est censé faire et trouve où il casse, dans la logique métier, dans les droits d'accès et dans les failles qui n'apparaissent qu'à l'exécution, puis il prouve chaque faille avec un exploit écrit sous forme de test.

Sous ces deux couches, il y a toute notre plateforme, un ASPM agentique, celle que nous hébergeons déjà sous le nom de CybeDefend Cloud. C'est elle qui tient le registre : les résultats de tous les scanners dans une seule file sans doublons, et une politique de sécurité écrite en code qui bloque la fusion sur un résultat critique, chaque exception étant limitée à un périmètre, datée, justifiée et approuvée nommément. Les rapports de sécurité relient les résultats à l'OWASP Top 10 et au CWE Top 25, exportés en PDF pour l'auditeur ou en JSON pour un outil GRC. Nous faisons le même exercice de notre côté : notre audit SOC 2 Type II est en cours. Si vous préparez le vôtre, nous pouvons le parcourir avec vous. Pour lancer l'audit sur votre propre code dès l'ouverture, rejoignez la liste d'attente de CybeDefend Open Source.

Questions fréquentes

DefectDojo est-il gratuit ?

L'édition Community de DefectDojo est open source, sous licence BSD-3-Clause, et gratuite à héberger soi-même. DefectDojo vend aussi une édition Pro, dans le cloud ou sur site. L'édition Community importe les résultats, retire les doublons et suit les statuts ; vérifiez la page des éditions pour les fonctions dont vous avez besoin avant de bâtir dessus.

Quel est le meilleur outil open source de gestion des vulnérabilités ?

Tout dépend du rôle. Dependency-Track surveille les composants à partir des SBOM. DefectDojo tient un registre de résultats importés depuis plusieurs scanners. OpenVAS scanne serveurs et réseaux. CybeDefend Open Source enchaîne les scanners AppSec et un scanner IA lancé par votre agent de code, et tient une seule file soumise à vos politiques. Pour un audit, un montage courant associe un jeu de scanners et un registre.

ISO 27001 impose-t-elle des scans de vulnérabilités ?

La mesure A.8.8 ne cite pas le scan. Elle demande d'obtenir l'information sur les vulnérabilités techniques, d'évaluer votre exposition et de prendre les mesures appropriées. Scanner régulièrement est la façon habituelle de montrer les deux premiers points, et votre politique fixe la fréquence.

Quels délais de correction prévoir pour ISO 27001 ?

La norme n'en fixe aucun. Vous les définissez par gravité dans votre politique, et l'auditeur vérifie que vous les avez tenus. HighTable cite un calendrier qu'il dit largement accepté par les auditeurs : 48 heures pour une vulnérabilité critique, 7 jours pour une haute, 30 jours pour une moyenne et 90 jours pour une basse.

OpenCVE est-il un scanner de vulnérabilités ?

Non. OpenCVE surveille la publication des CVE pour les éditeurs et produits que vous suivez et vous alerte par e-mail, Slack ou webhook, avec le contexte CVSS, EPSS et KEV. Il ne lit ni votre code ni vos fichiers de dépendances : il travaille à côté d'un scanner SCA et ne le remplace pas.

CybeDefend existe-t-il en open source ?

Son édition open source, CybeDefend Open Source, arrive bientôt : toute notre plateforme, un ASPM agentique, gratuite à faire tourner sur vos propres serveurs. La commande /cybedefend enchaîne les scanners AppSec open source et un scanner IA lancé par votre agent de code, et range chaque résultat dans une seule file soumise à vos politiques. D'ici là, CybeDefend Cloud est la même plateforme, hébergée par nous. Rejoignez la liste d'attente de CybeDefend Open Source.