Steve Poole：开源安全与 AI 带来的维护挑战

Olimpiu Pop 采访 HeroDevs 开发者布道师 Steve Poole，讨论开源供应链安全和 AI。Poole 提到其雇主为无人维护的开源包提供付费支持，这一商业背景与讨论相关。

Poole 说，软件团队高度依赖开源依赖及其维护者。攻击者可以通过入侵项目或开发者安装的工具与包来利用这种信任。他认为 AI 正在加快研究人员和攻击者发现漏洞的速度。

两人回顾了几种入口：执行未经检查的 shell 脚本、安装名称相似或拼写错误的恶意包，以及入侵已有项目。贡献者也可能先建立信任，再引入恶意修改。开发者机器往往持有凭据和访问权限，因此可能成为有价值的目标。

Pop 补充说，混淆性的版本号和自动拉取新版本的配置也可能增加供应链暴露面。需要关注的是从上游包到使用它的产品的整个链条，而不仅是应用自身的源代码。

两人讨论欧洲《网络韧性法案》、行业标准和网络保险对改善安全实践形成的压力。Poole 提醒自己不是律师。访谈中的解释是政策讨论，并非对法律义务及其适用范围的完整说明。

Pop 询问 AI 会让开源使用更安全，还是会引入新风险。Poole 说 AI 辅助工具可以大规模发现漏洞，并追问当防守方和攻击者都使用它们时会发生什么。他的核心担忧是发现问题的速度可能超过修复能力。

无人维护或已停止支持的依赖尤其棘手：发现问题后可能没有上游修复，Poole 也担心某些问题不会被广泛报告。即使是活跃维护者，也可能被大量报告压垮。这是他的风险判断，而非对所有项目的统计。

Poole 提出一种可能的商业回应：组织可能付费购买维护服务，以满足安全要求。他担心修复可能在付费服务与公共项目之间分化。他把这描述为可能结果，而非必然未来；他的雇主本身就在这个市场经营。

Pop 指出，发现并修复漏洞并不是供应链的终点。使用该依赖的组织仍需部署修复后的版本，而每个环节都可能延迟或失败。

企业能否 fork 一个依赖并自行修复？Poole 说这可以解决特定问题，但也会让企业承担未来维护和安全报告的责任。所需的工作量与专业知识容易被低估。

他的实践建议是检查每个依赖存在的原因，并减少不必要的依赖。他引用有限的研究，认为 AI 生成的应用可能比人写的替代方案包含更多依赖；他提到的数字并非普遍测量结果。生成代码仍需验证。

Poole 建议使用仍受维护的版本，并通过构建和部署流水线让升级成为常规操作。升级仍需测试，也可能引入兼容性风险。他将此作为安全实践提出，同时明确表示自己没有法律专业资格。

两人以 Kubernetes 的 AI 贡献政策为例，讨论如何让人类贡献者承担责任。Pop 说，即使 AI 参与生成代码，贡献者也必须理解并维护自己提交的代码。项目政策只适用于相应项目，也可能发生变化。

Poole 介绍一款 AI 安全工具在他处理过的代码中发现问题的经历。他预计工具会改进，但认为开发者仍对质量负责。输出的不确定性使测试和其他验证正确性的方法尤其重要。

最后，Poole 希望团队更务实地使用 AI：既看到好处，也认识到缺点，并理解使用时承担的责任。他说技术、经济和政策的相互作用，让最终结果难以预测。