Modern attackers are shifting upstream: the most vulnerable surface in many technology companies is no longer the production server, but the messy, highly permissioned laptop of a software engineer.
For the last decade, security teams have focused obsessively on locking down production environments. We built robust CI/CD pipelines, mandated Software Bills of Materials (SBOMs) for build artifacts, and deployed Endpoint Detection and Response (EDR) agents to monitor servers.
But as the CircleCI and LastPass breaches demonstrated, modern attackers increasingly target upstream systems and developer access. That problem has accelerated with AI coding agents.
Developers are rapidly installing third-party VS Code and Cursor extensions, experimental browser add-ons, and local Model Context Protocol (MCP) servers that give AI assistants access to file systems and databases. When a zero-day lands in a popular npm package or an MCP server is hijacked, security teams face a basic blind spot: who has this installed right now?
SBOMs tell you what shipped. EDR tells you what ran. Neither provides a clean inventory of everything sitting on a developer endpoint.
To bridge that gap, Perplexity open-sourced Bumblebee, a lightweight, read-only supply-chain scanner for macOS and Linux developer endpoints.
What Is Bumblebee?
Bumblebee is a focused inventory collector written in Go. It rapidly scans a developer machine for installed packages, extensions, and AI-tool configurations, then emits its findings as structured NDJSON.
During an incident, responders can provide a manually curated exposure catalog containing known-bad package names and versions. Bumblebee compares that catalog against local disk state and flags direct matches.
Its coverage is built around four surfaces in the modern developer stack:
- Language package managers: npm, pnpm, Yarn, Bun, PyPI, Go modules, RubyGems, and Composer.
- Editor extensions: VS Code and related editors, including Cursor, Windsurf, and VSCodium.
- Browser extensions: Chromium-based browsers—including Chrome, Edge, Arc, Brave, and Comet—plus Firefox.
- AI agent configurations: MCP host configuration files.
Architectural Strengths: Why It Is Built Differently
A local inventory scanner may sound straightforward, but Bumblebee makes several deliberate engineering choices that make fleet-wide deployment practical.
1. Read-Only by Design
A common internal-security shortcut is to run commands such as npm ls or pip show on every endpoint. That approach invokes package-manager code while investigating a potentially compromised dependency—the exact boundary a defensive scanner should avoid crossing.
Bumblebee does not execute package managers. It reads files such as package-lock.json, go.mod, .dist-info/METADATA, and extension manifests directly from disk. The scan remains passive even when the installed tooling is untrusted.
2. Zero Non-Stdlib Dependencies
Bumblebee compiles to a single Go 1.25 binary using only the standard library. It requires no Python environment, package-manager runtime, or external library, which reduces deployment friction and keeps the scanner’s own software supply chain small.
3. Smart Secrets Filtering
MCP host configurations often contain database URIs, API keys, and environment variables. Bumblebee inventories configured MCP servers while dropping environment values and credentials from emitted NDJSON records. Security teams see the installed surface without copying developer secrets into centralized logs.
The Three Scan Profiles
Bumblebee offers three profiles so teams can balance coverage against scan cost and cadence:
| Profile | Best For | Behavior |
|---|---|---|
baseline | Daily or weekly fleet scans | Checks predictable locations for global packages, language toolchains, editor extensions, and MCP configurations. |
project | Active development workspaces | Sweeps configured roots such as ~/code or ~/src for project lockfiles and metadata. |
deep | Targeted incident response | Walks broader custom roots—potentially the entire home directory—against a specific exposure catalog. |
Hands-On: Deploying Bumblebee
Installation requires a standard Go toolchain. After installing the latest release, run the built-in self-test to validate the binary against its embedded fixtures.
# Install the latest versiongo install github.com/perplexityai/bumblebee/cmd/bumblebee@latest# Validate the binary against embedded fixturesbumblebee selftestPerforming a Routine Baseline Scan
A baseline scan produces an NDJSON inventory that can be forwarded to systems such as Datadog, Splunk, or Elasticsearch.
bumblebee scan --profile baseline > inventory.ndjsonRapid Incident Response
When threat intelligence identifies compromised package or extension versions, responders can create an exposure-catalog.json containing those signatures and run a targeted deep scan. With --findings-only, Bumblebee emits records only when it finds a direct match.
bumblebee scan --profile deep \ --root "$HOME" \ --exposure-catalog ./catalog.json \ --findings-only \ --max-duration 10mWhere Bumblebee Fits in the Stack
Bumblebee is not an automated vulnerability feed like Dependabot, and it is not an active runtime-protection product like CrowdStrike. It is an inventory-mapping tool designed to connect threat intelligence with endpoint exposure.
Perplexity’s workflow pairs Bumblebee with human review and AI-assisted catalog creation:
- An emerging threat is identified through a public disclosure.
- An AI agent drafts a structured exposure-catalog update containing the affected package names and versions.
- A human security engineer reviews and merges the update.
- Bumblebee uses the catalog to check the developer fleet for direct exposure.