In May 2026, Perplexity open-sourced a small Go binary called Bumblebee and picked up a few thousand GitHub stars for it within weeks. On paper it reads like every other "AI company ships a security tool" announcement that's flooded timelines this year. But read the design doc closely and Bumblebee is doing something almost contrarian: it is a supply-chain scanner that ships with no vulnerability database at all. No CVE feed. No built-in list of bad packages. No "we'll tell you what's dangerous." It scans your machine, tells you exactly what's installed and where, and then stops — waiting for you to hand it a list of names to look for.
That's not a limitation someone forgot to fix before the release. It's the entire design premise, and it's worth understanding why, because it says something about where the real gap in developer tooling currently sits — not in vulnerability databases, which are commoditized and plentiful, but in fast, low-friction visibility into what a fleet of developer laptops actually has sitting on disk, especially the newer categories (MCP servers, agent skills, editor extensions) that older scanners were never built to look at.
What Bumblebee actually is
Bumblebee is a read-only inventory and exposure-matching scanner for developer endpoints, written in Go with zero non-standard-library dependencies, requiring Go 1.25+ to build, and released under the Apache License 2.0. You install it with a single go install command or grab a static binary, run it against a machine, and it walks the filesystem looking for package-manager metadata, lockfiles, extension manifests, and MCP configuration files — never executing anything, never touching the network for threat intel, never requiring elevated privileges.
The ecosystems it currently understands: npm, pnpm, Yarn, and Bun for JavaScript; PyPI for Python; Go modules; RubyGems; Composer for PHP; Homebrew; VS Code and other editor extensions; browser extensions; and — notably, given who built it — MCP (Model Context Protocol) server configurations and AI agent skill definitions.
It emits everything as newline-delimited JSON (NDJSON), which is the detail that tells you who this tool is actually for. NDJSON isn't a format you read in a terminal; it's a format you pipe into jq, a SIEM, a fleet-management dashboard, or a spreadsheet during an incident. Bumblebee is built to be a component in a pipeline, not a standalone dashboard product.
How it works, mechanically
The architecture is deliberately narrow, and that narrowness is the interesting part.
Three scan profiles. A baseline scan checks global package roots and known toolchain locations — cheap enough to run on a schedule across a whole fleet via cron, launchd, or an MDM push script. A project scan targets configured development directories, useful for CI or a specific repo checkout. A deep scan walks broad, explicit roots like $HOME — the one you reach for during an actual incident, when you need to know everything a specific machine touched, not just the usual suspects.
Two record types. Every scan emits package records — one line per discovered component, with ecosystem, name, version, the source file it was read from, and a confidence level (high, medium, or low) reflecting how directly that metadata maps to a real installed package versus an inferred one. When you also pass an --exposure-catalog, the scanner cross-references every package record against it and emits finding records for exact (ecosystem, name, version) matches — or "*" to flag every version of a named package.
The catalog is BYO. This is the crux. An exposure catalog is just a JSON file the operator supplies — for example, a list of package names and versions pulled from a GitHub Security Advisory, an OSV.dev feed, or an internal incident-response bulletin ("we just learned left-pad-plus@3.2.1 was compromised, check everyone"). Bumblebee treats catalogs as trusted operator input; it does zero validation on where they came from, so the security model explicitly puts catalog integrity on you, not the tool.
It reads metadata, not truth. Bumblebee never executes package managers and never parses source code — it reads lockfiles and manifests as text. That's what makes it safe to run without a sandbox, but it also means it can miss anything installed outside a recognized manager's bookkeeping (a manually vendored dependency, a binary dropped into PATH, a global install the lockfile doesn't track).
MCP and agent-skill scanning is JSON-only, for now. It reads JSON-based MCP configs, but explicitly does not parse Codex's TOML config or Continue's YAML config — a real gap if your team standardizes on either. It does parse env blocks inside MCP configs (where credentials often live) but is careful to never emit the credential values themselves into its output records, only the fact that the block exists.
What running it actually looks like
The workflow is deliberately unglamorous. A baseline inventory scan is one command with no flags beyond the profile:
bumblebee scan --profile baseline --output inventory.ndjson
That produces one JSON object per line, something like:
{"type":"package","ecosystem":"npm","name":"left-pad-plus","version":"3.2.1","source":"/home/dev/app/package-lock.json","confidence":"high"}
{"type":"package","ecosystem":"mcp","name":"internal-search-mcp","version":"0.4.0","source":"/home/dev/.config/mcp/servers.json","confidence":"medium"}
To actually get findings instead of just an inventory, you write (or fetch) a catalog file — a flat JSON list of {ecosystem, name, version} tuples pulled from an advisory, an internal incident bulletin, or a converted OSV/GHSA feed — and pass it in:
bumblebee scan --profile deep --exposure-catalog ./ir-2026-08.json --output findings.ndjson
Now the matching engine runs, and any package record whose (ecosystem, name, version) tuple exact-matches (or matches a "*" wildcard entry) a catalog line gets emitted as a second, separate finding record referencing the original package record. There's also a bundled bumblebee selftest command specifically for validating a fleet deployment didn't silently break — worth noting because "the scanner ran but produced nothing" and "the scanner correctly found nothing" look identical in NDJSON unless you've verified the binary itself works first.
Nothing about this workflow is novel in isolation — plenty of tools read lockfiles and emit JSON. What's notable is how few moving parts there are between "we have a name we're worried about" and "here's every machine that has it," which is exactly the property you want under incident-response time pressure, when nobody wants to be debugging a scanner's own dependency chain at 2am.
What's actually new here
Traditional software composition analysis (SCA) tools — Snyk, Trivy, OSV-Scanner, Socket.dev — are built around the same core loop: parse your dependency tree, cross-reference it against a maintained vulnerability database (NVD, GHSA, OSV, or a proprietary feed), and rank findings by severity. That loop is mature and it works. It's also slow to extend to new categories of software, because someone has to go build and maintain a vulnerability database for that category before the loop produces any output.
Bumblebee skips that step entirely by not shipping a database. Instead it optimizes the other half of the problem — discovery — and covers surface area that mainstream SCA tools mostly ignore: MCP servers, agent skill directories, and editor/browser extensions sitting on a developer's actual machine, not just what's declared in a package.json. That's a deliberate bet that the bottleneck during an active incident isn't "do we know this package is bad" (you usually find that out from a GitHub advisory, a vendor email, or Twitter within hours) but "which of our 400 developer laptops actually have it, right now, so we can start remediation." Answering that second question with Snyk or Trivy today means either they already indexed the exact ecosystem you're worried about, or you're writing custom tooling under time pressure.
The other shift is scope of what counts as "supply chain." A year or two ago, that meant npm and PyPI packages. The explosion of MCP servers — installed by pointing a config file at a URL, often with zero registry, zero code review, and direct filesystem/network access granted to whatever agent loads them — and the parallel rise of "agent skills" as an installable unit, created a new, mostly unaudited category of code running with developer-level trust. Perplexity, as a company shipping its own agent products, is effectively acknowledging that its own ecosystem (and everyone else's MCP tooling) has outrun the auditing tools built for the npm era. That's the more interesting story here than "AI company releases scanner."
Why developers should actually care
The MCP/skills attack surface is real and currently under-tooled. Unlike an npm package, which goes through at least a registry publish step, an MCP server is often just "add this URL to a config file and restart your editor." There's no equivalent of npm audit for MCP servers yet, and most existing SCA products haven't caught up. If your team has developers installing MCP servers or agent skills from arbitrary sources — and if you use Claude Code, Cursor, or similar tools, some of your developers almost certainly are — you currently have close to zero visibility into what's actually configured across your fleet unless someone builds it themselves.
It's genuinely cheap to deploy. A zero-dependency static Go binary means no runtime to install, no Python virtualenv fights, no container image to maintain. You can push it via MDM, run it from a shell script in CI, or scp it to a machine during an incident and get structured output in seconds. That operational simplicity is worth more than it sounds during an actual fire drill, when the last thing you want is a scanner that itself needs pip install to run.
It composes instead of competing. Because it doesn't ship a vulnerability database, Bumblebee isn't trying to replace Snyk or Dependabot for day-to-day CVE triage — it slots in beside them as the fast, catalog-driven layer for "we have a specific list of known-bad things, tell us where they are." That's a narrower job than most SCA marketing promises, but it's a job those tools don't do well: turning a hand-written or advisory-sourced IOC list into a fleet-wide answer in minutes.
Read-only-by-design lowers the adoption bar. Security tooling that needs elevated privileges or that executes untrusted package manager commands is a harder sell to run broadly, especially on developer laptops people are protective of. A tool that only reads files with the invoking user's own permissions is much easier to get approved for wide rollout.
There's no vendor lock-in or seat pricing to negotiate. Snyk and similar platforms bill per developer or per scan volume, and once findings, suppressions, and policy exceptions live in someone else's dashboard, switching costs climb every month you use it. Bumblebee's entire state is a JSON catalog file and NDJSON output you own — nothing to export if you decide to stop using it, no dashboard history that only exists inside a vendor's product, and no minimum contract to get value from a single incident-response run. For a security-adjacent tool, that's a meaningfully lower-commitment way to try something before deciding whether it earns a permanent place in your stack.
Practical use cases
-
Incident response triage. A supply-chain compromise gets disclosed (a compromised npm maintainer account, a poisoned MCP server, a malicious VS Code extension). You build or receive an exposure catalog with the affected package/version, run a
deepscan across affected machines via your existing fleet-management tooling, and get exact hit/no-hit answers in NDJSON you can aggregate immediately — instead of asking every developer to manually check. -
Recurring baseline hygiene. Schedule
baselinescans across developer machines (Bumblebee explicitly leaves scheduling to the operator — cron, launchd, systemd timers, or MDM) and feed the package-record stream into existing observability, building your own historical inventory of what's actually installed across the org over time, independent of any single vulnerability feed. - MCP/agent-skill governance. Even without an exposure catalog, running Bumblebee just for its package-record output gives you a first real inventory of which MCP servers and agent skills are configured across your developers' machines — useful groundwork before you can even write a sane policy about what's allowed.
- Feeding a SIEM or data lake. NDJSON output is trivially ingestible by anything that speaks structured logs, so Bumblebee output can become one more signal source correlated against other endpoint telemetry, rather than a standalone report nobody reads.
- Vendor/advisory cross-checks without waiting on tool support. When a new ecosystem-specific advisory drops for something niche a mainstream SCA vendor hasn't indexed yet, you can convert the advisory into a catalog JSON file yourself and get an answer same-day.
-
Pre-acquisition or pre-merger due diligence. Because it needs no agent install and no elevated privileges, a
deepscan is a low-friction way to get an honest inventory of a codebase's actual runtime dependency footprint — including MCP tooling nobody wrote down anywhere — before two engineering orgs merge their infrastructure.
What the hype leaves out
Out of the box, it finds nothing. Because there's no bundled vulnerability database, running Bumblebee with no --exposure-catalog flag gives you an inventory and zero findings — full stop. Every piece of coverage I read framed this as "supply-chain scanner" without foregrounding that you, the user, are entirely responsible for sourcing, building, and maintaining the catalogs that make it useful for anything beyond inventory. That's a materially different value proposition than a tool like Trivy, which is useful the moment you install it.
macOS and Linux only. No Windows support is mentioned anywhere in the project's current scope. For organizations with a meaningful population of Windows developer machines, that's a real coverage gap, not a footnote.
Non-JSON MCP configs are invisible to it. Codex's TOML-based config and Continue's YAML config are explicitly unsupported. If your organization's AI tooling mix leans toward either, Bumblebee's MCP-scanning story is considerably weaker than the marketing framing ("covers MCP configs") implies.
Confidence levels imply a real false-positive/negative tradeoff that isn't quantified anywhere. The high/medium/low confidence field on package records is a tacit admission that metadata-only scanning is inherently approximate — a low-confidence inference from an ambiguous manifest could be wrong in either direction, and nothing in the public documentation gives you a sense of how often that happens in practice.
The exposure catalog is an unauthenticated trust boundary. The project's own security model states plainly that catalogs are trusted operator input with no integrity checking built in. That's a reasonable design choice for a tool this narrowly scoped, but it does mean the tool's actual security value is only as good as your organization's process for sourcing and vetting catalog files — which most teams don't have yet, because the tool that would consume such a catalog didn't exist until now.
It's read-only, which also means it's reactive. Bumblebee tells you what's already on disk. It does nothing to prevent installation of a malicious MCP server or extension in the first place, and nothing to alert you the moment something new appears — you have to keep re-running it.
How it stacks up
| Bumblebee | Trivy | OSV-Scanner | Snyk | |
|---|---|---|---|---|
| Built-in vulnerability database | None — bring your own catalog | Yes (aggregated feeds) | Yes (OSV.dev) | Yes (proprietary + public feeds) |
| Scans MCP servers / agent skills | Yes | No | No | No |
| Scans editor/browser extensions | Yes | No | No | No |
| Execution model | Filesystem-only, never executes packages | Filesystem + image/container scanning | Filesystem-only | Filesystem + some execution for language servers |
| Dependencies to run | Zero (single Go binary) | Single binary, some DB downloads | Single binary | Requires account/CLI + network |
| Output format | NDJSON | JSON, table, SARIF, etc. | JSON, table | Dashboard + JSON/SARIF |
| Best fit | Fast, catalog-driven fleet triage and inventory | Continuous CVE scanning (containers, IaC, code) | Continuous OSS vuln scanning, CI-friendly | Continuous vuln management + remediation workflow |
| License / model | Apache 2.0, self-hosted | Apache 2.0, self-hosted | Apache 2.0, self-hosted | Commercial SaaS (free tier) |
The honest way to read this table: Bumblebee isn't in the same competitive category as the other three for day-to-day vulnerability management. It's a narrower, faster tool for a specific job — "given a name, find it everywhere" — that happens to also cover ecosystems the others don't touch yet.
An independent read
Strip away the "Perplexity open-sources security tool" framing and what's left is a genuinely well-scoped piece of infrastructure: a zero-dependency, read-only inventory collector that's honest about being an inventory collector rather than overselling itself as a vulnerability scanner. That restraint is unusual — most tools in this space bundle a mediocre, partially-maintained vuln feed just so the demo has red findings in it. Bumblebee shipping with nothing to find by default is a credible signal that the team optimized for the tool being correct and trustworthy over it being immediately impressive.
The more interesting subtext is what it implies about Perplexity's own risk model. A company aggressively shipping AI agent products — with their own MCP integrations and skill ecosystems — built and open-sourced the tool for auditing exposure to exactly that category of software, ahead of any major SCA vendor doing so at the same depth. Whether that's institutional foresight or a reaction to something specific that happened internally isn't stated publicly anywhere I found, and it's worth being clear that no incident is documented as the direct trigger — but the timing, arriving as MCP server adoption has scaled past what any registry currently governs, isn't coincidental.
Where I'd push back on the coverage I read: several pieces described it as filling "the SBOM gap" for AI tooling, which overstates it. An SBOM is a declarative, exhaustive manifest; Bumblebee is a point-in-time filesystem sample with confidence-scored inference. It's closer to find with structured output and a matching layer than to a true SBOM generator like Syft. That distinction matters if you're evaluating it for a compliance use case rather than an operational one.
I'd also flag a structural risk that the project's own documentation is upfront about but that coverage glossed over: the exposure-catalog trust boundary means the tool's usefulness is gated entirely on an organizational process — sourcing, validating, and maintaining catalog files — that most teams don't currently have, because until now there was no tool that consumed such a file. Open-sourcing the scanner doesn't automatically produce that process. A team that adopts Bumblebee expecting turnkey protection and never builds a habit of feeding it fresh catalogs will get a false sense of coverage from a tool that, by its own security model, found nothing because it was never told what to look for. The tool is honest about this; the risk is that not every adopter will read the security model closely enough to notice.
Who should try it, who should wait
Try it now if you're running incident response for a fleet of developer machines and currently have no fast way to answer "who has this package/version," or if you want a first honest inventory of what MCP servers and agent skills are actually configured across your engineering org — a question almost nobody currently has a good answer to.
Wait if your organization is meaningfully Windows-heavy, or if your AI tooling is built primarily around Codex or Continue configs rather than JSON-based MCP setups — you'll get materially reduced coverage until (if) those are added.
Skip it if what you actually need is continuous, automatically-updated CVE coverage with remediation guidance; that's not this tool's job, and pairing it with something like Snyk, Trivy, or OSV-Scanner rather than instead of them is the more accurate mental model.
What's your read on tools that deliberately ship with no built-in threat intelligence and put the burden of sourcing IOCs entirely on the operator — is that the right tradeoff for a fast, trustworthy incident-response tool, or does it just shift the hard part of the problem onto teams that don't have a mature process for maintaining exposure catalogs?
Sources:
Top comments (0)