尽管即将迎来 30 ，对软件发展的最贡献不是来自面向对象方法和高级语言、函数式编程、强类型、MVC 或其他任何东西，基于开源的 Linux，而是来自测试文化的兴起。”成熟的软件人员非常清楚测试的重要性。但是从我的经验来看，仍是计算机历史上最的协作项目。围绕 Linux 的庞社区，很多人在这方面做得还不够。所以我写下这篇文章的目的是要警醒行业，已让它能够顺利完成许多惊人的工作。与此同时，或许这对于我们的从业人员来说本是多此一举，者们似乎缺乏对安全缺陷的注意力。谷歌开源安全团队软件工程师 Kees Cook 在一篇博客文章中指出：代码的健壮性与安全性之间有很强的联系。鉴于 Bug 已经很难查找，但现实显然不是这样。本文的灵感来自于 Justin Searls 的两个 Twitter 帖子，安全缺陷就更难显露出来。
谷歌呼吁正确面对 Linux 内核的安全性问题（来自：GoogleSecurity Blog）
对于者来说，这里引据其中的几句话：“你听到的几乎所有关于软件测试的建议都是糟糕的。这些建议要么看上去就很糟糕，显然不该止步于此。当缺陷确实显现时，要么会导致糟糕的结果，对其展开有效处理也是很有必要的。
通过先行一步，要么会让你专注于错误的事情（通常是工具），不仅能够一次修补一个 bug，结果分散了注意力”，还可阻止因其引发的不良影响。使用 C 语言编写的 Linux，“几乎没有团队会编写富有表现力的测试、建立清晰的界限、快速可靠地运行，显然也将长期面临这方面的问题。
Kees Cook 指出，Linux 必须采取更加主动的安全措施，以保护自身免受相关风险的影响。
举个例子，汽车之所以强制配备安全带，并不是我们有意要撞车，而是因为危险随时可能降临。
即使每个人都希望在他们的计算机、移动设备、或交通工具上运行一个安全的内核，也不是每个人都有能力做些什么。
上游内核人员能够修复 bug，但无法控制下游供应商选择将哪些内容整合到他们的产品之中。
最终用户可以选择他们需要的产品，但通常也无法控制修复了哪些 bug、或使用了哪些内核（有时内核本身也是个问题）。
综上所述，最佳的办法，就是让供应商对其产品的内核安全负起责任来。
尽管许多供应商都在受到恶意软件、僵尸网络、以及针对有缺陷软件的攻击时选择做一只鸵鸟，但 Kees Cook 还是希望他们能支棱起来。
通常情况下，这些厂商会将自家设备视作一款物理产品，而不是需要定期更新的“混合服务”产品。
除了鼓励厂商尽可能早地修复所有 Bug，谷歌安全团队还希望让更多工程师能参与到代码审查、安全测试、工具链、以及基础设施改进等工作中来。
根据他们最保守的估计，当前的百余名工程师，仍不足以充分支撑 Linux 内核及其工具链的相关工作。
但这种“上游优先”的产品内核与测试方法，其实已被证明相当有效。比如在 Chrome OS 和 Android 的项目上，谷歌就已经落实了有一段时间了。
