Daniel Kim

Posted on Aug 15

Perplexity Open-Sourced a Supply-Chain Scanner That Never Touches npm, pip, or Your Shell

#security #devops #github #opensource

In the space of about four months in early 2026, three separate npm and PyPI supply-chain worms tore through the JavaScript and Python ecosystems, and each time the same operational question landed on security teams' desks with no good answer: "An advisory just named a compromised package version — which of our developers' laptops actually have it installed right now?"

Not "which repos declare it in package.json." Not "which CI pipeline pulled it." Which physical machines, with all their globally-installed CLIs, editor extensions, and half-forgotten side projects, are carrying the exact poisoned artifact.

Perplexity, the AI search company, open-sourced a tool built to answer exactly that question. It's called Bumblebee, and it's a strange, deliberately narrow piece of software — a supply-chain scanner that refuses to run a single package-manager command, execute a line of the code it's inspecting, or even touch the network. It just reads files and reports what it finds. That constraint is the entire point, and it's worth understanding why.

What happened

Bumblebee shipped on GitHub on May 22, 2026, under the Apache 2.0 license, written in Go with zero non-standard-library dependencies. It crossed 1,450 stars and 112 forks in its first week — a fast climb for a security utility with no UI and no SaaS layer behind it — and as of this writing sits above 4,900 stars and 437 forks.

The timing wasn't accidental. The release came directly on the heels of a cluster of npm/PyPI compromises that security researchers grouped under the "Shai-Hulud" and "Mini Shai-Hulud" names. Mini Shai-Hulud hit 324 packages in the antv namespace across 643 malicious versions on May 19. A week earlier, on May 11, attackers shipped malicious TanStack releases that carried valid SLSA Build Level 3 provenance attestations — meaning the supply-chain attestation system designed to prove a package wasn't tampered with didn't catch it. The same campaign family touched packages associated with SAP and Zapier, and crossed into the Python ecosystem on April 30 through poisoned releases of the lightning package on PyPI (versions 2.6.2 and 2.6.3).

Bumblebee is Perplexity's internal-tool-turned-public-release for handling exactly this pattern: an advisory drops, and someone needs a fast, trustworthy way to sweep a fleet of developer machines for the compromised artifact — without running anything that could itself become an attack vector during the sweep.

What it actually does

Bumblebee is a read-only inventory scanner for developer endpoints — currently macOS and Linux. You run it, it walks the filesystem for package-manager metadata and lockfiles, and it emits a structured record for every package, extension, and tool it finds. Point it at an "exposure catalog" (a JSON file listing known-compromised package name/version pairs) and it also emits finding records — exact matches between what's on disk and what's known to be bad.

It's not an antivirus, not an EDR agent, and not a registry-side scanner like the ones GitHub or npm run on packages before you ever download them. It answers one narrower, more mechanical question: given a known IOC (indicator of compromise), is it physically present on this machine, right now, and where?

The ecosystem coverage is broad for something this small:

JavaScript/TypeScript: npm, pnpm, Yarn, and Bun, read from package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, and bun.lock
Python: PyPI packages via dist-info/METADATA, egg-info/PKG-INFO, and direct_url.json
Go: go.sum and go.mod
Ruby: Gemfile.lock and installed .gemspec files
PHP: composer.lock and vendor/composer/installed.json
MCP servers: JSON-based host configs like mcp.json and claude_desktop_config.json
Agent skills: skills-lock.json files
Editor extensions: VS Code, Cursor, Windsurf, and VSCodium manifests
Browser extensions: Chromium and Firefox per-profile configuration
Homebrew: INSTALL_RECEIPT.json and cask metadata

The inclusion of MCP configs and editor/browser extensions alongside traditional package managers is the tell for who this tool is actually built for: teams that have watched the attack surface of a developer's machine expand well past node_modules in the last two years, into IDE plugins and agent tool configs that get installed with a single click and rarely get audited.

How it works

The mechanism is almost aggressively simple, and that's deliberate.

Single static binary, one-shot execution. Bumblebee is Go 1.25+, compiles to one binary with no runtime dependencies, and does one scan per invocation before exiting. It has no daemon mode and no built-in scheduler — you wire it into cron, launchd, or systemd yourself if you want recurring sweeps. That's a conscious scope cut: the project isn't trying to be a monitoring platform, just a reliable primitive you can build one around.

