SBOM and vulnerability scan for the CRA
Drop your lockfiles. You get a CycloneDX SBOM (Annex I Part II requires one) and the known vulnerabilities referenced by OSV.dev for your open-source components. The ones with confirmed active exploitation (CISA KEV) are flagged separately. That flag is a strong signal for the CRA reporting duty, which starts once your product is exposed and you know it. Nothing is uploaded: only package names and versions are sent to OSV.dev.
Supported:
…or paste a manifest
Run the same scan in your CI
The scanner is an open-source CLI. Run it at every release and keep the SBOM with the artefacts. That is what Annex VII asks for.
# in your project folder npx crakit # writes sbom.cdx.json and prints known + actively exploited vulnerabilities npx crakit --fail-on-kev # exit code 2 when a KEV-listed vulnerability is found (CI gate) # GitHub Actions - uses: actions/setup-node@v4 - run: npx crakit --fail-on-kev
How it works
What is checked?
Your lockfile is parsed locally into package URLs (purl). They are sent to OSV.dev's batch API, which aggregates GitHub Advisories, PyPA, RustSec, Go, npm and more. Each advisory is then matched against the CISA Known Exploited Vulnerabilities catalogue by CVE identifier. If you give a manifest without a lockfile, version ranges are approximated by their lower bound and flagged as such.
Why is KEV the CRA signal?
Article 14 requires reporting of vulnerabilities that are “actively exploited”. KEV lists vulnerabilities with confirmed exploitation. So a KEV hit in a dependency is your cue to check today whether your product exposes that code path. If it does and the product is shipped, the 24-hour clock runs from the moment you know.
Limits
OSV covers open-source ecosystems, not your own code or closed-source SDKs. Transitive dependencies are covered when a lockfile is provided. Maven properties and Gradle are not resolved. For those, use the CycloneDX Maven/Gradle plugins and upload the resulting bom.json instead.