Was KROMSE erkennt
Open-Source-Schwachstellenscanner: was KROMSE genau erkennt
Ein Open-Source-Schwachstellenscanner listet die Drittanbieterkomponenten Ihrer Software auf und gleicht sie mit Schwachstellendatenbanken ab. KROMSE tut das für Repositories, SBOMs, Container-Images und Linux-basierte Firmware, und diese Seite führt genau auf, was es heute abdeckt und was nicht.
Free-Tarif, keine Kreditkarte erforderlich.
Wie ein CVE-Scanner funktioniert
Der Großteil des Codes in einem modernen Produkt ist Open Source. Ein Scanner erstellt aus Lockfiles, Manifesten oder den Dateien in einem Image eine Bestandsaufnahme dieser Komponenten und gleicht dann jede Komponente und Version mit Sicherheitshinweisen ab. Die Qualität des Ergebnisses hängt von beiden Hälften ab: Eine unvollständige Bestandsaufnahme verdeckt Schwachstellen, und ein Abgleich mit vielen Fehltreffern kostet Entwicklungszeit.
KROMSE listet Komponenten mit Syft auf und gleicht sie mit OSV-Scanner gegen OSV.dev ab, das Sicherheitshinweise aus Quellen wie der GitHub Advisory Database, PyPA, der Go-Schwachstellendatenbank und RustSec bündelt.
Ökosysteme und Lockfiles
Abhängigkeiten werden aus den Lockfiles und Manifesten gelesen, die OSV-Scanner unterstützt. Abgedeckt und in unserem eigenen Benchmark getestet sind: package-lock.json, yarn.lock, pnpm-lock.yaml, poetry.lock, uv.lock und Go-Module.
- JavaScript und TypeScript: npm (package-lock.json, npm-shrinkwrap.json), Yarn v1, pnpm (Lockfile v6 und v9).
- Python: Poetry, uv, pip-Requirements-Dateien und pyproject.toml.
- Go-Module, Rust (Cargo), Java (Maven und Gradle), PHP (Composer), Ruby (Bundler) und .NET-Projektdateien.
- Embedded- und Robotik-Manifeste werden in der Bestandsaufnahme aufgeführt: ROS package.xml, CMake, Conan, vcpkg, PlatformIO, Zephyr, ESP-IDF, Arduino, Yocto und Buildroot. Die meisten davon werden nicht mit Sicherheitshinweisen abgeglichen.
Mehr als Abhängigkeiten
Ein einziger Scan deckt auch die anderen Wege ab, auf denen bekannte Risiken in ein Produkt gelangen.
- Bösartige Pakete: Abhängigkeiten, die in der OpenSSF-Datenbank Malicious Packages aufgeführt sind, werden als kritisch markiert; die einzige Abhilfe ist das Entfernen.
- Quellcodeanalyse mit Opengrep und einem fest versionierten Regelwerk für C, C++, C#, Go, Java, JavaScript, TypeScript, Kotlin, Python, Scala und Swift (für C und C++ nur musterbasierte Prüfungen); eigene SARIF-Ergebnisse können Sie ebenfalls importieren.
- Secrets: Gitleaks prüft den gescannten Commit auf eingecheckte Zugangsdaten; die Werte werden geschwärzt und nie gespeichert.
- Fehlkonfigurationen: Trivy prüft Infrastructure as Code wie Terraform und Dockerfiles.
- Container-Images: Images in einer aus dem Internet erreichbaren Registry werden mit Trivy und Syft analysiert.
- Linux-basierte Firmware-Images: entpackt und geprüft, wobei Binärdateien offline mit NVD-basierten Daten abgeglichen werden.
Priorisieren, was zählt
Eine Liste von CVEs ist noch kein Plan. Jeder Befund mit einer CVE-Kennung wird mit dem Known-Exploited-Vulnerabilities-Katalog der CISA, der Ausnutzungswahrscheinlichkeit nach FIRST EPSS, NVD-Daten und der EU-Schwachstellendatenbank der ENISA angereichert. Daten zum Supportende stammen von endoflife.date.
Bei Go-Projekten kann eine Aufrufanalyse zeigen, ob Ihr Code die verwundbare Funktion tatsächlich aufruft. Für andere Sprachen zeigt KROMSE die Erreichbarkeit als nicht festgestellt an, statt zu raten.
Woher der Code kommt
KROMSE scannt GitHub-Repositories über seine GitHub App für die Scans, die nur Lesezugriff hat; KROMSE lehnt Installationen der Scan-App ab, die Schreibzugriff verlangen. Rook (Autofix) nutzt eine separate, optionale GitHub App namens Kromse Fix. Jeder aus dem Internet erreichbare Git-Host funktioniert über HTTPS mit einem Zugriffstoken, darunter GitLab. Pipelines können SBOMs mit einem API-Token des Arbeitsbereichs übermitteln, und SBOMs, Firmware-Images, SARIF- und VEX-Dateien lassen sich direkt hochladen.
Was KROMSE heute nicht erkennt
Grenzen offen zu benennen, gehört zum Nachweis. Zum Zeitpunkt dieser Prüfung nicht abgedeckt sind: Erreichbarkeit außerhalb von Go, Quellcodeanalyse für PHP, Ruby und Rust, Secrets in der Git-Historie, private oder On-Premises-Registries und Git-Server, der Upload von Container-Tarballs, durch Git-Pushes ausgelöste Scans, CVE-Abgleich für Conan- und PlatformIO-Komponenten, CSAF-Sicherheitshinweise von Herstellern sowie Website- oder API-Tests.
Heute in KROMSE verfügbar
Alles, was auf dieser Seite steht, läuft heute im Produkt; die Zusammenfassung:
- Bekannte Schwachstellen in Abhängigkeiten über OSV.dev, mit Kontext aus KEV, EPSS, NVD und der EUVD der ENISA.
- Bekannte bösartige Pakete, als kritisch markiert.
- Quellcodeanalyse für 11 Sprachen, Erkennung von Secrets und Prüfung auf Fehlkonfigurationen.
- Container-Images aus erreichbaren Registries und Linux-basierte Firmware-Images.
- Verständliche Erklärungen, CycloneDX- und SPDX-SBOMs sowie Export als CycloneDX VEX und OpenVEX.
Häufige Fragen
Welche Paketmanager unterstützt KROMSE?
Lockfiles und Manifeste für npm, Yarn v1, pnpm, Poetry, uv, pip, Go-Module, Cargo, Maven, Gradle, Composer, Bundler und .NET-Projekte werden über OSV-Scanner gelesen. Embedded- und Robotik-Manifeste wie ROS, Conan, Zephyr und Yocto werden in der Bestandsaufnahme aufgeführt, die meisten aber nicht mit Sicherheitshinweisen abgeglichen.
Welche Schwachstellendatenbanken nutzt KROMSE?
Der Abgleich nutzt OSV.dev, das die GitHub Advisory Database und Datenbanken der einzelnen Ökosysteme umfasst, dazu NVD-basierte Daten für Firmware-Binärdateien und die Datenbank von Trivy für Images. Befunde werden mit dem KEV-Katalog der CISA, FIRST EPSS, NVD und der EU-Schwachstellendatenbank der ENISA angereichert.
Erkennt KROMSE bösartige Pakete?
Ja, wenn eine Abhängigkeit in der OpenSSF-Datenbank Malicious Packages erscheint, die über OSV.dev veröffentlicht wird. Solche Befunde werden als kritisch markiert, und die einzige empfohlene Maßnahme ist das Entfernen. Pakete, die bösartig, aber noch nicht gelistet sind, lassen sich auf diese Weise nicht erkennen.
Was ist der Unterschied zwischen SCA und SAST?
Software Composition Analysis (SCA) prüft die Drittanbieterkomponenten, die Sie verwenden, auf bekannte Schwachstellen. Static Application Security Testing (SAST) durchsucht Ihren eigenen Quellcode nach unsicheren Mustern. KROMSE führt beides in einem Scan aus, zusammen mit Prüfungen auf Secrets und Fehlkonfigurationen.
Verändert KROMSE meinen Code?
Nicht von selbst. Der Scanner arbeitet nur lesend. Rook (Autofix) nutzt eine separate, optionale GitHub App namens Kromse Fix und öffnet, nur wenn Sie es einschalten, Pull Requests als Entwurf, die Sie prüfen und zusammenführen. KROMSE erklärt Befunde und schlägt Upgrades vor, und eine Person entscheidet, was geändert wird.
Ist der Open-Source-Scan kostenlos?
Es gibt einen Free-Tarif ohne Kreditkarte. Founder, Basic, Pro und Ultra kosten 59 €, 249 €, 749 € bzw. 999 € pro Monat (oder 590 €, 2.490 €, 7.490 € bzw. 9.990 € pro Jahr, zzgl. MwSt.) und erweitern Kapazität und Funktionen, etwa um geplante erneute Prüfungen Ihrer SBOMs; Enterprise ist auf Anfrage erhältlich.