In May 2026, Perplexity open-sourced an internal security tool called Bumblebee, and within a week it had crossed a thousand GitHub stars. It's now sitting near 4.9k stars and 435 forks. That's a fast climb for a security CLI with no UI, no dashboard, and — this is the part worth dwelling on — no ability to actually stop an attack.
That last sentence isn't a criticism. It's the design. Bumblebee is not a malware detector, not a behavioral scanner, not a gatekeeper that blocks npm install when something looks sketchy. It doesn't try to figure out whether a package might be malicious. It answers one narrower, more mechanical question: when a supply-chain advisory names a specific compromised package and version, which of your machines have that exact thing sitting on disk right now?
That distinction is the actual story here, and it's one most of the coverage around the release skipped past in favor of the "Perplexity open-sources security tool" headline. Let's get into what it does, how it's built, and why the thing it deliberately refuses to do is more interesting than the thing it does.
Why this category exists at all
Software supply-chain compromise has settled into a handful of recurring shapes over the past few years: a maintainer's npm or PyPI account gets phished or credential-stuffed and a malicious version gets published under a trusted name; a typosquatted package name catches developers who fat-finger an install command; a postinstall script silently exfiltrates environment variables or SSH keys the moment npm install runs; a dependency-confusion attack tricks an internal build into pulling a public package instead of the private one it meant to reference. None of these require the attacker to compromise your infrastructure directly — they just have to get one bad artifact into a registry that your build already trusts.
What makes 2025-2026 different from the earlier waves of this problem is the addition of a new install surface that most existing tooling wasn't built to see: AI coding agents and their extension ecosystems. Developers now routinely add third-party MCP servers to Claude, Cursor, or other agent hosts, install "agent skills" from community repos, and grant those integrations filesystem and shell access with far less scrutiny than they'd apply to a new npm dependency. It's a fresh, largely unaudited install surface sitting right next to the well-trodden npm/PyPI one, and it's exactly the kind of thing a company that ships AI products would notice internally before the broader security tooling industry catches up. That's the backdrop Bumblebee was built against.
What happened
Perplexity's security team built Bumblebee as an internal tool for exactly the kind of incident that's become routine in 2025-2026: an npm or PyPI package gets compromised, a maintainer's token gets phished, a malicious version ships to the registry, and security teams everywhere scramble to answer "are we exposed?" across a fleet of developer laptops, CI runners, and now — increasingly — AI coding agent configurations.
They open-sourced the exact tool their own team uses for that sweep, under an Apache 2.0 license, as a single static Go binary with zero non-stdlib dependencies. The repo's README frames the goal directly: it "answers a narrow supply-chain response question... which developer machines show a match in their on-disk metadata right now?" Not "which machines are vulnerable." Not "which packages look suspicious." Which machines match a known-bad identity.
What it actually does
Bumblebee is a read-only inventory scanner. It walks a machine's filesystem, reads package-manager metadata and lockfiles, and checks what it finds against a bundled exposure catalog — records that pair an ecosystem, a package name, and a version (or version range) with a known compromise.
It ships three scan profiles that trade breadth for speed:
- baseline — common global and user package roots, language toolchains, editor extensions, browser extensions, and MCP configs. This is the "run this everywhere, fast" mode.
-
project — configured development directories (
~/code,~/src, whatever you point it at), for sweeping active repos. -
deep — arbitrary operator-supplied filesystem roots, including a bare
$HOME. The README is candid that this is the incident-response mode: you run it when you're already worried and need the exhaustive pass.
Ecosystem coverage is broad for a v0.1-era tool: npm, pnpm, Yarn, Bun, PyPI, Go modules, RubyGems, Composer, MCP host configurations, agent skill directories, and editor/browser extension manifests. That MCP and agent-skill coverage is not an afterthought — it's a signal about what Perplexity's own security team is actually worried about in 2026, and I'll come back to it.
How it works, mechanically
The architecture choices are the most telling part of the project, more than the feature list.
No execution, ever. The README states this as a hard rule: no npm ls, no pip show, no go list, no invoking any package manager, and no reading source files. Everything comes from parsing lockfiles, install metadata, dist-info directories, and JSON config files directly off disk. The stated reason is that package-manager invocations and postinstall scripts are themselves a common attack vector — you don't want your exposure-check tool to be the thing that triggers the payload it's checking for.
Zero non-stdlib dependencies. Written in Go 1.25+, compiled to a single static binary, with no third-party libraries in the dependency tree. For a normal CLI tool this would be a nice-to-have. For a tool you're specifically running because you suspect your supply chain is compromised, it's closer to a requirement — every dependency Bumblebee itself pulled in would be one more thing to trust during exactly the moment you trust nothing.
Confidence-scored output, not binary pass/fail. Findings come out as NDJSON records — package records, finding records, and scan-summary records — each package tagged with a confidence level:
- High — exact identity and version confirmed from canonical package-manager metadata.
- Medium — reliable identity, but partial version or source information.
- Low — a config or path reference exists, without proof the package is actually installed.
That gradation matters operationally. A fleet-wide sweep after an advisory drops doesn't need a false-positive storm; it needs "here are the machines we're sure about" separated from "here are the ones worth a human looking at."
The exposure catalog is the actual engine. Under the hood, the threat_intel/ directory in the repo holds structured records keyed by ecosystem, package name, and compromised version (or version range), each tied back to the advisory or incident that justified adding it. Scanning is essentially a large, fast set-intersection: everything Bumblebee finds on disk, checked against everything in that catalog. There's no scoring model, no machine learning, no reputation lookup against a live API — it's a deliberately boring lookup table, which is exactly what you want when the tool has to run somewhere you don't fully trust the network path either. A scan can run fully offline once the catalog is bundled, which matters more than it sounds during an incident where you may not want a compromised machine phoning home to anything, including your own security vendor.
One-shot by design. Bumblebee doesn't daemonize, doesn't watch the filesystem, and doesn't schedule itself. It's a snapshot tool. If you want continuous coverage, you wire it into cron, launchd, systemd, or your MDM yourself. This is consistent with the "narrow tool" philosophy but it's also the first thing that trips people up, based on the open issues in the repo — people expect a security tool in 2026 to be continuous by default, and Bumblebee explicitly isn't.
What's actually new here
Exposure-matching against known-bad package lists isn't a new idea — it's what npm audit, OSV-Scanner, and a dozen SBOM tools already do against CVE databases. What's different about Bumblebee is the combination of three things that don't usually travel together:
- It's read-only by hard architectural constraint, not just by convention, which is a meaningfully stronger trust story for a tool you run during an active incident.
- It treats MCP configs and AI agent skill directories as first-class scan targets, alongside npm and PyPI. That's new. Most existing supply-chain scanners were built before "install a third-party MCP server into your coding agent" was a routine developer action, and it shows — they don't look there. Bumblebee does, because Perplexity's own security team has to worry about it internally.
- It's explicitly not trying to be a detector. It has no heuristics for typosquatting, no behavioral analysis of package contents, no machine-learning risk score. It only matches against a curated catalog of packages already confirmed compromised. That's a narrower promise than most of its "competitors" make, and — this is the contrarian part — that narrowness is arguably the more honest design.
Why developers should care
Cost: free, Apache 2.0, no SaaS tier, no telemetry described in the README. Compare that to the commercial supply-chain security category, where per-seat pricing is standard.
Trust model: the zero-dependency, read-only, no-exec design is the actual product here, more than any individual feature. If you're going to run a security tool against a machine you suspect is compromised, "what does this tool itself depend on and what could it trigger" is not a hypothetical question.
Lock-in: none in the licensing sense, but real in the data sense — the tool is only as good as the exposure catalog bundled with it (or that you maintain yourself). Perplexity ships and updates a threat_intel/ catalog in the repo; how long they keep that current for the community, as opposed to just their own internal use, is an open question a young open-source project always carries.
DX: a single static binary you go install and run is about as low-friction as security tooling gets. No agents to deploy, no cloud account to create, no API key. That's a real advantage for fast incident response, where the last thing you want is an onboarding flow between "advisory drops" and "we know our exposure."
Maintainability: the narrow scope cuts both ways. It's easy to reason about what Bumblebee will and won't tell you, which is good for maintainability of your own security process. But it also means Bumblebee alone is not a complete supply-chain security program — more on that below.
Practical use cases
-
Post-advisory fleet sweep. An advisory names
left-pad@3.x.xas compromised (to pick a hypothetical in the spirit of past real incidents). You pushbumblebee scan --profile baselinevia your existing fleet management tooling and get back, within minutes, which developer machines have that exact version on disk. -
Incident response deep scan. Something's actively suspected on a specific machine. Run the
deepprofile against$HOMEand get an exhaustive inventory, not just the common package roots. - New-hire or new-machine baseline. Run it once against a freshly provisioned dev laptop before it joins the fleet, to catch anything already present from an image or dotfiles repo.
- AI agent supply-chain audit. Given how quickly teams are adding third-party MCP servers and agent skills to coding assistants, a periodic scan of those specific directories is a genuinely new use case that older SCA tools don't cover well.
- CI baseline snapshotting. Run it in CI to record a signed inventory of what a build environment actually had installed, useful for after-the-fact forensics if a build is later found to have been compromised.
- Offboarding and contractor machine checks. Because it's a single static binary with no installation dependencies, it's cheap to hand to a contractor or a machine you don't fully control and ask them to run one scan and return the NDJSON output, without granting that machine any broader access to your security stack.
- Acquisition and third-party due diligence. Before absorbing a team's laptops or CI environment into your own fleet, a baseline scan gives you a concrete, catalog-matched inventory rather than relying on self-reported package lists.
Why the read-only constraint is the real feature
It's worth sitting with why "never execute anything" is treated as a first-class design principle rather than a footnote, because it's easy to read past it as boilerplate security hygiene. Most package inventory tools — including plenty of commercial SCA products — get their data by shelling out to the package manager itself: npm ls --json, pip list, go list -m all. That's the fastest, most accurate way to get a canonical dependency tree, and it's what most tooling does by default.
The problem is that this makes the inventory step itself an attack surface. A compromised package manager plugin, a malicious .npmrc registry override, or a postinstall hook that fires on any invocation of the package manager — including a read-style one in some edge cases — can turn a routine security sweep into the thing that triggers the payload. During an active incident, when you least trust the state of the machine you're scanning, that's exactly the wrong moment to be invoking the tooling you already suspect is compromised.
Bumblebee sidesteps this entirely by treating lockfiles and metadata directories as plain text and structured JSON to be parsed, never as inputs to a program to be run. It's a smaller, less convenient way to build a scanner — you lose some of the canonical accuracy a real package-manager invocation would give you, and the README acknowledges the corresponding confidence-scoring tradeoff — but it's the correct tradeoff for a tool whose whole reason for existing is "run this when you don't know what you can trust yet."
What the docs and hype quietly leave out
- It cannot find something it doesn't already know about. This is the headline limitation and it's stated plainly in the README's framing, even if the surrounding coverage glossed over it: Bumblebee is exposure-matching against a catalog of already confirmed compromises. A genuinely novel malicious package — the kind of thing a behavioral scanner like Socket or GuardDog is built to catch before anyone's written an advisory about it — will not show up in a Bumblebee scan. Zero-day supply-chain compromises are explicitly out of scope.
-
v0.1 doesn't parse everything. Non-JSON agent config formats — Codex's
config.toml, Continue's YAML configs — aren't parsed yet. If your team's tooling lives in those formats, Bumblebee's MCP/agent-skill coverage is currently partial, not complete. - It's a snapshot, not a control. There's no blocking, no CI gate that fails a build, no npm-install-time interception. Every other layer of your supply-chain defense still has to exist independently; Bumblebee slots in as an audit/response layer, not a prevention layer.
- Continuous coverage is BYO. The one-shot design means the operational burden of "run this regularly and alert on new findings" is entirely on you. That's a reasonable trade for a tool this narrow, but it's a real integration cost that a per-seat SaaS competitor would otherwise absorb.
- Catalog freshness is the whole ballgame, and it's unproven at scale. A young open-source threat-intel catalog maintained largely by one company's security team is a different trust proposition than a community-run vulnerability database like OSV.dev that's been aggregating advisories across the industry for years. Bumblebee's usefulness a year from now depends entirely on whether that catalog stays current and whether the community starts contributing to it.
How it stacks up
| Tool | Core method | Scope | Executes anything? | License / pricing |
|---|---|---|---|---|
| Bumblebee | Exact-match against known-compromise catalog | npm, PyPI, Go, RubyGems, Composer, MCP, extensions | No — read-only, zero deps | Apache 2.0, free |
| Socket | Behavioral/heuristic risk analysis at install time | npm, PyPI, GitHub | Analyzes package behavior; can gate installs | Free tier + paid |
| Snyk | CVE/vulnerability database matching + some behavioral | Broad multi-ecosystem, containers, IaC | No; SaaS-based scanning | Free tier + paid, enterprise-heavy |
| OSV-Scanner | CVE matching against OSV.dev | Broad, CVE-focused (not malicious-package-focused) | No | Apache 2.0, free |
| GuardDog | Heuristic detection of malicious package indicators | npm, PyPI | Static analysis of package contents | Apache 2.0, free |
The useful way to read this table isn't "which tool wins" — it's that Bumblebee occupies a gap the others don't cover well: post-advisory exposure inventory across a developer fleet, including the AI-agent-specific attack surface, with a trust model built for running during an active incident. It's not a substitute for Socket or GuardDog's detection capability; it's the tool you reach for after one of them (or an external advisory) tells you what to look for.
An independent read
The design restraint here is genuinely unusual for a security tool release, and it's the strongest argument in Bumblebee's favor. Most vendors, open source or not, want their scanner to look comprehensive — broad heuristics, risk scores, AI-flavored "threat detection." Perplexity's team instead shipped something that explicitly says "we do one narrow thing and we do it with a trust model you can actually audit," which is a rarer and, for this specific use case, more credible pitch.
The MCP and agent-skill scanning is the most forward-looking part of the project, and also the part I'd watch most closely. It's a tacit admission from a company that ships AI products that the AI agent supply chain — third-party MCP servers, agent skill packages, editor extension marketplaces — is already a real attack surface, not a hypothetical one. Most of the incumbent SCA tooling hasn't caught up to that yet, and it's a reasonable bet that this becomes a more contested category over the next year.
The open question is durability, not design. A single-vendor threat-intel catalog is the load-bearing part of the whole tool, and it's untested at the multi-year timescale that determines whether a project like this stays useful or quietly stales out the way a lot of single-company security tooling has before. Apache 2.0 licensing means the community could fork and maintain the catalog independently if Perplexity's attention moves elsewhere — but "could" isn't "will," and it's worth watching whether outside contributors actually show up in the threat_intel/ directory over the next few months.
Who should try it, and who should wait
Try it now if you run security response for a developer fleet and want a fast, low-friction way to answer "are we exposed" the next time an advisory drops — especially if your team is already using MCP servers or AI coding agent skills, since that's genuinely underserved territory elsewhere.
Wait if you need continuous, automated coverage out of the box — you'll be building the orchestration layer yourself right now — or if you need zero-day/behavioral detection, which is explicitly not what this tool does; pair it with something like Socket or GuardDog instead of expecting it to replace them.
Skip it if your stack is outside its current ecosystem coverage, or if a single-vendor, six-month-old threat-intel catalog isn't a trust level you're comfortable building an incident-response workflow around yet. That's a reasonable position today; it may not be in a year if the catalog and community around it mature.
What's your read on tools that deliberately ship a narrower feature set than they technically could — is "we only do exact-match against known incidents, nothing more" a stronger security promise than a broader heuristic scanner, or does the narrowness just push the real detection problem onto some other tool you now also have to run?
Sources:
Top comments (0)