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 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 (C et C++ ne bénéficient que de contrôles basés sur des motifs) ; 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 analyse les dépôts GitHub via son application GitHub d’analyse, qui est en lecture seule ; KROMSE refuse les installations de l’application d’analyse qui demandent un accès en écriture. Rook (Autofix) utilise une application GitHub distincte et facultative appelée Kromse Fix. Tout hébergeur git en HTTPS accessible depuis internet fonctionne avec un jeton d’accès, y compris GitLab. 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.
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 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 ?
Pas de lui-même. Le scanner est en lecture seule. Rook (Autofix) utilise une application GitHub distincte et facultative appelée Kromse Fix et, uniquement si vous l’activez, ouvre des pull requests en brouillon que vous examinez et fusionnez. KROMSE 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. Founder, Basic, Pro et Ultra coûtent 59 €, 249 €, 749 € et 999 € par mois (ou 590 €, 2 490 €, 7 490 € et 9 990 € par an, 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.