Bumblebee: The Scanner Built for the Developer Laptop Security Problem

The security question Bumblebee answers

Security teams have long had two partial answers. SBOMs tell you what was shipped. EDR tells you what is running. Bumblebee asks a different question: what is already sitting on developer machines, right now, in the folders people actually use? That matters because supply-chain exposure does not stay neatly inside a build pipeline. It lands on laptops, in extensions, caches, lockfiles, and now local AI tool configs.

That is the real thesis behind perplexityai/bumblebee. It is a read-only inventory scanner for macOS and Linux developer endpoints, built to map on-disk package, extension, and developer-tool metadata to known compromise catalogs. In other words, it looks for the parts of the machine that security tooling usually waves past because they are too messy to model cleanly.

Why the project feels different

Bumblebee is not trying to be a generic crawler. It uses profiles like baseline, project, and deep to decide how far to look, which keeps the tool usable on real machines instead of turning it into a background tax. The baseline profile even avoids the trap of walking all of $HOME blindly. It targets specific paths that are more likely to matter.

That scoping decision is not just a UX choice. It is an architecture choice. The scanner is zero-dependency Go, uses concurrent workers, and normalizes findings into a shared record model with host metadata, OS details, run IDs, and source paths. That means the output is structured for fleets, not for one-off forensics.

How Bumblebee scans without becoming invasive

The scanning loop lives in scanner.Run. It fans work out across a small worker pool, parses files through ecosystem-specific handlers, and emits a normalized record for each finding. The important part is what it refuses to do. It does not shell out to package managers. It does not mutate the machine. It treats expected access errors, including macOS permission noise, as part of normal life on a developer laptop.

That restraint extends to output. Findings can go to stdout, a file, or an HTTP sink. The HTTP path is especially careful: secrets are read from environment variables, and the sink supports token or HMAC-style signing so credentials do not have to hang around in process lists. Bumblebee is not just careful about what it reads. It is careful about how it leaves the machine.

// Simplified shape of the scanner's contract.
results, err := scanner.Run(ctx, scanner.Config{
    Profile: "baseline",
    Workers:  4,
    Output:   output.NewHTTPSink(url),
})
if err != nil {
    log.Fatal(err)
}

for _, r := range results {
    // Each record carries base metadata plus ecosystem-specific fields.
    fmt.Println(r.SourcePath, r.DuplicateCount)
}

MCP is the tell

The sharpest part of Bumblebee is not classic package detection. It is the fact that it treats MCP configs as inventory objects. That widens the attack surface from installed software to the local AI tooling that can read files, hold credentials, and reach into developer workflows. If a malicious or compromised config can shape what an agent sees, then the config itself belongs in the security model.

That is why Bumblebee feels ahead of the usual endpoint narrative. It is not only asking which packages are present. It is asking which local tools, extensions, and AI connectors have access to sensitive context. For teams trying to understand supply-chain exposure on modern developer laptops, that is the more interesting question.

Self-test as product philosophy

The embedded selftest flow makes the project feel built for deployment, not for demos. Bumblebee ships fixture data in the binary, extracts it to a temporary directory, and scans it without needing external network access or live malware samples. That is a small thing with a big implication: the tool is designed to prove itself in constrained environments.

What Bumblebee is not

Why this matters now

The strategic shift here is simple. Security is moving from “what did we ship?” to “what is actually resident on developer machines, and what can local tooling see?” Bumblebee is a sign that the endpoint is no longer just an endpoint. It is a living supply-chain surface, and local AI tooling makes that surface wider.