应用程序安全性状态：统计数据会告诉我们什么

在过去几年中，DevOps文化的出现从根本上改变了软件开发的方式，使企业可以更快地推送代码，并自动扩展支持新功能和创新所需的基础设施。而将DevSecOps投入到开发和运营渠道中的安全性日益增强，现在正在改变应用程序安全性的状态，但是一份最新发布的行业调查报告表明，这种差距仍然存在。

安全测试所有权

调研机构Enterprise Strategy Group(ESG)公司最近发布的一份调查报告对北美地区的378位应用程序开发人员和应用程序安全专业人员进行了调查，发现尽管许多组织认为自己的应用程序安全程序很可靠，但仍继续将具有已知漏洞的代码用于生产环境。

发布易受攻击的代码并不是什么好事，但知道有漏洞总比毫不知情要好，因为企业的决策通常涉及一些风险评估和修复计划，也许还有一些应对措施。一半的受访者表示他们的组织经常这样做，三分之一的受访者表示他们的组织偶尔也这样做。他们提到的一些原因通常是在截止日期之前出现漏洞，或在发布周期中发现问题为时已晚。

这份报告强调了组织在开发过程中尽早地集成安全测试是很重要的原因，而且发布易受攻击的代码并不一定表示没有良好的安全程序，因为这可能有多种不同的原因，并且没有一种单一类型的安全测试能够捕获所有的错误。然而，调查还发现，许多组织仍在扩展其应用程序的安全性，只有33%的组织表示其程序覆盖了代码库的75%以上，33%的组织表示其程序覆盖了不到一半的代码。

调查发现，将易受攻击的代码投入生产的决策者可能因组织而异。28%的组织的决策是由开发经理和安全分析师共同做出的，24%的组织中的决策是由开发经理单独做出的，21%的组织的决策是由安全分析师做出的。

这实际上可能是应用程序安全性成熟的标志，因为DevSecOps是关于在开发管道中尽早进行安全测试，而在过去，安全测试只属于组织安全团队的范围，他们通常在产品完成后执行安全测试。

在组织中，开发团队由于集成到他们的流程中而进行了安全测试。因此与安全团队合作，由开发经理做出可接受漏洞的决策是正常的，而团队的安全负责人通常是一位具有应用程序安全知识和经验的开发人员。但是，这种决策仍应基于制定组织策略的首席信息安全官(CISO)做出，他最终负责管理组织整体的信息安全风险，并且可以确定哪些应用程序更容易受到攻击，或者确定黑客可能攻击的更敏感信息。这些应用程序在打补丁时可能有更严格的规则。

如果没有正确评估风险，则采用带有已知漏洞的代码可能会造成严重后果。60%的受访者承认，在过去12个月里，他们的应用程序受到了OWASP Top-10列出的漏洞进行攻击。OWASP Top-10包含了Web应用程序最关键的安全风险，其中包括SQL注入、破坏身份验证、泄露敏感数据、破坏访问控制、安全性错误配置、使用具有已知漏洞的第三方组件等问题。这些问题通常不应该允许存在于生产代码中。

根据ESG公司的这份调查报告，很多组织使用的各种应用程序安全测试工具包括：API安全漏洞(ASV)扫描(56%)、防止错误配置的基础设施代码安全工具(40%)、静态应用程序安全测试(SAST)工具(40%)、软件组成分析(SCA)测试工具(38%)、交互式应用程序安全测试(IAST)工具(38%)、动态应用程序安全测试(DAST)工具(36%)、可以帮助识别和解决安全问题用于集成开发环境的插件(29%)，扫描容器和存储库以及微服务中使用的图像的工具(29%)、模糊测试工具(16%)、容器运行的配置安全工具(15%)。

然而在使用这些工具面临的挑战中，其中包括，缺乏发现并解决问题的开发人员(29%)，没有使用组织有效投资工具的开发人员(24%)，安全测试工具增加难度并减慢了开发速度周期(26%)，以及来自不同供应商的应用程序安全工具之间缺乏集成(26%)。

