Skip to content

Back to the catalog

Bumblebee
github.comrepo

Bumblebee

Bumblebee is a single-binary, read-only inventory scanner for macOS/Linux developer endpoints that parses lockfiles, package-manager metadata, extension manifests, and MCP JSON configs into structured NDJSON component records. Given an exposure catalog (exact ecosystem/name/version matches), it emits finding records so responders can quickly answer "which machines have this compromised package right now" during a supply-chain incident, without executing package managers or reading source files. It ships baseline/project/deep scan profiles, a built-in selftest against embedded fixtures, and maintained threat-intel exposure catalogs built from public supply-chain campaign reporting.

TL;DR Read-only fleet inventory scanner that matches on-disk package/extension metadata against exposure catalogs for fast supply-chain incident response.
Document

What it is

Bumblebee (Perplexity, Go 1.25+, zero non-stdlib dependencies) is a one-shot, read-only endpoint scanner distributed as a single static binary. Each invocation performs one scan and exits; scheduling cadence is left to the runner (cron, launchd, systemd, MDM). It emits NDJSON package records and, when given an exposure catalog, finding records, ending every run with a scan_summary record that receivers use to decide whether to promote the run to current state.

How it works

It reads only the lockfiles, package-manager install metadata, extension manifests, and MCP JSON configs enumerated in docs/inventory-sources.md. It never executes a package manager (npm ls, pip show, go list) and never reads source files. Each package record carries a confidence field: high (exact identity and version from canonical metadata), medium (reliable identity, partial version/source), low (config/path/spec reference only — not proof of an installed version). Records include endpoint (hostname, os, arch, username, uid, device_id), profile, and a per-root root_kind so receivers can keep populations separate.

Preconditions / Affected

macOS and Linux developer endpoints. Profile constrains what gets walked: baseline and project refuse bare-home roots; only deep walks them. --root is required for deep, optional otherwise. --findings-only requires --exposure-catalog. --exposure-catalog accepts a JSON file or a directory of *.json catalogs, merged non-recursively — all files must share the same schema_version.

What to do

Install and verify before fleet rollout:

go install github.com/perplexityai/bumblebee/cmd/bumblebee@v0.1.1
bumblebee selftest
# selftest OK (2 findings in 1ms)

Selftest runs against embedded fake-package fixtures (bumblebee-selftest-evil@0.0.0) with no network calls; a non-zero exit means the local install can no longer detect what it should — use it as a pre-deployment smoke test. On-demand exposure scan against an advisory:

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

Preview resolved roots without scanning via bumblebee roots --profile baseline.

Caveats

A low confidence record is a reference, not evidence of an installed exact version — do not treat it as a confirmed hit during triage. Security-relevant handling to verify yourself: MCP host configs can carry credentials in their env blocks; Bumblebee parses these for server inventory but states it does not emit those values in its records. It answers only "does on-disk metadata match right now" — not what shipped (SBOM) or what ran (EDR).

Organisations named here

  • Perplexity Computer

Technologies named here

  • macOS developer endpoints
  • Linux developer endpoints
  • npm packages
  • PyPI packages
  • go packages
  • pnpm lockfiles
  • MCP JSON configs
  • Go
  • npm
  • PyPI
  • pnpm
  • Model Context Protocol

Techniques named here

  • Supply-chain response via on-disk metadata inventory
  • Wildcard version matching via "versions"