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.
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 10mPreview 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"
Related in Supply Chain


