在过去的几年中，DevOps文化的出现从根本上改变了软件的开发方式，使企业能够更快地推送代码并自动扩展以支持新功能和创新所需的基础设施。DevSecOps安全越来越多地融入开发和运营管道，现在正在改变应用程序安全的状态，但最新发布的行业调查显示差距仍然存在。安全测试所有权研究公司EnterpriseStrategyGroup(ESG)最近的一份调查报告调查了北美378名应用程序开发人员和应用程序安全专业人员，发现虽然许多组织认为他们的应用程序安全程序可靠，但存在已知漏洞的代码仍在继续使用在生产中。发布易受攻击的代码并不是一件好事，但知道存在漏洞总比不知道好，因为业务决策通常涉及一些风险评估和补救计划，也许还涉及一些对策。一半的受访者表示他们的组织经常这样做，三分之一的人表示他们的组织偶尔这样做。他们提到的一些原因通常是截止日期之前的错误，或者在发布周期中发现问题的时间太晚了。该报告强调了为什么组织在开发过程的早期集成安全测试很重要，并且发布易受攻击的代码并不一定表示缺乏良好的安全程序，因为这可能出于多种不同的原因，并且没有单一类型的安全测试可以捕获所有错误。然而，调查还发现，许多组织仍在扩展其应用程序的安全性，只有33%的组织表示他们的程序覆盖了超过75%的代码库，而33%的组织表示他们的程序覆盖了不到一半的代码。调查发现，将易受攻击的代码投入生产的决策者因组织而异。在28%的组织中，决策由开发经理和安全分析师共同制定，在24%的组织中，决策由开发经理单独制定，在21%的组织中，决策由安全分析师制定。这实际上可能是应用程序安全成熟的标志，因为DevSecOps是关于在开发管道的早期进行安全测试，而在过去，安全测试只是组织安全团队的权限，他们通常在产品发布后执行它完全的。在一个组织中，开发团队由于集成到他们的流程中而进行安全测试。因此，与安全团队合作，开发经理通常会决定可接受的漏洞，而团队的安全负责人通常是具有应用程序安全知识和经验的开发人员。然而，这一决定仍应基于首席信息安全官(CISO)，他制定了组织的政策，最终负责管理整个组织的信息安全风险，并可以确定哪些应用程序更容易受到攻击攻击，或确定黑客可能攻击的位置。更敏感的信息。这些应用程序在打补丁时可能有更严格的规则。如果未正确评估风险，采用具有已知漏洞的代码可能会产生严重后果。60%的受访者承认他们的应用程序在过去12个月内受到OWASPTop-10中列出的漏洞的危害。OWASPTop-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安全团队在5月份警告称，名为OctopusScanner的恶意软件活动是NetBeansIDE项目的后门。受损或受感染的组件也会定期分发到包存储库，例如npm或PyPi。复杂的依赖网络使得处理这个问题变得更加困难。达姆施塔特大学的研究人员在2019年分析了npm生态系统，这是JavaScript组件的主要来源。他们发现一个典型的包加载了平均来自39个不同维护者的79个其他第三方包。npm上排名前五的包涵盖了134,774到166,086个其他包。Sonatype在报告中说：“当恶意代码被有意和秘密地注入开源项目的上游时，除了注入它的人之外，很少有人知道恶意软件的存在。”这种方法允许对手在上游秘密设置陷阱，一旦漏洞通过供应链传播，然后攻击下游。”2015年2月至2019年6月期间，用户报告了216次此类供应链攻击，但从2019年7月到2020年3月，记录了929次攻击，因此这已成为非常流行的攻击向量。许多组织似乎没有准备好对黑客利用组件中的已知漏洞进行的传统攻击做出快速响应。就最终导致2017年Equifax泄漏的ApacheStruts2漏洞而言，网络攻击者在漏洞公开后72小时内开始利用该漏洞。最近，SaltStack报告的一个漏洞也在公开后的三天内被利用，让许多组织措手不及。根据Sonatype对679名软件开发专业人士的调查，只有17%的组织在漏洞被公开披露一天后才知道。三分之一的组织在一周内学会了，将近一半的组织在一周后学会了。此外，大约一半的组织在得知违规行为后用了一个多星期的时间才做出回应，其中一半的组织用了一个多月的时间。开源组件的可用性和使用率每年都在增加。在过去的一年里，JavaScript社区推出了超过50万个新的组件版本，将npm目录推向了130万个包。截至今年5月，开发者从npm下载包860亿次。Sonatype预计到今年年底这个数字将达到1万亿。令人担忧的是，达姆施塔特大学去年发布的一份研究报告显示，近40%的npm包包含或依赖存在已知漏洞的代码，而npm包中66%的漏洞仍未修复。在Java生态系统中，2019年开发者从Maven中央仓库下载了2260亿个开源软件组件，比2018年增长了55%。根据2020年的统计数据，Sonatype预计Java组件下载量将达到每年3760亿个。该公司维护着一个中央存储库并深入了解数据，报告称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月的一次违规事件中泄露了包括电子邮件、散列密码在内的数据库快照；2019年7月发生在CapitalOne的违规事件影响了1亿多美国人，这是一次利用其中一个漏洞的攻击的结果。Accurics首席技术官OmMoolchandani表示：“策略即代码实施应确保最佳实践，例如加密数据库、轮换访问密钥和实施多因素身份验证。”但是，自动化威胁建模对于识别特权增加和路由更改至关重要。还需要等待它是否会在云部署中创建破坏路径。因此，当在开发过程中定义基础设施（基础设施即代码）时，组织必须将策略扩展为代码，将安全扩展为代码。”他说，一种称为“代码修复”的新实践正在出现，其中安全工具不仅检查云配置模板或运行部署本身的漏洞，但也会生成自动修复问题所需的代码并将其提交给开发人员。这可以减少组织修复所需的时间，这是一个主要问题，因为到目前为止，该过程在很大程度上是手动的，导致许多问题被忽视。在过去的几年中，许多应用程序和基础设施安全供应商一直致力于重新设计他们的产品，以便它们与开发工具很好地集成，因为开发人员与安全性有不同的期望和工作方式团队。许多开源工具也可用于测试云部署。渗透测试机构BishopFox在美国黑帽大会期间发布了一个名为Smogcloud的工具，可以帮助安全工程师和云计算管理员找到他们在AWS云平台上泄露的数据资产，包括面向互联网的FQDN和IP、配置错误或漏洞、不再使用的资产、当前未监控的服务以及其他影子IT。