Three scan profiles, escalating in invasiveness:

Profile	Scope	Use case
`baseline`	Global package roots, language toolchains, editor/browser extensions, MCP configs	Lightweight recurring inventory
`project`	Configured dev directories (`~/code`, `~/Developer`)	Daily sweeps of known workspaces
`deep`	Explicit operator-supplied roots, including bare `$HOME`	Active incident response

Baseline and project profiles explicitly refuse to scan a bare home directory — only deep mode allows that, and it's clearly framed as the "we have an active incident, sweep everything" setting. That's a small but meaningful design choice: it makes the invasive mode opt-in and hard to trigger by accident.

It never executes anything it's inspecting. This is the core security property, and it's what separates Bumblebee from the obvious alternative of just running npm ls -g, pip show, or a package manager's own audit command. Those all shell out to the tool being audited, and postinstall/preinstall scripts are precisely how most of these worms achieve initial execution in the first place. Bumblebee reads lockfiles and metadata files directly as static text/JSON — it never invokes npm, pip, bun, or any package manager binary, and never triggers a postinstall hook. If you're scanning a machine you suspect might already be compromised, that matters: you don't want your scanner to be the thing that re-triggers the payload.

Matching is exact, not heuristic. The exposure catalog is just a JSON list of ecosystem + package name + version. Entries support wildcard versions (["*"]) to flag every release of a fully sabotaged package. When Bumblebee finds a local package matching a catalog entry, it emits a finding record with severity, the advisory/catalog ID, the exact evidence (e.g., version=1.2.3), the source file it came from, and a confidence level.

Output is NDJSON, one JSON object per line — package records, finding records, and a closing scan_summary record for receiver-side state tracking. This is a format built to be piped into something else (a SIEM, a spreadsheet, a Slack alert script), not read by a human directly. Installation is a single go install command, and there's a bumblebee selftest subcommand to sanity-check the install before you point it at production laptops.

A minimal exposure catalog entry looks roughly like this — an ecosystem, a name, one or more affected versions, and the metadata that ends up copied onto any resulting finding:

{
  "id": "GHSA-example-1234",
  "advisory": "mini-shai-hulud-2026-05",
  "ecosystem": "npm",
  "package": "some-compromised-package",
  "versions": ["4.2.1", "4.2.2"],
  "severity": "critical"
}

Feed that file to bumblebee scan --profile deep --root ~ --exposure-catalog ./catalog.json, and every match on disk becomes a finding record with the source lockfile and confidence level attached — enough to go straight into a ticket without additional lookup.

The workflow this is built around is narrow by design: someone (a security team, a threat-intel vendor, a community PR to threat_intel/) has to already know the bad package/version pair before Bumblebee can find it anywhere. It's a confirmation instrument, not a discovery engine — closer to a metal detector sweeping for a specific known object than a general anomaly scanner.

What changed versus the tools already doing "supply-chain security"

The supply-chain security category is crowded, but almost everything in it operates at a different layer than Bumblebee.

Tools like Socket and Snyk work primarily at the registry and CI/CD layer — they score packages before install, scan declared dependencies in package.json/requirements.txt, and gate pull requests. SBOM generators like Syft or the CycloneDX tooling produce a manifest of what you intentionally shipped in a build artifact or container image. EDR platforms watch runtime behavior continuously, looking for processes doing something malicious right now.

None of those answer "what's actually sitting on Alice's laptop, installed globally eighteen months ago, that nobody has thought about since." That's the gap: the scattered, undeclared, un-manifested state that accumulates on a real developer machine — global npm installs, an old VS Code extension, a Homebrew cask, an MCP server config someone pasted from a blog post. SBOMs don't cover it because it was never part of a formal build. CI scanners don't cover it because it never went through CI. EDR generally isn't tuned to reason about package-manager metadata at all.

Bumblebee's actual innovation isn't the scanning logic — reading lockfiles is not novel. It's the scope decision: treat the developer endpoint itself, including the parts nobody manifests, as the unit of exposure, and build a tool narrow enough that a security team can trust running it during an active incident without introducing new risk.

