Skip to main content

Catch the bad dependency before it ships.

Almost every application is mostly other people's code. That is the point of a package ecosystem, and it is also where the risk lives. Supply-chain trouble arrives in two shapes:

  • A package you depend on has a known flaw. A CVE lands against a version you have pinned, and now you need to know whether it actually reaches your running code or is just noise in a transitive branch you never call.
  • A package gets hijacked or was never real. A maintainer's release is compromised, a look-alike name is squatted, or an AI coding assistant confidently imports a package that does not exist (until an attacker registers it for you). This is the newer failure mode, and it is the one that catches teams by surprise.

Vulkro covers both. The free Labs tools handle the "is this package trustworthy at all" question with no license and no account. The paid engine handles depth: reachability-ranked CVEs across five ecosystems, compromised-release detection, sub-second incident lookup, and the procurement paperwork (SBOM and reachability-backed VEX). Everything runs on your machine. Nothing is uploaded.

Malicious and hallucinated packages (free, in Labs)​

The fastest-growing supply-chain risk is not a stale CVE. It is a name that should never have been installed in the first place: a package an AI invented, a typosquat one keystroke off a real library, or a name a threat actor already registered as malware. Two free, keyless tools in Vulkro Labs address this, both open source:

Install the free Labs CLI:

curl -fsSL https://dist.vulkro.com/install-live.sh | bash

verify - is this package safe? Point it at a package name and it catches hallucinated / slopsquatted names, known-malicious packages, look-alike typosquats, known CVEs, and suspiciously new or low-reputation packages. Covers npm, PyPI, and crates.io.

foresee - the predictive slopsquat map. This one is proactive. It reads your real dependency stack, works out the plausible-but-absent names an AI is likely to invent next to the libraries you already use, checks the registry for those names, and writes a committable do-not-install guardrail. You get the warning before an assistant hallucinates the import, not after the malicious package is already in your lockfile.

Both are free and open source. They are the front door of the supply-chain story, and the only part of Vulkro that is open source.

Known vulnerabilities, ranked by reachability (paid engine)​

Install the paid engine:

curl -fsSL https://dist.vulkro.com/install.sh | bash

The closed, licensed engine does reachability-ranked dependency checks across five ecosystems: npm, PyPI, Go, Cargo, and Maven. Your manifests and lockfiles are matched offline against a signed local database that combines OSV, NVD, CISA KEV, and FIRST.org EPSS, refreshed daily.

The ranking is the point. A raw CVE list from a package audit is mostly noise: hundreds of advisories, most of them in code paths you never execute. Vulkro sorts the list so the ones that matter surface first:

  • Known-exploited issues (on the CISA KEV list) and high-EPSS issues rise to the top.
  • Issues in code you never call are ranked lower.

Vulkro ranks the reachable ones first. It does not claim to prove exploitability; it gives you a defensible order to work down instead of a flat wall of advisories. See the public benchmark for how the detection is measured, and the comparison page for how this lines up against the alternatives.

For the pre-install gate, vulkro slopcheck blocks hallucinated or slopsquatted package names before install, so the same protection that Labs offers ad-hoc runs as an enforced check in your pipeline.

Compromised releases​

A package can be entirely legitimate and then, for one release, not be. A maintainer account gets phished, a build server gets owned, and a hijacked version ships to millions of installs before anyone notices.

Vulkro carries a curated record of real supply-chain attacks: event-stream, ua-parser-js, xz, @solana/web3.js, and others. The moment your lockfile pins a hijacked release, you hear about it. This is not a generic CVE match; it is a specific catalog of "this exact version was compromised in a known incident," so a poisoned release is flagged the instant it appears in your tree.

Incident exposure in under a second​

When a new advisory drops or a package version makes the news, the question is always the same and always urgent: am I exposed?

vulkro respond answers "am I exposed to this advisory or package version" in under a second, offline, via a cached reverse index. You do not re-scan the world and you do not call out to a service. You ask once and get a straight answer from a local index of what you actually depend on. That turns a fire-drill into a lookup.

SBOM and reachability-backed VEX for procurement​

Security is increasingly a paperwork problem too. Customers, auditors, and procurement teams want a machine-readable bill of materials and a defensible answer for every flagged component.

Vulkro produces output in 23 machine-readable formats, all generated offline, including:

  • CycloneDX SBOM and SPDX for the standard bill of materials.
  • A Cryptographic BOM (CBOM) for the cryptography inventory that regulated procurement increasingly asks for.
  • Reachability-backed VEX in both OpenVEX and CycloneDX-VEX formats. The value here is that a not_affected verdict is backed by reachability analysis rather than asserted by hand, so when you tell a customer a CVE does not apply, there is analysis behind the claim.

Every one of these is produced on your machine. See the full feature list for the complete set of formats.

Everything offline, nothing uploaded​

The whole supply-chain workflow runs locally. Your manifests, lockfiles, and dependency graph never leave the machine. The signed vulnerability database ships to you and is matched offline, so there is no source or dependency inventory sitting in a vendor cloud. VULKRO_OFFLINE=1 hard-refuses every network call, which means the scan works in an air-gapped build and provably makes no outbound connection.

Get started​

Free Labs tools (open source, keyless), for the "is this package trustworthy" checks:

curl -fsSL https://dist.vulkro.com/install-live.sh | bash

Paid engine (closed, licensed), for reachability-ranked CVEs, compromised-release detection, vulkro respond, and SBOM / VEX output:

curl -fsSL https://dist.vulkro.com/install.sh | bash

Explore Labs · See the features · Compare · Read the benchmark