在 （Open Web Application Security Project）2015 年的年报中，SQL注入和跨站点脚本再次被列入Top 10软件隐患。

你是否觉得过去十年一直一成不变，从表面上也可以这么看。那么，为什么我们能够建造智能机器人，将无人机发射至太空，甚至创造出能够识别自然语言并能在智力竞答节目中击败人类的计算机，但却一直没有解决这些软件隐患？

安全公司 Cigital 首席技术官 John Steven 曾这样说道：修补这些漏洞使得“我们正处于并厌烦于一个仓鼠转轮的痛苦之中”。Rogue Wave 的首席技术官 Rode Cope 也深表赞同：「你也许会觉得 15 年过后这将不再是个问题。但是 OWASP 的前十榜单似乎每年都一模一样。」

的前沿应用安全分析专家 Joseph Feiman 说：「开发者将会继续写出不安全的代码，而对此他们自己也无能为力。面对黑客，这是一场注定失败的战争。」

现在的软件生命周期与二十年前的相比已经大不相同，那时候你只需要开发软件然后放在防火墙后面运行，在接下来六个月到一年（或者更久），新的软件版本开发出来之前你完全不用对它做出任何改变。测试机构 Bugcrowd 的 CTO Chris Raethke 指出，时下软件应用都是基于部件横向开发出来的。「所有的应用都是因特网的碎片。」他说道，「且依赖于微服务（microservice）和面向服务的架构。」

Raethke 更进一步说到，因为版本发行时间的存在，开发者必须争分夺秒，产品特点和更新更多由公司内非技术人员引导。他如实说到：「你不能期待某种魔法能够变出机构想要的安全、可扩展且万能的应用」。

安全，谁之责？

长久以来，安全倡议者都认为代码的安全性由开发者决定。其他人则坚持认为相对于安全专业人员来说，开发者由于不专攻系统漏洞因此对漏洞的最新进展知之甚少。

「底线在于，我们不能让开发者去做这件事，」Cope 补充道，「这不是一个复选框，而是整个开发过程中至关重要的一部分。」

对于开发者来说在代码阶段保证安全就是一个魔咒。相对于保证软件的抗攻击性，他们对开发出酷炫的功能更有兴趣。Cope 说开发者并不觉得代码安全工作有趣，他们总是这样对自己说：「我不会因为写出安全的代码而出名。只有开发出酷炫的新功能才能让我扬名，或者因为遭受攻击而因此被责备。但是除了避免更多的痛苦意外并没有其他更好的办法。」

Cope 还提到开发机构面对的另外一个大问题是，新人入职时对代码里的脆弱性并不了解。他表示：「总会有新的开发人员不断加入，因此已经在几年前遇到攻击问题的人会知道避免 SQL 注入的问题或缓存溢出，而刚入职的新人可能现在正维护着他的代码。」

「但那些刚离开学校，或是刚使用新语言开始写代码的人不知道那些漏洞具体长什么样，而他们正学习这些新代码。在过去十五年内不断犯错的人并不是同一个人，而是一些新手正重新制造这些漏洞。」

远远不止不明白他们写出的代码，开发者加入一个正在进行中的项目还需要了解 Gemalto 产品经理 Todd Steel 所说的操作环境的边界性。开发者的安全测试「更多的是数据分析和问题解决，远不是理解系统框架和该框架的局限性。」

但是 Steel 同时又坚决地相信「了解（系统）环境和漏洞是开发者义不容辞的责任。」

在传统意义上，开发者写代码，执行功能和回归测试，制造出坚固的架构。然后，QA （质量保证）组保证其正常工作。Cope 指出，软件安全测试则是另外一回事。他认为应该有安全专家来确定软件易被攻击的地方，而不仅仅是确定它能正常运行而已。而这些技能常常是开发者没有学过因而不具有的。

Steven 说 code hygiene 总会有问题出现。「作为测试者的我们有点像牙医，当我们去看牙医时他会问「每次就餐后你都刷牙了吗？」我们会说「没有，我吃的是商务餐，没法刷牙」卫生是不可能的。要求开发者在写每行代码时注意 code hygiene 是不可能的。」

新方案的到来

自从软件在很多高调且有破坏性的情形中崩溃，在撰写此文我们访问的专家都认为已经到了重估软件安全的时间，解决措施是使用自动工具甚至是开发一种全新的能够使应用保护自己免受攻击的办法。

