Google 专家探索开源安全挑战和修复

一个开源安全事件带来了关于供应链安全和开源项目管理缺陷的讨论。

随着越来越多的组织在其软件中依赖开源组件，保护这些组件的问题变得越来越紧迫。

这是谷歌今天举办的一场活动的前提，在此期间，开源专家讨论了保护开源软件的无数挑战、公司应该优先考虑的事项以及行业可以采取的措施来改善开源安全的整体状态。

Synopsys 的数据显示，平均软件应用程序依赖于至少 500 个开源库和组件，比两年内的 298 个依赖项增加了77%。开源库和组件占平均软件应用程序代码的 75% 以上，84% 的应用程序至少有一个漏洞，典型应用程序有 158 个。

在一次关于开源供应链安全的演讲中 ，谷歌软件工程师 Dan Lorenc 建议组织了解他们在使用什么——他承认这一步看似显而易见但并不容易，尤其是当开发人员开始构建和发布工件并组合工件时进入其他文物。当漏洞被报告时，无论是无意的还是恶意的，不知道正在运行什么都会给您带来麻烦。

“在添加依赖项时进行控制，”他说。对新依赖项的治理和持续审计，无论是内部的还是开源的，都是保护软件的好方法。

这种控制可以扩展到构建您使用的组件，Lorenc 继续说道，并指出这对于大多数组织来说也是艰难的一步。大多数情况下，二进制包的内容很难验证。他补充说，它不需要全部或全部，但部分开源代码正在构建和编译它。知道您可以在必要时构建它是成功的一半，并表明您可以控制进入应用程序的代码。

“开源软件就是软件，”Lorenc 说。“它充满了错误；充满了可以被利用的 CVE。” 虽然其中一些错误不会造成太大损害，但有些可能证明是有害的。

Lorenc 强调，组织应该制定处理零日漏洞和已知缺陷的计划。零日漏洞是通常成为头条新闻的浮华、令人兴奋的错误，企业应该有一个紧急手册来快速修补它们，但较旧的漏洞可能没有引起他们应有的重视。在运行大量环境和系统的大型组织中，这些缺陷很容易被忽视。

“仅仅因为你忘记了它并不意味着攻击者不会找到它，”他继续道。“这些东西从外面很容易找到。”

他说，组织必须跟踪他们正在运行的开源软件并不断更新它，并指出这通常被认为是“蹩脚”和“无聊”的工作，通常不会得到回报。Lorenc 建议对流程进行自动化、监控和跟踪，以使其尽可能简单。

“这是每个人都应该担心的事情，”他谈到已知的漏洞时说。

更广泛地说，该行业可以更好地查找和修复未知错误。

“在您使用的项目中规范上游工作，”洛伦茨说。

“上游”是指原始软件作者或维护者的方向。有一种常见的误解，认为因为代码在 GitHub 上并且经过了良好的审查，所以没有错误。他说，这不是真的，“修复上游的错误可以帮助建立重要的桥梁并改善公共利益。”

开源漏洞披露：流程提示

她说，对于初学者来说，发现漏洞的人联系漏洞管理团队 (VMT) 应该不难。Bertucio 说，该团队可能会决定使用一种常用工具或他们已经使用过的工具，但电子邮件非常好，并且可以很好地用作备份选项。安全策略应该是可访问的，并且包括在错误报告中要解释的内容以及响应预期。如果确认提交需要三天时间，请直接说出来。

从那里，问题得到确认和验证。项目所有者应该询问报告者他们是否愿意帮助开发补丁，他们是否愿意被计入 CVE，以及他们是否同意他们的披露时间表。

贝尔图西奥说：“记者真的很喜欢看到事情尽快被披露和记名。” 虽然 90 天是标准，但重要的是要弄清楚什么对双方都有效。

她补充说，到了披露的时候，安全建议应该是事实和简短的——直截了当地说明人们需要知道什么以及如何缓解它。如果您想分享发现错误的故事及其工作原理，请将其写在单独的博客文章中。

Bertucio 说，隐藏漏洞的细节没有意义，并指出“通过默默无闻的安全根本不是真正的安全。” 同样，她说，为一个特定的开源项目拥有大量 CVE 也没有错。她补充说，这意味着你对披露缺陷和强化项目有强烈的反应。