When an advisory names a compromised package or editor extension, the immediate question is not abstract: is that exact package and version on this machine?
Perplexity’s Bumblebee scanner answers that question by reading package-manager metadata, lockfiles, extension manifests, and supported developer-tool configurations on macOS and Linux. It does not execute package managers or inspect source files. It emits the inventory, diagnostics, scan summary, and any exact matches against a supplied exposure catalog as NDJSON.
That is a sensible interface for automation. It is less convenient when I am sitting at one machine and want to understand what a scan actually saw. The information is present, but answering the next questions means reading the stream or writing a jq query: Which roots were scanned? Which packages were found? Did an input fail to parse? Which catalog produced this match? What changed since the previous run?
I built Bumblebee Desktop, a Flutter interface around the upstream scanner, to make those questions easier to answer without changing where the security logic lives.
Keep the scanner as the source of truth
The desktop app does not reimplement package discovery or exposure matching. A bundled Bumblebee helper performs the scan, and the app consumes its output. Package records, findings, diagnostics, files considered, duration, and completion state all come from that stream.
Keeping that boundary mattered to me. A second detection engine in the UI would create two implementations to compare, update, and distrust. The interface should help interpret a run, not quietly change its meaning.
It also preserves Bumblebee’s read-only model. The scanner reads supported metadata rather than invoking commands such as npm ls, pip show, or go list. The UI starts a scan and displays its records; it does not install, remove, or execute the packages it finds.
Show the scope before the result
Bumblebee has three profiles with different scope:
- Baseline checks common user and global package roots, toolchains, extensions, and supported developer-tool configurations.
- Project scans explicitly configured development directories.
- Deep scans explicit roots and is intended for a broader, on-demand check.
The dashboard exposes that choice and the resolved roots before the scan runs. This is more than a convenience. A result with no findings is only useful if I can tell what was included. The same screen then shows progress, package-record counts, findings, diagnostics, files considered, duration, and whether the scanner completed successfully.
Turn package records into an inventory
NDJSON is a good transport format, but it is not the view I want when tracing one package. The Inventory screen keeps the records emitted by Bumblebee and makes them searchable by package name, ecosystem, confidence, and root.
That supports a simple investigation: find a package, confirm its normalized version, and see the path from which the record came. The UI does not infer that a package is dangerous merely because it exists. A finding still requires an exact match from a loaded exposure catalog.
Make catalog provenance visible
Exposure results are only as current and relevant as the catalogs used for the run. Bumblebee Desktop bundles catalog JSON files from the upstream project and can sync the current files from Perplexity’s threat_intel directory.
The Threat Intel screen shows those files and their source instead of treating the rules as an invisible part of the application. That makes it possible to check which catalog was available before interpreting a finding.
Add the state a one-shot scanner does not keep
Upstream Bumblebee performs one scan and exits. Scheduling and state management belong to whatever runs it. For a desktop workflow, I wanted the completed runs to remain available locally, so the app adds a History screen.
Each saved run is a point-in-time result that I can reopen and compare with what the scanner reports later. This is useful context, but it is not continuous monitoring: the history is only as complete as the scans I chose to run and retain.
What this interface does not prove
Bumblebee is deliberately narrow. It reports supported on-disk metadata and exact exposure-catalog matches. An empty findings list does not prove that an endpoint is uncompromised, that every ecosystem was covered, or that a package never executed. The UI cannot widen that evidence; it can only make the scan scope, diagnostics, and result easier to inspect.
That boundary is why the desktop app complements the CLI instead of replacing it. Automation can continue consuming NDJSON, while a person investigating one endpoint gets a view suited to questions rather than transport.
The source, build notes, and releases are in the Bumblebee Desktop repository .
