第 0 天是开发的第一天

哥伦比亚大学最近的一项研究发现，我们每天都要做出 70 多个决定。 如果你只计算重要的决定，康奈尔大学先前的研究表明，我们每天都会做出超过 200 个与食物有关的决定。

我们每天做出的许多决定从长远来看都是无关紧要的。 其影响非常微小，而且大多数都无法归类为“好”或“坏”。 它们仅仅是我们做出的选择。 但有些选择会带来重大后果。 有些是故意的，是经过深思熟虑的。 其他的则是无意的，只有事后才变得明显。

事后看来，一些意想不到的后果显然与我们的应用的安全性有关。 

选择： 平台、框架和组件  

从开发的第一天起，我们就在做出选择。 许多选择都围绕平台和框架、库和第三方组件。 在开发过程中我们做出了很多这样的选择。 据估计，目前应用的 80-90％ 是由开放/第三方源组件组成的。 导致包含开放/第三方源组件的每种选择都会产生潜在的后果，特别是在应用安全性方面。 Black Duck Software 的分析表明，平均每个商业软件产品包含 105 个开源组件。

从表面上看，这些后果并不是那么可怕。 毕竟， Contrast Security 的研究发现，软件库仅占漏洞的 7%。  Black Duck 平均每个应用发现 22.5 个开源漏洞。 其中百分之四十 (40%) 的漏洞被评定为“严重”。 尽管如此，考虑到应用剩余的 10-20％（自定义代码）是造成应用中大多数漏洞的原因，这个数字还是很小的。

不幸的是，大部分漏洞并未通过 CVE 披露，并且示例漏洞代码很容易被攻击者获取。 在成千上万个 Web应用经常使用相同组件和库的环境中，不良行为者不需要费力就能找到目标。 目前，builtwith.com（一个跟踪应用程序和网站构建技术使用情况的网站）统计出近 40,000 个依赖 Apache Struts 的在线网站。 我们大多数人都知道，Apache Struts 2 中已发布的漏洞已被成功利用，从而导致了互联网上的轻微恐慌。 其他大量使用的开源和第三方库（如 OpenSSL）的严重漏洞披露也引发了类似的恐慌。

但潜在问题的不仅仅是我们是否包含库或第三方组件或在开源框架上构建应用程序的选择。 我们在开发过程中做出的其他选择也会产生严重的影响，特别是当它们导致不安全的开发实践时。

选择： 用速度换取安全

听到用速度来换取安全性，这并不奇怪。 情况一直如此。 2014 年，迈克菲对 504 名安全专业人士进行的一项调查发现，“大约三分之一的受访组织和运营商承认，他们试图通过定期禁用防火墙安全功能来提高网络性能。”

事实证明，发展也没什么不同。 他们的重点不是执行速度，而是管道速度。 为了满足更及时地向市场发布应用和更新的需求，许多公司承认在开发过程中完全跳过了安全性。 IBM 在 2017 年 Arxan 对移动和物联网开发人员进行的一项调查发现，26% 的受访者根本不测试移动应用程序是否存在安全问题，近一半 (48%) 的受访者根本不测试物联网应用程序。  69% 的人表示，交付压力是经常忽视安全检查的原因。

今年夏天，我们在客户活动Agility上对参会人员进行的一项民意调查证实了这一现实。 超过一半（62%）的人承认，他们在组织中用安全性换取了速度。

然后，组织需要选择如何解决发现的漏洞。 Black Duck 的分析显示，2018 年扫描的应用中仍有10% 容易受到 2014 年 Heartbleed 漏洞的攻击。 Ponemon 开展的一项 ServiceNow 研究发现，令人不安的是，57% 的违规受害者表示，他们本可以通过安装可用的补丁来防止违规行为发生。 

选择会产生后果

从开发的第一天到部署后，我们对整个应用堆栈的安全性所做的选择都很重要。 这些选择与午餐吃汉堡或沙拉不同；这些决定的影响不仅会影响 IT 和业务，还会影响依赖应用程序提供商认真对待安全性的客户。 

我们中很少有人可以声称从未收到过“亲爱的应用程序用户”的信件，告知我们我们的数据已被泄露。 这并不意味着可以放松安全监管；相反，我们应当尽力为客户提供更好的个人隐私信息保护。

做到这一点的最好方法是认识到从开发第一天开始的每一个选择都是提高我们开发的应用安全性的机会。 有意识地、明智地选择。