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 noch 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; 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 verbindet sich mit GitHub über eine App mit reinem Lesezugriff und lehnt Installationen ab, die Schreibzugriff verlangen. Jeder aus dem Internet erreichbare Git-Host funktioniert über HTTPS mit einem Zugriffstoken, darunter GitLab, Bitbucket und Azure DevOps. 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.
Als Nächstes geplant
Auf der Roadmap, noch nicht verfügbar. Die Termine sind Zielmarken, keine Zusagen; diese Seite wird an dem Tag aktualisiert, an dem eine Funktion live geht.
- Geplant · Q4 2026 (November)Plug-in für Coding-Agenten. Ein Plug-in für KI-Coding-Agenten wird jedes Paket prüfen, das der Agent vorschlägt, bevor es in den Code gelangt – auch Pakete, die es gar nicht gibt oder die erst vor wenigen Tagen veröffentlicht wurden.
- Geplant · Q4 2026 (November)KI-Korrekturvorschläge, von Menschen freigegeben. KROMSE wird Korrekturen für Befunde vorschlagen, mit KI formuliert und erst angewendet, nachdem eine Person in Ihrem Team sie freigegeben hat.
- Geplant · Q4 2026 (Dezember)Überwachung nach Ihrem Zeitplan, mit KI-Agenten. Erneute Scans werden nach einem Zeitplan laufen, den Sie festlegen, mit KI-Agenten, die neue Sicherheitshinweise verfolgen, einordnen, was davon zutrifft, Korrekturen vorschlagen und den Bericht zu Ihrer Prüfung entwerfen.
- Geplant · Q4 2026 (Dezember)Website- und API-Tests. KROMSE wird Websites und APIs auf Schwachstellen testen, ausschließlich auf Domains, bei denen Sie nachgewiesen haben, dass Sie sie kontrollieren.
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 noch 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?
Nein. Die GitHub-Verbindung hat nur Lesezugriff, KROMSE öffnet keine Pull Requests, und nichts, was es tut, verändert Ihr Repository. Es 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. Basic und Pro kosten ab 49 € bzw. 249 € pro Monat bei jährlicher Zahlung (59 € bzw. 299 € monatlich, zzgl. MwSt.) und erweitern Kapazität und Funktionen, etwa um geplante erneute Prüfungen Ihrer SBOMs; Enterprise ist auf Anfrage erhältlich.