Skip to main content

Am I exposed? Answered in under a second, offline.

It is 3am and an advisory just dropped. A dependency you might be pulling in (directly or five levels deep) has a fresh CVE, or a maintainer account got hijacked and a poisoned release went out to a registry your lockfiles pin against. The only question that matters right now is: am I exposed to this specific package@version, and if so, where.

Most teams answer that by grepping lockfiles by hand, opening the dependency tree in a browser tab, and guessing, and the tree is bigger than it used to be: AI assistants add dependencies as readily as they write code. Vulkro answers the question on your machine, with nothing uploaded.

Where this sits in the lifecycle​

Vulkro's spine is the pre-deploy lifecycle: catch the flaw while you build. Incident response is the edge case that spine has to handle anyway: the code did not change, the world did. The paid Vulkro engine owns this page: vulkro respond for the instant exposure check, the reachability-ranked dependency scan for the triage order, and the compromised-release catalog for the hijack case.

Instant exposure check: vulkro respond​

vulkro respond answers "am I exposed to this advisory or this package@version" offline. It walks your lockfiles plus per-file imports (direct and transitive) through a cached reverse index, so the moment you paste in the affected package it tells you whether you pull it, which of your files reach it, and by what path.

# When an advisory drops:
vulkro respond --package [email protected] .
vulkro respond --advisory SUP-COMPROMISE-001 .

On a typical project the answer comes back in under a second, because the reverse index is cached locally and invalidated only when a lockfile changes. It reads npm package-lock.json, Poetry poetry.lock, Pipfile.lock, Cargo.lock, and go.sum, plus per-file imports across JS/TS, Python, Go, and Rust, and reports both direct importers and transitive dependents by file and line. The exit code is part of the answer: 0 clean, 1 exposed, so the same command drops straight into a script or a CI job.

This is built for the advisory-drop moment. No upload, no waiting on a cloud scan queue. When the security channel lights up, you get to say "we pin it in two services, here are the files" before the thread has finished loading.

If all you have is a package name and you want a fast, free second opinion, the open-source Vulkro Labs tool answers "is this specific package safe" too:

curl -fsSL https://dist.vulkro.com/install-live.sh | bash
vulkro-live verify <package>

The vulkro engine itself stays closed and licensed. vulkro-live is the free, open-source Labs tool, and it is the fastest way to sanity-check a single package the instant an advisory lands.

Reachability, so you fix the reachable ones first​

A CVE list sorted by CVSS is noise at 3am. Vulkro's dependency checks are reachability-ranked: they combine OSV, NVD, CISA KEV, and FIRST.org EPSS (all offline, from a signed bundle) and rank so that what you can actually reach rises to the top.

When a new CVE lands, KEV entries and high-EPSS issues rise, and issues sitting in code you never call rank lower (downgraded and stamped, never silently dropped). The result is a worklist you can act on in order, instead of a wall of equal-weight advisories.

Vulkro ranks reachable findings first, and cites the call chain: entry point -> ... -> vulnerable symbol, with file and line hops, in the finding's evidence. It does not claim to prove exploitability. The point is triage: spend the first hour on the CVE that sits in a code path your app actually executes and that attackers are actively using, not on the one buried in a dev-only transitive you never import.

Compromised releases, the moment your lockfile pins one​

Reachability handles the CVE case. The other 3am case is a supply-chain compromise: a hijacked release, a maintainer takeover, a poisoned post-install script. Vulkro ships a compromised-release catalog covering known incidents (event-stream, ua-parser-js, xz, @solana/web3.js, and the growing list of others). The moment your lockfile pins one of those hijacked releases, you hear about it.

That turns "did the thing I read about on the security feed touch us" from an afternoon of manual archaeology into a one-command answer.

Attack paths to your critical sinks​

Knowing you are exposed is step one. Knowing whether the exposed code sits behind an auth check is step two. The desktop console's Attack paths view walks each detected entry point forward through the call graph to the reachable critical sinks (raw SQL, subprocess, file writes, network callouts) and flags the hops that are missing an auth check.

During an incident that tells you which paths are reachable from an unauthenticated request, so you can prioritise the one a stranger on the internet can hit over the one that requires an admin session. Ranked and evidenced, not proven exploitable.

Everything offline, nothing uploaded​

Every step here runs on your machine. vulkro respond, the reachability ranking, the compromised-release catalog, and the attack-path view all read local state and a signed offline bundle. Your source, your lockfiles, and your dependency graph never leave the machine, so incident response does not become its own data-handling event that your security team has to sign off on.

Where the boundaries are​

Being precise about what this is:

  • Exposure, not compromise. Vulkro tells you whether you pull the affected package and where. It does not analyse logs, hunt indicators of compromise, or tell you whether the flaw was exploited on your systems. If you were exposed, forensics is a different discipline and a different tool.
  • respond covers the lockfiles it can read. npm, Poetry / Pipfile, Cargo, and Go lockfiles, plus JS/TS, Python, Go, and Rust imports. Maven dependencies are covered by the dependency-CVE scan, not by the respond reverse index.
  • The answer is as fresh as your bundle. The advisory match runs against the signed CVE snapshot on your disk. Run vulkro update when an advisory drops; the lookup itself never calls out.
  • Ranking is not proof. Reachability and attack paths order the work and cite the evidence. They do not prove a path is exploitable in production.

Get started​

curl -fsSL https://dist.vulkro.com/install.sh | bash
vulkro login   # first login starts the 14-day trial

# When an advisory drops:
vulkro respond --package <name@version> .

See the full feature list for how respond, the reachability ranking, and the attack-path view fit together, the supply-chain page for the dependency and compromised-release coverage, and the comparison for how offline triage stacks up against cloud SAST. The benchmark has the reproducible detection numbers.