在开源漏洞爆发之前
就发现它。
Open Source Component Analysis & Response
OSCAR 在每次构建时采集 SBOM（软件物料清单），并持续检查您服务中的开源组件是否存在已知漏洞。界面使用您的语言，您还可以用自然语言向 AI 提问——“哪些项目存在 Critical 漏洞？”——直接得到答案。
风险最高的项目 按严重程度统计漏洞组件
新增漏洞 最近 12 周
- loan-batchCVE-2021-44228 · log4j-core 2.14.1Critical
- payment-apiCVE-2022-22965 · spring-beans 5.3.17Critical
仪表盘一屏掌握所有项目的风险
AI 查询直接提问，无需学习菜单
您现在能说清自己的服务里都有什么吗？
当 Log4Shell 这类开源漏洞爆发时，第一个问题总是“我们用到它了吗？”在各团队手工翻查依赖库清单的时候，时间站在攻击者一边。OSCAR 会提前为您准备好这个答案。
| 方面 | 过去 | 使用 OSCAR |
|---|---|---|
| 频率 | 每年人工审查一次——期间新出现的漏洞无人察觉 | 每次构建都上传 SBOM，新漏洞发布时自动重新检查 |
| 方式 | 靠人工逐一核对依赖库清单——容易遗漏 | 由机器将组件清单与漏洞数据库比对（名称、版本、哈希） |
| 响应时间 | 光确认“我们用没用”就要好几天 | 从一个 CVE 出发，立即找出所有受影响的项目 |
| 界面 | 只有英文的工具，业务团队难以阅读 | 本地化界面；许可证全文附译文，与原文并列显示 |
| 查询 | 要学会菜单和筛选条件才能得到所需表格 | 用自然语言向 AI 提问——47 个工具负责查找 |
一览
发现漏洞只是开始：OSCAR 让结果易于阅读，记录谁上传了什么，并追溯组件是如何被引入的。以下界面使用虚构数据。
└ spring-boot-starter-log4j2
└ log4j-core 2.14.1
主要功能
OSCAR 原样使用久经验证的开源分析引擎 (OWASP Dependency-Track)，并在其周围补充团队所需的能力。
自动生成 SBOM——支持三种构建方式
Maven 用 pom 插件，npm 用上传脚本，没有 pom.xml 的 Ant 或手工构建项目用 ssemsbom CLI——构建一结束，SBOM 即自动上传。
持续检测
同时使用 NVD、GitHub Advisory、OSV、Sonatype OSS Index 和 Trivy。新漏洞发布时，会对已有的组件清单重新检查。
自然语言 AI (MCP)
通过 MCP 提供覆盖项目、漏洞、组件、策略、许可证和 SBOM 的 47 个工具。可在 Claude 等 AI 客户端或内部 LLM 中提问。
本地化界面 · 许可证翻译
开箱即提供韩文界面，许可证全文由 LLM 翻译并与原文并列显示。可选用内部 LLM (Ollama、LM Studio) 或 Gemini。
上传历史 · 标准标签
记录每份 SBOM 由谁、在何时、为哪个项目上传。团队、服务类型、技术、构建工具、应用服务器等标准标签可对数百个项目进行分组。
识别杂乱的遗留 JAR
通过文件名、pom.properties、MANIFEST、group 推断、Vendor-Id 以及（可选的）Maven Central 哈希查询六个步骤还原名称和版本。不确定时绝不猜测。
团队如何使用
开发人员无需学习新工具：构建中多加一步，结果在界面上查看或直接问 AI。
部署到您的服务器
分析引擎和数据库运行在 Docker 中；网关和界面运行在 Tomcat 11 上。一切都留在您的内网中。
加入 SBOM 步骤
在 pom 中加一个插件，npm 用一个脚本，Ant 构建中加一行 ssemsbom。此后每次构建都会自动上传。
接收漏洞数据
定期拉取漏洞数据库。在隔离内网中，只需通过网络桥接开放流入方向。
查看 · 提问 · 修复
在仪表盘上关注风险，向 AI 询问影响范围，并记录分析状态（分诊中、不受影响）。
工作原理
所有路径都经过同一个 OSCAR 网关。界面、构建和 AI 从不直接调用分析引擎，因此网关可以附加翻译和历史记录——而引擎可以原样升级。
- 分析引擎不做任何修改。OSCAR 运行官方发布的 OWASP Dependency-Track，并在其前方的网关中改写响应。升级引擎不会影响 OSCAR。
- 翻译在网关中完成，而不是在界面中，因此界面、AI 和 API 客户端收到的都是同一份译文。
- MCP 服务器运行在每位用户的 PC 上，由 AI 客户端启动，并使用签发的 API 密钥进入网关。AI 只能执行该密钥允许的操作。
- 虚线表示只进不出。漏洞数据流入引擎；您的组件清单绝不会离开您的网络。
Dependency-Track 4.13
OWASP 开源 · Docker。负责 SBOM 分析以及漏洞、策略和许可证评估。
Java 21 · Tomcat 11
请求转发、许可证翻译和上传历史，与本地化界面一同提供。
MCP 服务器 · 47 个工具
单个 Java jar，通过 STDIO 通信。支持 Claude Desktop、Claude Code 及其他 MCP 客户端。
CycloneDX 1.5 · PURL
国际 SBOM 标准 (ECMA-424)。组件以 PURL 标识，并与漏洞数据进行匹配。
安全原则
安全工具本身不能成为新的风险，因此我们首先划定了以下界线。
- 部署在您的服务器上——组件清单和分析结果不会交给外部云。
- 上传的是组件清单 (SBOM)，而非源代码——只有名称、版本和哈希。
- 唯一的外部连接是拉取漏洞数据，便于在隔离内网中通过审批。
- 若使用内部 LLM (Ollama、LM Studio) 进行许可证翻译，连待翻译的文本也不会出内网。
- AI 只负责调用工具，不自行判断——答案始终以引擎的数据为依据。
- AI 访问使用专用 API 密钥，无法超出该密钥的权限（读取、上传……）。
- 翻译失败时仍会显示原文——不会因为翻译而丢失任何内容。
- 引擎是久经验证的开源软件，原样使用；OSCAR 只在其前方加了一层薄薄的网关。
运行要求
运行 OSCAR 所需的条件。
- 服务器上需要 Docker（分析引擎、PostgreSQL）和 Tomcat 11 (Java 21)。分析引擎需要充足的内存（数 GB 以上）。
- 需要一条从互联网流入的通道以接收漏洞数据。在隔离内网中，只需通过网络桥接放行必要的地址。
- SBOM 由构建生成，因此需要能够在流水线（Maven、npm、Ant、手工构建）中加入 SBOM 步骤。
- 缺少元数据的商业或内部 JAR 无法识别，可能被排除在漏洞匹配之外。
- AI 查询需要支持 MCP 的客户端；内部 LLM 必须支持工具调用 (tool calling)。
- 许可证译文仅供参考，法律判断以原文为准。