Written with AI assistance from the source video. The video is the authority.
5:49Anthropic
Log in to leave a comment
No posts yet
开源软件虽然便利，但也伴随着风险。根据 2025 年的一项调查，随着 AI 开始辅助编写代码，漏洞发生率较前一年飙升了 41%。对于需要独自审查数万行外部库代码的安全负责人来说，这简直是一场灾难。既然无法读完所有的代码，就必须让 AI 成为我们的盟友。本文总结了如何像 Project Glasswing 那样，亲手打造一套智能运行的安全工作流。
通过自动化安全审查，可以省去每周投入 10 个多小时的单纯重复性工作，并防止由于人工扫视而遗漏的错误。请尝试构建一个在 GitHub Actions 环境中调用 LLM API 的流水线，每当有 Pull Request 提交时进行实时扫描。核心策略并非简单地提问，而是将“识别”与“审计”分离。
LLM_API_KEY。必须存放在 Libsodium 加密存储库中，以防止密钥泄露事故。path-filter，挑选出像 src/auth 或 lib/core 这种一旦出事就后果严重的敏感目录进行扫描。只要完成这些设置，安全负责人就无需面对数万行代码，只需确认 AI 汇总的安全报告即可。
AI 工具虽然擅长发现漏洞，但误报也很多。如果发现了 100 个漏洞，其中有 15 个是假的，开发团队难免会感到厌烦。为了不浪费有限的开发资源，需要一套筛选真实威胁的标准。请结合 CVSS 4.0 评分和显示当前是否正在发生实际攻击的 EPSS 指标来确定优先级。
即便只关注 9.0 分以上的紧急等级，安全水平也会大幅提升。减少不必要的修改请求，自然也会减少与开发团队的摩擦。
AI 建议的修复方案看似完美，有时却会破坏原有的正常功能。像 Shopify 这样的公司虽然也使用 AI，但并不会盲目信任生成的代码。必须建立一套程序，在 Firecracker 或 gVisor 等隔离环境中自动确认修复代码是否安全。
sbx CLI 启动一个与当前服务具有相同运行时环境的 MicroVM。有了这些安全装置，才能防止 AI 制造的“看似正确但有细微错误”的代码进入生产服务器。
不能只修复我们自己的服务就结束了。将所使用的开源项目本身的缺陷报告给上游项目，也是安全负责人的职责。维护者都很忙，因此必须提供明确的依据。请利用 GitHub 的 PVR 渠道，负责任地传递报告。
标题中应明确注明漏洞类型和位置。附带任何人都能遵循的复现路径和截图是基本要求。最有效的方法是连同之前在沙盒中验证过的修复代码一并发送。缩短他们的审查时间，补丁被采纳的概率就会大幅提高。一份专业的报告不仅能证明企业的技术实力，还能促成官方 CVE 编号的获取。