Ce que détecte KROMSE
Scanner de vulnérabilités open source : exactement ce que KROMSE détecte
Un scanner de vulnérabilités open source recense les composants tiers de votre logiciel et les confronte à des bases de données de vulnérabilités. KROMSE le fait pour les dépôts, les SBOM (nomenclature des logiciels), les images de conteneurs et les firmwares basés sur Linux, et cette page détaille exactement ce qu’il couvre aujourd’hui et ce qu’il ne couvre pas.
Offre Free, sans carte bancaire.
Comment fonctionne un scanner de CVE
L’essentiel du code d’un produit moderne est open source. Un scanner dresse l’inventaire de ces composants à partir des fichiers de verrouillage, des manifestes ou des fichiers contenus dans une image, puis confronte chaque composant et sa version aux avis de sécurité. La qualité du résultat dépend des deux moitiés : un inventaire incomplet masque des vulnérabilités, et un rapprochement trop bruyant fait perdre du temps aux ingénieurs.
KROMSE liste les composants avec Syft et les rapproche avec OSV-Scanner des données d’OSV.dev, qui agrège les avis de sources comme la GitHub Advisory Database, PyPA, la base de vulnérabilités de Go et RustSec.
Écosystèmes et fichiers de verrouillage
Les dépendances sont lues à partir des fichiers de verrouillage (lockfiles) et des manifestes pris en charge par OSV-Scanner. Les suivants sont couverts et testés dans notre propre banc d’essai : package-lock.json, yarn.lock, pnpm-lock.yaml, poetry.lock, uv.lock et les modules Go.
- JavaScript et TypeScript : npm (package-lock.json, npm-shrinkwrap.json), Yarn v1, pnpm (lockfile v6 et v9).
- Python : Poetry, uv, fichiers requirements de pip et pyproject.toml.
- Modules Go, Rust (Cargo), Java (Maven et Gradle), PHP (Composer), Ruby (Bundler) et fichiers de projet .NET.
- Les manifestes embarqués et robotiques sont listés dans l’inventaire : ROS package.xml, CMake, Conan, vcpkg, PlatformIO, Zephyr, ESP-IDF, Arduino, Yocto et Buildroot. La plupart ne sont pas encore rapprochés des avis de sécurité.
Au-delà des dépendances
Une même analyse couvre aussi les autres voies par lesquelles un risque connu entre dans un produit.
- Paquets malveillants : les dépendances répertoriées dans la base OpenSSF Malicious Packages sont signalées comme critiques, la suppression étant la seule remédiation.
- Analyse du code source avec Opengrep et un jeu de règles figé pour C, C++, C#, Go, Java, JavaScript, TypeScript, Kotlin, Python, Scala et Swift ; vous pouvez aussi importer vos propres résultats SARIF.
- Secrets : Gitleaks recherche, dans le commit analysé, les identifiants qui y ont été commités ; les valeurs sont masquées et jamais stockées.
- Erreurs de configuration : Trivy vérifie l’infrastructure as code, comme Terraform et les Dockerfiles.
- Images de conteneurs : les images hébergées dans un registre accessible depuis internet sont analysées avec Trivy et Syft.
- Images firmware basées sur Linux : extraites et vérifiées, les binaires étant rapprochés hors ligne de données fondées sur la NVD.
Prioriser ce qui compte
Une liste de CVE n’est pas un plan. Chaque constat doté d’un identifiant CVE est enrichi avec le catalogue CISA Known Exploited Vulnerabilities, la probabilité d’exploitation FIRST EPSS, les données de la NVD et la base de données européenne des vulnérabilités de l’ENISA. Les données de fin de support proviennent d’endoflife.date.
Pour les projets Go, l’analyse des appels peut montrer si votre code appelle réellement la fonction vulnérable. Pour les autres langages, KROMSE indique que l’atteignabilité n’est pas établie plutôt que de deviner.
D’où vient le code
KROMSE se connecte à GitHub via une application en lecture seule et refuse les installations qui demandent un accès en écriture. Tout hébergeur git en HTTPS accessible depuis internet fonctionne avec un jeton d’accès, y compris GitLab, Bitbucket et Azure DevOps. Les pipelines peuvent envoyer des SBOM avec un jeton d’API d’espace de travail, et les SBOM, les images firmware, les fichiers SARIF et VEX peuvent être importés directement.
Ce que KROMSE ne détecte pas aujourd’hui
Être explicite sur les limites fait partie des preuves. Les éléments suivants ne sont pas couverts à la date de cette révision : l’atteignabilité en dehors de Go, l’analyse du code source pour PHP, Ruby et Rust, les secrets dans l’historique git, les registres et serveurs git privés ou sur site, l’import d’images de conteneurs sous forme d’archive tar, les analyses déclenchées par un push git, le rapprochement de CVE pour les composants Conan et PlatformIO, les avis CSAF des fournisseurs, et les tests de sites web ou d’API.
Disponible aujourd’hui dans KROMSE
Tout ce qui figure sur cette page fonctionne aujourd’hui dans le produit ; en résumé :
- Les vulnérabilités connues des dépendances via OSV.dev, avec le contexte KEV, EPSS, NVD et ENISA EUVD.
- Les paquets malveillants connus, signalés comme critiques.
- L’analyse du code source pour 11 langages, la détection de secrets et la vérification des erreurs de configuration.
- Les images de conteneurs issues de registres accessibles et les images firmware basées sur Linux.
- Des explications en langage clair, des SBOM CycloneDX et SPDX, et l’export VEX aux formats CycloneDX VEX et OpenVEX.
Prochainement
Sur la feuille de route, pas encore disponible. Les dates sont des objectifs, pas des promesses ; cette page change le jour où une fonctionnalité est mise en service.
- À venir · T4 2026 (novembre)Plug-in pour agents de codage. Un plug-in pour les agents de codage IA vérifiera chaque paquet proposé par l’agent avant son intégration, y compris les paquets qui n’existent pas ou qui n’ont été publiés que quelques jours plus tôt.
- À venir · T4 2026 (novembre)Correctifs proposés par l’IA, approuvés par une personne. KROMSE proposera des correctifs pour les constats, rédigés avec l’IA et appliqués uniquement après l’approbation d’une personne de votre équipe.
- À venir · T4 2026 (décembre)Surveillance selon votre calendrier, avec des agents IA. Les nouvelles analyses s’exécuteront selon un calendrier que vous définirez, avec des agents IA qui surveilleront les nouveaux avis de sécurité, trieront ceux qui s’appliquent, proposeront des correctifs et prépareront le rapport pour votre revue.
- À venir · T4 2026 (décembre)Tests de sites web et d’API. KROMSE recherchera des vulnérabilités dans les sites web et les API, uniquement sur les domaines dont vous aurez vérifié que vous les contrôlez.
Questions fréquentes
Quels gestionnaires de paquets KROMSE prend-il en charge ?
Les fichiers de verrouillage et les manifestes de npm, Yarn v1, pnpm, Poetry, uv, pip, des modules Go, de Cargo, Maven, Gradle, Composer, Bundler et des projets .NET sont lus via OSV-Scanner. Les manifestes embarqués et robotiques comme ROS, Conan, Zephyr et Yocto sont listés dans l’inventaire, mais la plupart ne sont pas encore rapprochés des avis de sécurité.
Quelles bases de données de vulnérabilités KROMSE utilise-t-il ?
Le rapprochement s’appuie sur OSV.dev, qui inclut la GitHub Advisory Database et les bases propres à chaque écosystème, ainsi que sur des données fondées sur la NVD pour les binaires des firmwares et sur la base de Trivy pour les images. Les constats sont enrichis avec le catalogue CISA KEV, FIRST EPSS, la NVD et la base de données européenne des vulnérabilités de l’ENISA.
KROMSE détecte-t-il les paquets malveillants ?
Oui, lorsqu’une dépendance figure dans la base OpenSSF Malicious Packages publiée via OSV.dev. Ces constats sont marqués comme critiques, et la seule action recommandée est la suppression. Les paquets malveillants qui ne sont pas encore répertoriés ne peuvent pas être détectés de cette manière.
Quelle est la différence entre SCA et SAST ?
L’analyse de la composition logicielle (SCA) confronte les composants tiers que vous utilisez aux vulnérabilités connues. Les tests statiques de sécurité des applications (SAST) examinent votre propre code source à la recherche de schémas non sécurisés. KROMSE exécute les deux dans une même analyse, avec la détection de secrets et la vérification des erreurs de configuration.
KROMSE modifie-t-il mon code ?
Non. La connexion GitHub est en lecture seule, KROMSE n’ouvre pas de pull requests et rien de ce qu’il fait ne modifie votre dépôt. Il explique les constats et suggère des mises à niveau ; une personne décide de ce qu’il faut changer.
L’analyse open source est-elle gratuite ?
Il existe une offre Free, sans carte bancaire. Basic et Pro démarrent à 49 € et 249 € par mois en facturation annuelle (59 € et 299 € en mensuel, hors TVA) et ajoutent de la capacité et des fonctionnalités comme la revérification planifiée de vos SBOM ; l’offre Enterprise est disponible sur demande.