Linux安全问题的google重视

支撑万亿美元规模数字经济基础设施的Linux，终于拥有了两名全职带薪安全工程师。

Google昨日宣布将为两名专注Linux内核安全的开发人员提供薪水，此举对于Google来说虽然只是九牛一毛的资金投入，其意义却不同寻常。

以Linux为代表的自由和开源软件(FOSS)已成为现代经济的重要组成部分，据估计，FOSS在现代软件中的占比高达80%-90%，任何安全问题都有可能给各行各业带来灾难性的后果。

但令人难以想象的是，在开发安全口号响彻云天的今天，即便是Linux这样的支柱性的开源软件项目，也严重缺乏安全资源支持，甚至没有“全职”安全人员。

Google对Linux原生安全生态或者说基础安全问题的“人工救助”和呼吁，一方面说明Linux安全问题，尤其是Linux内核安全的“安全债”已经威胁到Google自身业务，另一方面也说明，开源软件的原生安全不是设立一个高额漏洞赏金计划，“用钱砸”就能解决的问题，Google希望能够释放一个信号，吸引其他科技公司也重视并投入Linux安全。

对于Google以及很多依赖Linux的科技巨头来说，缓解处于上游的Linux安全威胁变得更加紧迫，因为Google在开源软件上的赌注越来越大，Google甚至为Linux基金会贡献了Kubernetes，后者已成为云原生计算运动的关键。

Google员工软件工程师Dan Lorenc说：“随着开源在关键基础设施中的重要性不断提升，开源代码工具的安全性问题也变得更为紧迫。”

Google一直在扩大对安全的关注，这是使Google Cloud云服务产品对持有超敏感数据的公司客户更具吸引力的举措的一部分。

“希望这是一个积极的反应。”Lorenc说道：“我们正在努力领先于供应链攻击的兴起。”

Linux基金会的开源安全基金会(OpenSSF)与哈佛大学创新科学实验室(LISH)合作发布了一份最新的报告，该报告强调了对包括Linux在内的开源生态的安全性需求。

Lorenc说，随着Linux在供应链和其他大型系统中变得越来越重要，它自然已成为网络罪犯的更大目标。现在许多公司都在出售安全解决方案，但是支持Linux内核仍被视为加强基本安全性的一种方法。

通过开源安全基金会，大约有20,000名贡献者按自己的时间来维护和开发Linux。尽管其中许多人对安全性有些兴趣，但实际投入很少，而Google的举动可能有助于使安全性成为Linux项目的重中之重。

有趣的是，Google资助的两个维护者Gustavo Silva和Nathan Chancellor是一对夫妇，Google希望一笔稳定可观的薪水可以鼓励他们全身心投入Linux内核的安全开发，这对夫妇一直是此领域最活跃的参与者之一。

开源软件的“安全债”不仅仅是资金问题，更主要的是观念和时间问题。

2020年的开源贡献者调查中，在被问及有哪些外部资源对开源项目安全性产生最大影响时，将近三分之二的受访者提到了错误/安全修复程序，三分之一的受访者提及免费的安全审核(调查参与者可以选择多个答案)。大约25%的受访者表示他们希望在其持续集成流程中添加与安全性相关的工具。大约18%的人要求提供有关安全软件开发的免费课程。

显然，安全确实是开源软件贡献者的首要任务，但是，当被问及是否将时间花在与安全有关的活动上时，只有2.3%的受访者回答是。此外，调查对象表示他们不希望将来在安全上投入更多时间。

总而言之，虽然开源软件贡献者认为安全性很重要，但他们不想成为负责安全性的人。他们宁愿通过第三方审核或开源安全管理工具(例如FOSS)转移安全性相关工作负载。

报告指出，鉴于这些发现，在可行的情况下，管理开源软件项目的组织应为额外的外部安全资源提供资金。安全性流程自动化程度越高，项目受到的保护就应越多。

2020年，大多数开源软件贡献者调查的受访者通过非正式手段(而不是正式课程、公司培训课程或认证)了解安全代码开发。

最受欢迎的资源是在线论坛(StackOverflow、Reddit等)，将近51%的参与者将其视为学习安全最佳做法的有用场所。博客和在线文章紧随其后，约47%的受访者选择它们。(参与者可以选择多个答案)。30%的受访者选择“其他”，其中最受欢迎的选项是工作经验、同事与共同贡献者之间的知识共享。

对于开发和/或依赖开源项目的组织和个人来说，可以根据上述调查结果，选择贡献者最常用的渠道和资源提供安全教育和培训。例如，您可以针对特定的安全问题创建一个StackOverflow话题和共享中心，或者维护一个安全开发为主题的博客文章列表。

这其中蕴含巨大的安全培训机会。根据FOSS的调查结果，贡献者对通用安全实践的实施差异很大。例如，几乎80%的受访者表示他们的网站支持SSL/TLS，而41%的维护者或核心参与者专注于安全性。但是，只有26%的人制定了安全策略，只有22%的人在其项目中使用了威胁模型。