那些我们还不知道的程序惊人复杂性
在过去几十年的高速编码中,我们已经飞速实现自动化,导致我们现在已经无法保护我们构建的东西。首先,让我们看几个事实:
通常情况下,中等规模的金融机构拥有超过1000个应用程序,而大型企业则超过10000个应用程序。平均来说,这些应用程序都有数十万行自定义代码,最大的应用程序可能有超过千万行代码。此外,每个应用程序都包含几十个到几百个软件库、框架和组件,这通常超过自定义代码的10倍。并且,这个数量正在迅速增长,超过20%的应用程序每年都会有新增和更新的代码。
例如美国联邦政府税代码(US Federal Tax Code),在过去几年已经大幅增长,目前,该代码已经拥有超过440万行,但却只有几个应用程序。作为安全研究人员,笔者发现代码中包含数千个漏洞。但作为前任首席执行官,笔者还分析了法律合同中的漏洞。有趣的是,无论笔者审查软件代码还是法律语言,这两种分析并没有你想象的那么不同。这两种分析都需要了解专门的语言以及基本业务。
当前的安全形势
在摩根大通安全泄露事故的细节披露后,该公司一名前雇员告诉《纽约时报》,攻击者仿佛窃取了国会大厦的构造图,摩根大通没办法监控每个门和玻璃窗。实际上,笔者认为情况更糟糕,摩根大通花了几十年时间来创建其软件基础设施,没有简单的办法可以对其作出改变。
现在,根据安全专家表示,典型的企业web应用程序一般包含22.4个严重漏洞。这些漏洞通常很容易找到,但其严重程度不相同。通过结合这些漏洞以及日益复杂的威胁,我们看到越来越多的安全泄露事故。单单是今年的安全泄露事故已经非常发人深省。
传统应用安全的局限性
在过去,我们进行手动渗透测试和代码审查来发现漏洞。这些审查可以很好地发现漏洞,而开发人员也有时间在代码进入生产之前来修复问题。但最近软件开发领域的进步,包括库和组件的广泛使用、高速开发方法、复杂的框架以及高深莫测的协议,都减慢了手动分析。
很多行业已经发展到,生产速度已经最大化,而质量却无法跟上。汽车行业经过很多艰苦岁月来换装备以提高质量。Agile和DevOps社区已经成功地使用更快的迭代来保持软件项目不会偏离轨道太远。现在,我们正在越来越快地构建代码,但安全没有同步发展。我们必须找到新的技术来确保快速发展和扩展中的安全性。
重构应用安全
首先,我们需要摒弃安全例外的观念,并从其他行业借鉴经验。我们可以监控整个软件开发过程(设计、开发、测试和生产),确保应用程序不断测试自己并提供实时安全反馈信息。从本质上讲,我们必须将安全测试、入侵检测和响应以及运行时保护作为每个应用程序的一部分。
Etsy、Netflix、Twitter和Yelp等公司已经意识到这个问题,并开始部署新的安全工具。这些工具不像传统工具,在开发过程的最后使用。这些工具用于软件开发过程中,在应用程序被构建、集成、测试和部署时实时收集安全信息。最重要的是,这些工具(例如连续集成和连续交付工具)并不会干扰正常的软件交付过程。干扰或者减缓软件交付的安全工具不会被使用。正如Signal Science公司的Zane Lackey所说,企业把延误视为破坏,会尽量避免。
我们怎样才能实现那样的情况?这并没有你想象的困难。你可以从创建脚本、测试用例或执行简单测试的工具开始。或者使用免费的Contrast for Eclipse插件。你将需要的大部分基础设施可能已经由Agile and DevOps团队创建好了。
我们需要重新构想我们所有的安全测试技术,让它们可以共同发挥作用。我们还需要我们的安全专家变成教练和工具达人,而不只是追逐漏洞,因为这样永远不会形成规模。
相关文章
- 1条评论
- 辙弃绮烟2022-06-04 17:43:57
- 经发展到,生产速度已经最大化,而质量却无法跟上。汽车行业经过很多艰苦岁月来换装备以提高质量。Agile和DevOps社区已经成功地使用更快的迭代来保持软件项目不会偏离轨道太远。现在,我们正在越来越快地构