It's also worth distinguishing Bumblebee from automated-remediation tools like Dependabot or Renovate. Those operate on the same declared-manifest layer as Snyk — they open PRs to bump versions in a repository — and they're forward-looking (keep dependencies current) rather than backward-looking (find out what already landed on a machine before anyone declared it anywhere). A repo's Dependabot config tells you nothing about the CLI a developer installed globally two years ago, or the VS Code extension that's been sitting untouched since a hackathon. Bumblebee is explicitly aimed at that undeclared residue.

The MCP and editor-extension coverage also puts Bumblebee ahead of a trend rather than reacting to one that's already fully materialized. Malicious or trojanized editor extensions and rogue MCP servers are a smaller incident category today than compromised npm packages, but the mechanism is structurally identical — a single install grants a tool broad filesystem and credential access, and most developers install extensions and MCP servers with even less scrutiny than they apply to npm install. Building the inventory capability for that surface now, before it's the site of a headline-grade incident, is a deliberate bet on where the next wave of this problem shows up.

Why developers (and the security teams around them) should care

Cost: Free and self-hosted. No SaaS tier, no per-seat pricing, no telemetry phoning home — you own the binary and the output. For orgs already paying for Socket or Snyk, this isn't a replacement for either; it's a cheap addition that closes a blind spot those tools structurally can't reach.

Latency: A one-shot static binary with no dependencies starts and finishes fast. For an incident-response scenario — "we need exposure data from 400 laptops in the next hour" — that responsiveness matters more than a feature-rich dashboard would.

DX: go install and you're scanning. No agent to deploy, no account to create, no config beyond an optional catalog file. The tradeoff is that you get raw NDJSON, not a dashboard — more on that below.

Security: The read-only, never-execute design is the headline feature, and it's a genuinely well-reasoned one for this specific use case. A scanner that shells out to the tool it's auditing is a scanner that can be weaponized by the exact compromise it's trying to detect.

Lock-in: None. Apache 2.0, one binary, plain-text JSON catalog format, NDJSON output that any pipeline can consume. If Perplexity stopped maintaining it tomorrow, nothing about your workflow breaks — you'd just be maintaining your own fork of the catalog.

Practical use cases

Incident response after a named advisory. A CVE or GHSA drops naming a specific compromised package/version. Security pushes a deep scan with a one-entry exposure catalog to the fleet (via existing MDM/config-management tooling) and gets a yes/no per machine within minutes, without needing developers to manually check.
Recurring low-noise inventory. A baseline scan on a weekly cron, piped into a central log store, builds a rolling picture of what's actually installed across an engineering org — useful for offboarding audits and general hygiene, independent of any active incident.
MCP and agent-tool exposure specifically. As AI coding agents and MCP servers become normal developer tooling, the config files describing which MCP servers a machine trusts are themselves an attack surface (a malicious MCP server is a live path to code execution or credential theft). Bumblebee inventorying these alongside traditional packages is a genuinely forward-looking inclusion most competing tools don't have yet.
Post-mortem scoping. After a breach is confirmed, running Bumblebee against backups or forensic images (read-only, no side effects) to establish exactly which machines had the compromised artifact and for how long.

What the docs (reasonably) don't dwell on

A few limitations are worth being explicit about, since a security tool's gaps matter as much as its features:

It's macOS and Linux only. The README frames it plainly as covering those two platforms. For organizations with a meaningful Windows developer fleet, that's a real gap, not a footnote — and it's the kind of detail that's easy to miss if you only read the announcement rather than the actual scan-target list.
The exposure catalog is not a live feed. Bumblebee ships with a threat_intel/ directory of catalogs maintained via community PRs, but it is not a continuously updated threat intelligence subscription. You are responsible for keeping the catalog current, or wiring it to a source that is. Out of the box, it detects nothing until someone tells it what to look for.
The catalog dependency is a real bottleneck, not a footnote. Exact-match detection means Bumblebee is only as current as whoever is updating your catalog — there's no built-in feed, so a team that adopts the scanner but not a disciplined catalog-update habit gets a false sense of coverage.
No fleet-wide aggregation or dashboard is included. NDJSON output is exactly what it sounds like — lines of JSON. Turning that into an actual fleet-wide view (which machines, what severity, trending over time) is left entirely to whoever deploys it. That's consistent with the "small sharp tool" philosophy, but it does mean the real deployment cost isn't the scanner — it's the pipeline you build around it.
v0.1 gaps are already documented but easy to skim past: non-JSON MCP configs (Codex's TOML format, Continue's YAML) aren't parsed yet, and "loose" agent-skill directories without a lock file aren't enumerated. It's young software, and the ecosystem coverage table looks more complete on first read than the current version actually delivers.
Read-only means read-only — Bumblebee will tell you a machine is exposed, but it does nothing about it. Uninstalling the package, rotating credentials that may have been exfiltrated, and confirming remediation are all separate, manual steps.

