What KROMSE detects
Open source vulnerability scanner: exactly what KROMSE detects
An open source vulnerability scanner lists the third-party components in your software and checks them against vulnerability databases. KROMSE does this for repositories, SBOMs, container images and Linux-based firmware, and this page lists exactly what it covers today and what it does not.
Free plan, no card required.
How a CVE scanner works
Most of the code in a modern product is open source. A scanner builds an inventory of those components from lockfiles, manifests or the files inside an image, then matches each component and version against advisories. The quality of the result depends on both halves: an incomplete inventory hides vulnerabilities, and a noisy match wastes engineering time.
KROMSE lists components with Syft and matches them with OSV-Scanner against OSV.dev, which aggregates advisories from sources such as the GitHub Advisory Database, PyPA, the Go vulnerability database and RustSec.
Ecosystems and lockfiles
Dependencies are read from the lockfiles and manifests that OSV-Scanner supports. These are covered and tested in our own benchmark: package-lock.json, yarn.lock, pnpm-lock.yaml, poetry.lock, uv.lock and Go modules.
- JavaScript and TypeScript: npm (package-lock.json, npm-shrinkwrap.json), Yarn v1, pnpm (lockfile v6 and v9).
- Python: Poetry, uv, pip requirements files and pyproject.toml.
- Go modules, Rust (Cargo), Java (Maven and Gradle), PHP (Composer), Ruby (Bundler) and .NET project files.
- Embedded and robotics manifests are listed in the inventory: ROS package.xml, CMake, Conan, vcpkg, PlatformIO, Zephyr, ESP-IDF, Arduino, Yocto and Buildroot. Most of these are not yet matched to advisories.
Beyond dependencies
A single scan also covers the other ways known risk gets into a product.
- Malicious packages: dependencies listed in the OpenSSF Malicious Packages database are flagged as critical, with removal as the only remedy.
- Source-code analysis with Opengrep and a pinned rule set for C, C++, C#, Go, Java, JavaScript, TypeScript, Kotlin, Python, Scala and Swift; you can also import your own SARIF results.
- Secrets: Gitleaks checks the scanned commit for committed credentials; the values are redacted and never stored.
- Misconfiguration: Trivy checks infrastructure-as-code such as Terraform and Dockerfiles.
- Container images: images in a registry reachable from the internet are analysed with Trivy and Syft.
- Linux-based firmware images: unpacked and checked, with binaries matched offline against NVD-based data.
Prioritising what matters
A list of CVEs is not a plan. Each finding with a CVE identifier is enriched with the CISA Known Exploited Vulnerabilities catalogue, the FIRST EPSS exploitation probability, NVD data and ENISA's EU Vulnerability Database. End-of-support data comes from endoflife.date.
For Go projects, call analysis can show whether your code actually calls the vulnerable function. For other languages KROMSE shows reachability as not established rather than guessing.
Where the code comes from
KROMSE connects to GitHub through an app with read-only access and refuses installations that ask for write access. Any HTTPS git host reachable from the internet works with an access token, including GitLab, Bitbucket and Azure DevOps. Pipelines can push SBOMs with a workspace API token, and SBOMs, firmware images, SARIF and VEX files can be uploaded directly.
What KROMSE does not detect today
Being explicit about limits is part of the evidence. The following are not covered at the time of this review: reachability outside Go, source analysis for PHP, Ruby and Rust, secrets in git history, private or on-premises registries and git servers, container tarball uploads, scans triggered by git pushes, CVE matching for Conan and PlatformIO components, vendor CSAF advisories, and website or API testing.
Available in KROMSE today
Everything listed on this page runs in the product today; the summary:
- Known vulnerabilities in dependencies via OSV.dev, with KEV, EPSS, NVD and ENISA EUVD context.
- Known malicious packages flagged as critical.
- Source analysis for 11 languages, secrets detection and misconfiguration checks.
- Container images from reachable registries and Linux-based firmware images.
- Plain-language explanations, CycloneDX and SPDX SBOMs, and CycloneDX VEX and OpenVEX export.
Coming next
On the roadmap, not available yet. Dates are targets, not promises; this page changes the day a capability is live.
- Coming · Q4 2026 (November)Coding-agent plug-in. A plug-in for AI coding agents will check every package the agent proposes before it lands, including packages that do not exist or were published only days ago.
- Coming · Q4 2026 (November)AI fix proposals, approved by a person. KROMSE will propose fixes for findings, written with AI and applied only after a person on your team approves them.
- Coming · Q4 2026 (December)Monitoring on your schedule, with AI agents. Rescans will run on a schedule you set, with AI agents that watch for new advisories, triage what applies, propose fixes and draft the report for your review.
- Coming · Q4 2026 (December)Website and API testing. KROMSE will test websites and APIs for vulnerabilities, only on domains you have verified you control.
Frequently asked questions
Which package managers does KROMSE support?
Lockfiles and manifests for npm, Yarn v1, pnpm, Poetry, uv, pip, Go modules, Cargo, Maven, Gradle, Composer, Bundler and .NET projects are read through OSV-Scanner. Embedded and robotics manifests such as ROS, Conan, Zephyr and Yocto are listed in the inventory, but most are not yet matched to advisories.
Which vulnerability databases does KROMSE use?
Matching uses OSV.dev, which includes the GitHub Advisory Database and ecosystem databases, plus NVD-based data for firmware binaries and Trivy's database for images. Findings are enriched with the CISA KEV catalogue, FIRST EPSS, NVD and ENISA's EU Vulnerability Database.
Does KROMSE detect malicious packages?
Yes, when a dependency appears in the OpenSSF Malicious Packages database published through OSV.dev. Such findings are marked critical, and the only recommended action is removal. Packages that are malicious but not yet listed cannot be detected this way.
What is the difference between SCA and SAST?
Software composition analysis (SCA) checks the third-party components you use against known vulnerabilities. Static application security testing (SAST) reads your own source code for insecure patterns. KROMSE runs both in one scan, together with secrets and misconfiguration checks.
Does KROMSE change my code?
No. The GitHub connection is read-only, KROMSE does not open pull requests and nothing it does modifies your repository. It explains findings and suggests upgrades, and a person decides what to change.
Is the open-source scan free?
There is a Free plan with no card required. Basic and Pro start at €49 and €249 per month billed annually (€59 and €299 billed monthly, excluding VAT) and add capacity and features such as scheduled re-checks of your SBOMs; Enterprise is available on application.