尽管将近80%的组织表示，他们的安全分析师通过直接工作以审查功能和代码，与开发人员合作进行威胁建模，或者参加开发Scrum会议，但他们自己似乎没有接受更多的安全培训。这就是只有19%的组织的应用程序安全测试任务是由开发人员正式拥有的原因，26%的组织是由开发经理负责的。三分之一的组织仍然将这项任务分配给专门的安全分析师，另有29%的组织由开发和安全团队共同拥有。

在三分之一的组织中，只有不到一半的开发人员接受过安全培训;只有15%的组织表示，其开发人员都进行了这种培训。不到一半的组织要求开发人员每年参加一次以上的安全培训，其中16%的组织希望开发人员进行自我教育，而20%的组织只在开发人员加入团队之后才提供培训。

此外，即使在提供或需要安全培训的情况下，大多数组织也无法有效跟踪这种培训的有效性。只有40%的组织对开发团队或开发人员跟踪安全问题和进行持续改进。

针对供应链攻击的开源组件

任何成熟的应用安全程序也应该涵盖开源组件和框架，因为这些组件和框架在现代应用程序代码库中占有很大比例，并且存在继承漏洞和供应链攻击的风险。在ESG公司的调查中，几乎一半的受访者表示，开源组件占到他们代码库的50%以上;8%的受访者表示，他们三分之二的代码是由开源组件组成的。尽管如此，只有48%的组织投资于处理开源漏洞。

开源治理服务提供商Sonatype公司在其《2020年软件供应链状况报告》中指出，针对开源软件项目的网络攻击同比增长430%。这些网络攻击不再是被动的，因为网络攻击者在这些漏洞公开披露之后就利用了这些漏洞。而网络攻击者试图破坏恶意软件并将其注入上游开放源代码项目中，然后由开发人员将其代码提取到自己的应用程序中。

GitHub安全团队就名为Octopus Scanner的恶意软件攻击活动在今年5月发出了警告，该软件是NetBeans IDE项目的后门程序。而受到攻击或感染的组件也已定期分发到软件包存储库(如npm或PyPi)中。

复杂的依存关系网络使处理这个问题变得更加困难。达姆施塔特大学的研究人员在2019年分析了npm生态系统，它是JavaScript组件的主要来源。他们发现，一个典型的软件包从平均39个不同的维护者中加载了79个其他第三方软件包。npm上排名前五位的软件包覆盖了134774到166086个其他软件包。

Sonatype公司在报告中说：“当恶意代码被有意地和秘密地向上游注入开源项目时，除了植入它的人员以外，几乎没人会知道恶意软件在那里。这种方法可以使对手秘密地在上游设置陷阱，一旦漏洞通过供应链蔓延，然后在下游进行攻击。”

该公司称，在2015年2月至2019年6月，用户报告了216起这种供应链攻击，但从2019年7月至2020年5月，有929起攻击被记录在案，因此这已成为一种非常流行的攻击媒介。

对于黑客利用组件中已知漏洞的传统攻击而言，很多组织似乎没有足够的准备能够迅速地做出响应。就Apache Struts2漏洞最终导致2017年的Equifax公司的泄漏事件来说，网络攻击者在这个漏洞公开之后的72小时内便开始利用该漏洞进行攻击。最近，SaltStack公司报告的一个漏洞在公开后的三天内也被利用，导致许多组织措手不及。

Sonatype公司对679位软件开发专业人员的调查表明，只有17%的组织在漏洞公开披露一天之后才得知。三分之一的组织在一周内得知，而将近一半的组织在一周之后得知。此外，大约一半的组织在了解到这一漏洞之后在一个多星期之后才对漏洞进行响应，其中一半的组织花费一个多月的时间。