「有些事情简洁明了，如密码存储，我们知道怎样做才是正确的但是对一般的开发者来说却异常痛苦，」 Steven 解释道，「我们能够向他们展示一次。在公司里我们能够教他们写一次代码，而他们再次使用时还是会忘记…安全 API 的概念，对吗？」

「然后还有很多 hygienic 问题，」他继续说道，「例如之前我们已经讨论到的注入问题缺陷，没有任何测试或单一控制能解决这个问题。因此我们需要同等的 hygienic 程序，而它们拥有不同的库和框架。如果使用不同的工具应付软件漏洞，那么开发者就不可能陷入这个泥淖。」

Cope 认为不能指望开发者手动解决安全问题。「这不会发生，」他说，「对他们来说这太冗长乏味了。」

「因此开发周期必须囊括这个重要必不可少的步骤而不仅仅是某项检查框。就如你快速写出代码需要后续的可行性测试，包括单元测试，功能测试等等，我认为安全测试应该被提升到同等的首要位置上来。」

「第二点」他继续说道，「就是你必须实现自动化。不管是第一次还是后续检测你都不可能手动把它做好。代码审查是很好，但是并不是每行代码都会被仔细地检查。开发者也是人……他们也会觉得累，会觉得饿，写出的代码永远不会是完美的。你需要相关的工具能帮忙时刻盯着，某个开关是否正确，是否重要等等，一些小工具能够阅读代码并检查安全错误。这两者需要结合一致，不能指望开发者在没有任何外界的帮助因素下就能解决所有问题。管理层必须提高视野高度。」

Gartner 公司的 Feiman 有一个全新的方法。「如果我们不能或很好地检测所有的应用，我只看到一个解决办法：应用软件自我测试，」他说，「我们做不到对所有应用都进行分析，这就是为什么 Apps 必须自我检测。而且因为利用现有的方法（ firewalls、IPSes、IDSes、Web application firewalls、encryption ）我们无法保护所有的应用，唯一的解决办法就是软件应用必须实现自我保护。”

软件安全就是一个难惹的毛球。如 Feiman 指出的那样「软件安全是最近才出现在应用安全大家庭之中的。其中身份管理问题，45 年；网络防护，30 年；端点问题：25 年。我们看到的这些攻击都十分普遍而且很成功，我们无法阻止它们，这让我们感到绝望。」

「但是网络销售商仍旧不断出售它们……甚至推送它们，不仅仅是销售它们。防火墙经销商也一样。端点保护也是如此。他们不断添加着新的特性，这里改一改那里修一修，然后说现在的产品更好了，效果更佳了。而由于我们并不知道详情，我们会照单全收。这就像在青霉素出现以前他们会推荐使用草药，而你使用它们是因为市场上没有更好的选择了。我想说的是，这和四年前我们刚从事这个研究时所问的问题出现的巨大的反差，那时候我们说「怎么会，如果我们都认为应用（ app ）是最重要的财产（应用以及它处理的数据），那么它怎么会是完全软弱的呢？它不能自我检查，不能自我保护，这怎么会呢？」」

因此，Feiman 想出了运行时应用软件保护（ Runtime Application Software Protection (RASP) ）的概念。他同时也警告道：「我们给了身份验证管理 45 年的进化时间。而 45 年过后，这仍然不够。我们给网络安全 30 年的进化时间，结果也是没有起到作用。那么在最后，我们给了端点防护 25 年的进化时间，而现在仍有它不能抵御的病毒。」

「所有的技术都拥有复杂的执行部件，而 现在还处于萌芽发展时期，但是一些有名的世界组织正在使用由企业收购的生产执行部件，以保护它们的财产。」

由 Bugcrowd 公司的 Raethke 提出的另外一种方法则是创造一支由各个部门代表组成的能够在企业内部捍卫变革的「fire team 」。「一两个工程师，一个生产人员、安全人员、管理人员，以及一两个销售部门人员代表和市场部员工代表，」他说。这样的话，任何关于产品的反馈都会传达到所有团队，这个方法对改变运行操作十分高效。「这给所有的人都提供了参与的机会。」

Raethke 认为跨组织规则之间的交流是关键所在。「任何向组织内部推广的措施（包括安全）都必须是可持续的。」他建议在开始阶段纳入两名开发者和两名操作团队成员，在共同性确定之后再带入销售，市场和行政部门的人员。

未完待续...

如今，多样化的攻击手段层出不穷，传统安全解决方案越来越难以应对网络安全攻击。 实时应用自我保护技术,可以为软件产品提供精准的实时保护，使其免受漏洞所累。想阅读更多技术文章，请访问 。

本文转自