How it stacks up

Tool	Operates at	Execution model	Question it answers	Output
Bumblebee	Developer endpoint	Read-only, never executes scanned tooling	"Is this exact compromised package version on this machine right now?"	NDJSON
Socket	Registry / CI, pre-install	Analyzes packages before/at install, GitHub App checks	"Is this package suspicious before I add it?"	Dashboard, PR checks
Snyk	SCA / CI-CD	Scans declared dependency manifests, integrates with build	"What known CVEs exist in my declared dependencies?"	Dashboard, PR checks
Syft / CycloneDX	Build-time	Static analysis of build/image artifacts	"What's the complete inventory of what I shipped?"	SBOM file
EDR (e.g. enterprise endpoint agents)	Runtime, continuous	Persistent agent monitoring live process behavior	"What's executing right now that looks malicious?"	Alerts, telemetry

These aren't really competitors so much as adjacent layers of the same problem. A mature security posture plausibly wants several rows of this table simultaneously — Bumblebee fills a specific one that was previously handled, if at all, with ad hoc shell scripts during an incident.

An independent read

The most interesting thing about Bumblebee isn't the code — reading lockfiles and diffing against a catalog is not hard engineering. It's that a company built primarily around a consumer/enterprise AI product decided this was worth open-sourcing at all, and specifically chose the narrowest, least flashy possible scope for it: no dashboard, no cloud service, no AI-powered anomaly detection despite being an AI company. In a year where "AI security scanner" usually means a model looking at code and guessing, Bumblebee is refreshingly boring — deterministic string matching against a catalog, shipped as a static binary that does one thing and refuses to do more.

That restraint is also its limit. Because it only flags exact known-bad versions, its value is entirely downstream of catalog quality, and Perplexity has not (yet) positioned this as a managed feed — it's asking the community to help maintain threat_intel/ via PRs, which is a reasonable open-source pattern but a meaningfully weaker guarantee than a commercial threat-intel subscription. Teams adopting Bumblebee should go in understanding they're adopting a primitive, not a finished security program.

The choice to include MCP configs and agent-skill lockfiles from day one is the most forward-looking part of the release. Most existing supply-chain tooling was designed for a world of package.json and requirements.txt; Bumblebee was clearly designed with awareness that the next wave of supply-chain compromise is going to run through AI agent tooling, not just traditional package registries. Whether that bet pays off depends on how fast malicious MCP servers actually become a real incident category — but building the inventory capability now, before it's urgent, is the right sequencing.

Who should try this, and who should wait

Try it now if you run a security team responsible for developer endpoint exposure and currently have no good answer to "which machines have package X version Y" beyond asking people to check manually. The setup cost is close to zero, the risk of running it is close to zero (read-only, no execution), and it plugs a real gap next to whatever CI-layer scanner you already run.

Worth adopting deliberately, not reflexively if your org is majority Windows on the developer side — you'd be running it against a minority of your fleet, which caps its value until Windows support (if it comes) lands.

Wait if you were hoping for a turnkey supply-chain security platform with a dashboard and a maintained threat feed. Bumblebee is a component, not a product; you'll be building the aggregation and alerting layer yourself, and the catalog is on you to maintain or source.

Ignore if your primary supply-chain risk model is about what ships in production artifacts rather than what accumulates on developer laptops — that's SBOM and CI-scanner territory, and Bumblebee isn't trying to compete there.

Discussion question: Bumblebee's core bet is that a read-only, exact-match, catalog-driven scanner is more trustworthy during an active incident than anything with heuristics or execution — even at the cost of missing novel compromises entirely. Is that the right tradeoff for endpoint-level supply-chain tooling specifically, or does the lack of any anomaly-detection capability mean it'll only ever catch what a human has already caught first?

Sources:

DEV Community