Perplexity 发布开源工具 Bumblebee：开发者终端的只读供应链安全扫描器

Bumblebee 的核心设计理念是：绝不执行安装流程或脚本。

许多恶意开源包会把攻击代码藏在安装钩子（install hooks）或 post‑install 脚本中。如果安全工具在扫描时触发这些脚本，反而可能激活恶意行为。

Bumblebee 通过以下方式避免这种风险：

• 直接读取磁盘中的元数据，而不是调用 npm、pip 等工具
• 不执行安装脚本或生命周期脚本
• 将系统视为“组件清单来源”，只做盘点

它主要解析以下信息来源：

• 依赖锁文件（如 package‑lock.json、pnpm‑lock.yaml 等）
• 已安装包的元数据
• 插件清单（manifest）
• AI 工具配置文件

因此可以在不改变系统状态、不触发恶意代码的情况下完成风险识别。

Bumblebee 会扫描哪些组件

Bumblebee 的扫描重点是那些近年来频繁成为供应链攻击入口的开发工具组件。

1. 语言包生态（Package Ecosystems）

工具会读取多种语言生态中的依赖元数据，包括：

• npm、pnpm、Yarn、Bun
• PyPI
• Go modules
• RubyGems
• Composer

通过解析锁文件或包记录，Bumblebee 能判断某台机器安装了哪些依赖以及版本信息，而无需运行包管理器。

2. 编辑器扩展

代码编辑器插件通常可以访问源码、API Token 或开发者凭证，因此也成为攻击目标。

Bumblebee 会盘点系统中的编辑器扩展及其配置清单，以识别可能存在风险的插件。

3. 浏览器扩展

安全研究人员越来越把浏览器插件视为开发环境的一部分，因为它们可能读取代码仓库页面或访问凭证。

Bumblebee 同样会扫描本地浏览器扩展，寻找与安全公告相关的可疑插件。

4. AI Agent 与 MCP 配置

随着 AI 开发工具普及，新的攻击面也随之出现。

Bumblebee 可以扫描 AI 工具的配置文件，例如 Model Context Protocol（MCP） 相关 JSON 文件（如 mcp.json 等），这些配置可能连接到外部服务或工具，如果被篡改也可能带来供应链风险。

三种扫描模式：适配不同安全流程

为了适配不同安全场景，Bumblebee 提供三种扫描模式（scan profiles）：

Baseline
用于日常轻量扫描，主要检查开发者电脑常见的软件目录。企业可以通过设备管理或终端管理系统定期运行该扫描。

Project
针对特定开发目录或代码仓库的扫描，例如 ~/code 或项目工作区，用于检查当前项目依赖。

Deep
用于安全事件发生后的全面排查，会在更广泛的文件系统路径中查找可能存在的风险组件。

这种设计让团队能够根据需求，从日常监控到应急调查灵活切换。

基于“风险目录”的检测机制

Bumblebee 的检测依赖所谓的 exposure catalog（暴露目录）——即一份已知存在问题的软件包、版本或插件列表。

扫描完成后，工具会将发现的组件与该目录进行比对，从而识别风险。

每条检测结果都可以追溯，包括：

• 触发告警的目录条目
• 条目加入时间
• 与本地组件匹配的证据

这使安全团队能够快速回答一个关键问题：

“当前哪些开发者电脑受到这次供应链事件影响？”

为什么现在这种工具越来越重要

软件供应链攻击正在快速增加。

研究机构 Sonatype 报告称，目前已识别的恶意开源软件包总数超过 123 万个，其中 2025 年就新增超过 45.4 万个。

另一份安全报告指出，2025 年检测到的恶意开源包数量同比增长 73%。

与此同时，开发者电脑上的组件数量不断增加——不仅有包管理器依赖，还有编辑器插件、浏览器扩展以及 AI 工具集成。很多企业对这些本地环境的可见性仍然有限。

Bumblebee 的出现正是为了解决这个问题：为安全团队提供一种快速、被动且安全的开发者终端扫描方式。

总结

Perplexity 的 Bumblebee 为软件供应链安全提供了一种实用的新思路。

通过：

• 只读扫描机制（避免触发恶意代码）
• 覆盖现代开发环境的多种组件（依赖包、插件、AI 配置）
• 基于风险目录的检测方式

它让安全团队能够在供应链事件发生时迅速定位风险设备。

随着开源生态和 AI 开发工具持续扩张，像 Bumblebee 这样专门针对开发者终端环境可见性的工具，正在成为现代应用安全体系的重要组成部分。