如何将 LLM API 接入开源漏洞扫描以缩短安全审查时间

开源软件虽然便利，但也伴随着风险。根据 2025 年的一项调查，随着 AI 开始辅助编写代码，漏洞发生率较前一年飙升了 41%。对于需要独自审查数万行外部库代码的安全负责人来说，这简直是一场灾难。既然无法读完所有的代码，就必须让 AI 成为我们的盟友。本文总结了如何像 Project Glasswing 那样，亲手打造一套智能运行的安全工作流。

在 GitHub Actions 中安装 AI 安全引擎

通过自动化安全审查，可以省去每周投入 10 个多小时的单纯重复性工作，并防止由于人工扫视而遗漏的错误。请尝试构建一个在 GitHub Actions 环境中调用 LLM API 的流水线，每当有 Pull Request 提交时进行实时扫描。核心策略并非简单地提问，而是将“识别”与“审计”分离。

• 保护 API 密钥：请在 GitHub Secrets 中注册 LLM_API_KEY。必须存放在 Libsodium 加密存储库中，以防止密钥泄露事故。
• 设置目标目录：没必要查看所有文件。在 YAML 配置中使用 path-filter，挑选出像 src/auth 或 lib/core 这种一旦出事就后果严重的敏感目录进行扫描。
• 交叉验证：第一阶段让 LLM 分析代码结构并编写笔记，第二阶段根据该笔记进行 3 次以上的重复扫描。由于 AI 有时也会胡言乱语，因此需要多次确认并比对结果的过程。

只要完成这些设置，安全负责人就无需面对数万行代码，只需确认 AI 汇总的安全报告即可。

利用 CVSS 和 EPSS 筛选出真正的危险分子

AI 工具虽然擅长发现漏洞，但误报也很多。如果发现了 100 个漏洞，其中有 15 个是假的，开发团队难免会感到厌烦。为了不浪费有限的开发资源，需要一套筛选真实威胁的标准。请结合 CVSS 4.0 评分和显示当前是否正在发生实际攻击的 EPSS 指标来确定优先级。

1. 确认基础分数：首先通过 CVSS 4.0 基础分数查看技术严重程度。
2. 调整环境分数：根据该代码是暴露在外部互联网的功能，还是仅在内网运行的功能，来降低或增加分数。
3. 对比攻击概率：查询 EPSS 数据库，确认该漏洞目前是否在攻击者中流行。如果攻击概率超过 50%，则应放下其他所有工作，立即进行修复。

即便只关注 9.0 分以上的紧急等级，安全水平也会大幅提升。减少不必要的修改请求，自然也会减少与开发团队的摩擦。

在沙盒中验证并部署修复代码

AI 建议的修复方案看似完美，有时却会破坏原有的正常功能。像 Shopify 这样的公司虽然也使用 AI，但并不会盲目信任生成的代码。必须建立一套程序，在 Firecracker 或 gVisor 等隔离环境中自动确认修复代码是否安全。

• 创建隔离环境：使用 sbx CLI 启动一个与当前服务具有相同运行时环境的 MicroVM。
• 模拟攻击：通过攻击脚本确认漏洞是否真的会被攻破，然后应用 AI 提供的修复补丁，再次攻击以检查是否被成功拦截。
• 功能测试：在应用补丁的状态下运行现有的单元测试。如果安全问题解决了但无法登录，那就毫无意义。

有了这些安全装置，才能防止 AI 制造的“看似正确但有细微错误”的代码进入生产服务器。

编写开源维护者愿意接纳的报告

不能只修复我们自己的服务就结束了。将所使用的开源项目本身的缺陷报告给上游项目，也是安全负责人的职责。维护者都很忙，因此必须提供明确的依据。请利用 GitHub 的 PVR 渠道，负责任地传递报告。

标题中应明确注明漏洞类型和位置。附带任何人都能遵循的复现路径和截图是基本要求。最有效的方法是连同之前在沙盒中验证过的修复代码一并发送。缩短他们的审查时间，补丁被采纳的概率就会大幅提高。一份专业的报告不仅能证明企业的技术实力，还能促成官方 CVE 编号的获取。