开源组件的可用性和使用量在逐年增加。在过去的一年中，JavaScript社区引入了50多万个新组件版本，将npm目录推至130万个软件包。直到今年5月，开发人员从npm下载的软件包达到860亿次。Sonatype公司预计到今年年底，这一数字将达到1万亿次。令人担忧的是，达姆施塔特大学去年发布的研究报告表明，所有npm软件包中将近40%包含或依赖具有已知漏洞的代码，而npm软件包中的66%漏洞仍未修复。

在Java生态系统中，开发人员在2019年从Maven中央存储库中下载的开源软件组件达到2,260亿次，与2018年相比增长了55%。根据2020年的统计数据，Sonatype公司估计，Java组件下载量每年将达到3,760亿次。该公司维护中央存储库，并对数据有深刻见解，该公司报告说，10%的下载是针对具有已知漏洞的组件进行的。

对1,700个企业应用程序的进一步分析表明，它们平均包含135个第三方软件组件，其中90%是开源的。这些开源组件中的11%至少具有一个漏洞，但是应用程序平均从这些组件继承了38个已知漏洞。而由2,000到4,000个开源组件组合而成的应用程序并不少见，这凸显了开源生态系统在现代软件开发中的主要作用。

在.NET生态系统和微服务生态系统中观察到了类似的组件使用趋势，其中DockerHub在过去一年中收到了2.2个容器映像，并且有望在今年看到开发人员提出960亿个映像拉取请求。公开报告的供应链攻击涉及托管在DockerHub上的恶意容器映像，并且存在配置错误或漏洞的映像的可能性也很高。

基础设施即代码需要进行修正

DevOps运动从根本上改变了软件开发，并使得新的微服务架构成为可能，在这种架构中，传统的整体应用程序被分解为在各自容器中运行的单独维护的服务。应用程序不再仅包含其功能所需的代码，还包含指示其在云平台上的部署并自动进行部署的配置文件，以及所需的资源。通过DevSecOps，开发团队不仅负责编写安全代码，还负责部署安全基础设施。

云计算安全厂商Accurics公司在最近发布一份调查报告中称，该公司运营着一个平台，可以检测基础设施中易受攻击的配置，例如代码模板和云部署，41%的组织在其配置中拥有硬编码密钥，这些密钥用于提供计算资源，89%的部署配置了资源，并且运行时使用了过度宽松的身份和访问管理(IAM)策略，而且几乎所有策略都有错误配置的路由规则。

该公司表示， CenturyLink公司在2019年9月发生的泄露事件中泄露了280万条客户记录;Imperva公司在2019年8月发生的泄露事件中，泄露了包含电子邮件、哈希密码的数据库快照;Capital One公司在2019年7月发生的泄露事件影响了1亿以上的美国人，这是利用其中一个漏洞进行攻击造成的。

Accurics公司首席技术官Om Moolchandani说：“策略即代码的实施应确保采用最佳实践，如加密数据库、旋转访问密钥和实现多因素身份验证。然而，自动威胁建模对于确定权限增加和路由更改等是否会在云部署中创建破坏路径也是必要的。因此，当在开发过程中定义基础设施(基础设施即代码)时，组织必须将策略作为代码，安全性作为代码进行扩充。”

他表示，一种称为“代码修复”的新实践正在兴起，安全工具不仅检查云配置模板或正在运行的部署本身的漏洞，还会生成自动修复问题所需的代码，并将其提交给开发人员。这可能会缩短组织进行补救的时间，这是一个主要问题，因为到目前为止，这一过程基本上都是人工完成的，导致许多问题被忽略。

在过去的几年中，许多应用程序和基础设施安全供应商一直在致力于重新设计他们的产品，以便他们能够很好地与开发工具集成，因为开发人员的期望和工作方式与安全团队不同。许多开源工具也可用于测试云部署。

渗透测试机构Bishop Fox公司在美国黑帽大会期间发布了一个名为Smogcloud的工具，该工具可以帮助安全工程师和云计算管理员找到他们在AWS云平台泄露的数据资产，其中包括面向互联网的FQDN和IP、配置错误或漏洞、不再使用的资产、当前未监控的服务，以及其他影子IT。