0

Bumblebee: the read-only scanner that tells you if you're already exposed

Perplexity open-sourced Bumblebee, a read-only supply-chain inventory scanner for dev machines. It never runs your package managers — which is exactly the point.

By YoloBytes Team ·

In the last post the question was how do I stop a malicious npm install? This one answers the other half: when an advisory drops, am I already exposed? That's the job of Bumblebee, the read-only supply-chain scanner Perplexity just open-sourced — and the subject of this video.

The problem it solves

A popular package gets compromised. An advisory names some-pkg@1.2.3. Now every engineering org on earth asks the same frantic question: which of our machines actually have that on disk right now? Bumblebee is built to answer exactly that — fast, across many ecosystems, on every developer endpoint.

The clever part: it refuses to run your code

Most "scan your dependencies" tools resolve or install packages to inspect them. That's a problem, because installing is how the attack fires — a single postinstall hook runs the moment a package manager touches it.

Bumblebee is a read-only inventory collector. It reads lockfiles, package-manager metadata, extension manifests, and MCP configs — and it never executes a package manager, never runs install scripts, never even reads your source files. Scanning can't trigger the very thing you're scanning for. It's a single Go binary (Go 1.25+, zero non-stdlib dependencies), macOS and Linux.

What it inventories

Far more than npm. Bumblebee knows about:

  • JS: npm, pnpm, Yarn, Bun
  • Others: PyPI, Go modules, RubyGems, Composer (PHP), Homebrew
  • AI/agent surface: MCP configs and agent skills
  • Editors: VS Code, Cursor, Windsurf, VSCodium extensions
  • Browsers: Chromium and Firefox extensions

That browser/editor/MCP coverage matters — supply-chain attacks have moved well beyond node_modules.

Using it

Install the binary:

go install github.com/perplexityai/bumblebee/cmd/bumblebee@latest
bumblebee selftest

A lightweight, recurring inventory of the usual global locations:

bumblebee scan --profile baseline > inventory.ndjson

A sweep of your actual project directories:

bumblebee scan --profile project \
  --root "$HOME/code" \
  --root "$HOME/Developer"

And the incident-response mode — point it at a catalog of known-bad packages and let it find matches:

bumblebee scan --profile deep \
  --root "$HOME" \
  --exposure-catalog ./catalog.json \
  --max-duration 10m

You can also narrow to specific ecosystems (--ecosystem npm,pypi) or preview which roots a profile would touch (bumblebee roots --profile baseline).

The output is built for tooling

Results are NDJSON — one record per line, each either a package or a finding, content-addressed, tagged with the endpoint (hostname, OS, arch, user) and a confidence level (high/medium/low). Every run ends with a scan_summary. That format is deliberate: you pipe it into your SIEM, diff it across machines, or fan it out across a fleet during an incident.

Threat intel, in the open

The repo ships a threat_intel/ directory of exposure catalogs assembled from public reporting on real supply-chain campaigns, updated via pull requests as new ones surface. So "scan for the latest worm" becomes "pull the catalog, run a deep scan." It's Apache-2.0 licensed.

Where it fits

Prevention (ignore-scripts, allowlists, cooldowns, lockfile installs) lowers the odds you get hit. Bumblebee answers the question that matters once something has shipped: are we exposed, on which machines, right now? — without the scan itself becoming the breach. Worth a spot in your incident runbook.

Based on the video "Perplexity Open-Sourced a Scanner Every Dev Should Know (Bumblebee)". Project: github.com/perplexityai/bumblebee.