扫描代码重大漏洞 java_如何在DevOps流程中利用管道插件减少安全扫描和修复成本?...

f537d854369288cad87337b663e372f6.png

编者按 “本文讨论了在DevOps项目管理和执行中遇到的阻碍信息安全的问题,并以微软Azure DevOps平台演示了使用的管道插件能够识别传统应用程序扫描工具检测到的漏洞并且不会明显减缓发布的速度。以深度而平滑的整合安全扫描进程进入DevOps以平衡程序安全性和研发效率。” 摘要 本文讨论了信息安全的思想,它是项目管理和执行的障碍。从DevOps角度讨论信息安全性时,这种心态甚至得到进一步巩固。当信息技术(IT)安全团队必须在每次DevOps团队想要执行发布时手动获取应用程序代码并扫描漏洞时,DevOps的目标可能会受到重大影响。这经常导致IT安全团队及其工具被排除在发布管理生命周期之外。本文演示了可用的管道插件不会在发布过程中引入明显的延迟,并且能够识别传统应用程序扫描工具检测到的漏洞。DevOps的艺术正在推动组织以前所未有的速度来生产和发布代码,这意味着IT安全团队需要找出一种方法来将自己插入这种实践中。 简介 DevOps流程在整个组织中稳步普及。但是,在此过程中,IT安全性仍然缺乏。有多项研究,例如Ponemon Institute调查[6]指出,可用的安全工具过于复杂,无法集成到DevOps发布管道中,或者与独立设备相比,它们无法执行足够的安全评估。 在进行应用程序安全性评估的组织中,按照惯例,在计划将要发布应用程序之前,它们通常是在项目计划结束时进行评估的最后步骤之一。IT安全团队将获取源代码以执行静态代码分析,然后进行动态评估,该评估通常在构建和部署了应用程序的认证环境中进行管理。然后将这些扫描的结果编译并提供给应用程序开发人员。在这一点上,开发团队和安全团队合作以了解文档中提出的漏洞,确定如何纠正它们,最后评估它们执行修复的速度。项目经理和业务相关者有一个决定:延迟应用程序发布以使开发人员有时间进行补救,对发现的漏洞进行补偿性控制,或承担组织已知漏洞的风险。 当组织在软件开发生命周期的早期就让IT安全团队参与进来时,对组织的总体风险将大大降低。早期集成的一种解决方案是配置要在DevOps管道构建和发布过程中使用的扫描工具。安全团队不仅将从一开始就参与其中,现在,这种集成将为开发人员每当将其代码重新签入其代码存储库时产生一个持续的反馈循环。由于该选项在Jenkins,Azure DevOps或AWS等最常见的发行管道工具集中都可用,为什么保护应用程序安全的做法没有成为所有具有DevOps文化的组织的标准做法? 本文提出的研究将评估整合最常用的DevOps管道发行产品中可用的一些现有应用程序扫描扩展所需的工作量。与传统源代码和动态分析引擎中使用的工具相比,它还将评估它们提供的扫描质量。 对DevOps的影响 c547a37616099ded7b87e319fc3a1411.png 数字化转型已在所有垂直行业中顺利进行,DevOps的文化是这一运动的核心。高性能的组织,例如Google,Amazon,Facebook,Etsy和Netflix,每天都在使用日常集成/连续部署(CI/CD)方法定期可靠地将代码部署到生产中,甚至数百次甚至数千次。组织如何继续创建新应用程序或将功能增强集成到现有应用程序中,并以如此快的速度交付它们,同时确保所部署的代码不包含任何漏洞?持续的反馈循环是敏捷开发过程的基石。因此,如果正确执行,开发人员将不断收到有关其代码中存在的漏洞的反馈。这种新的反馈循环将缓慢改变开发人员的安全意识,从而使安全编码成为组织内必不可少的基本技能,从而创造了一种通常被称为DevSecOps的文化。 本文演示了在CI/CD管道中集成必要工具的复杂性,不会比该应用程序的部署无关地进行Web应用程序安全评估更花时间或需要更强的专业知识。此外,“将安全集成到DevOps文化中时,高绩效团队花费在安全问题修复上的时间比低绩效团队减少了50%。这是因为与在末尾加装安全性相比,它们在SDLC中内置了安全性” [1]。 通过在发布管道中启用静态和动态分析工具的自动化,每次将应用程序检入到存储库中或通过构建和发布管道发送时,开发团队都会自动接收其代码中存在的漏洞信息。利用此过程可节省的时间有两个。首先,随着安全编码技能的提高,开发人员将能够更快地部署应用程序或功能版本。安全分析师现在可以将时间花在动态评估,白帽子或红色团队上,而不必持续配置工具来扫描应用程序。也许最大的好处不是节省时间本身,而是每天至少进行一次应用程序扫描,而不是仅在IT安全团队意识到应用程序或功能发布并获得适当数量的安全扫描的时候进行。是时候评估这些部署了。 如图1所示,构造了一个示例管道示例。该示例被认为是传统的管道配置,没有集成安全扫描扩展。图2描述了一个示例配置,其中包括两个附加阶段,这些附加阶段启动了下面讨论的应用程序扫描扩展。 892d0f186a10ed92f4bd47cceb133ca8.png 研究方法 [实验室] 设计使用Azure云中提供的Microsoft工具套件进行这项研究。已创建一个Ubuntu服务器来承载应用程序WebGoat,这是“故意不安全的Web应用程序” [4],它将用作评估Azure DevOps管道扩展功能的应用程序。该测试将包括静态代码分析和动态应用程序扫描方面,IT安全分析人员通常会在评估可供客户使用的Web应用程序的整体安全性时采用这些方面。静态代码分析将在构建过程中进行,而动态应用程序扫描将在发布管道中进行。 [测试方法论] 建立构建和发布基线 建立基线需要测量构建和发布WebGoat应用程序所花费的时间,而无需使用任何安全扩展。SonarQube和ZAP等安全扩展将集成到管道配置中,以便在部署过程中从静态代码分析角度以及动态分析角度自动评估应用程序。管道发布过程的第一阶段涉及应用程序的构建。WebGoat应用程序文件已下载并存储在Microsoft Azure Git存储库中。构建管道被配置为引用此代码存储库并编译应用程序。在不进行任何静态代码分析的情况下,捕获构建WebGoat的时间将建立基线。Microsoft Azure DevOps管道界面为构建过程中的每个步骤提供了计时,编译大约需要3分29秒,如图3所示。 27dd50aa0c0a7f7405961787a90a294a.png 然后使用Azure DevOps版本管道配置将应用程序部署到Microsoft Azure云中的虚拟服务器。启动后,此过程大约需要28秒,如图4所示。 8bb14897f7e2cc36203429de72755d24.png 建立应用程序扫描基准线 此时,该应用程序正在VM上的容器中运行。OWASP Zed攻击代理(ZAP)的安装在Microsoft Azure门户中运行的第二台虚拟服务器上进行。然后进行代理的配置,以引用之前已安装和引用的WebGoat应用程序。传统的动态应用程序扫描方法通常涉及此过程,在该方法中,为IT安全分析人员提供了Web应用程序URL,以便在应用程序扫描工具中进行配置和分析。WebGoat应用程序由两个网站组成:WebGoat和WebWolf,它们彼此交互。将ZAP工具配置为指向URL并执行站点爬网后,再进行活动扫描。表1示出了获得的结果。表2记录了Docker容器中两个应用程序的活动应用程序安全扫描的结果。 f9d753127d73a8bb5e3d491d7b27ffed.png 6dbb33d68ec43ad81f2bb449bc5840ea.png 自动构建集成 通过建立WebGoat应用程序的基准时间,可以收集统计数据,该统计数据指示与构建管道集成时静态代码分析测试还需要花费多少时间。上面引用的原始构建管道配置已经过修改,以包含SonarQube扩展:“ SonarQube是用于持续检查代码质量的开源产品” [2]。由于WebGoat是基于Java的应用程序,因此SonarQube被选为要使用的Azure管道扩展。OWASP还具有其他静态代码分析应用程序。OWASP网站上显示的列表提供了每种工具支持的可用编码语言。 当此构建过程开始时,将在管道中添加三个附加步骤。这些步骤在此构建管道中增加了75秒的时间。无法系统地捕获准备SonarQube和重新配置构建管道以将测试结果发布到SonarQube门户所需的步骤。初始集成所需的步骤包括部署SonarQube服务器或SonarQube的虚拟实例,在SonarQube中配置新项目,以及获取配置到集成构建管道所需的必要代码段。部署和配置SonarQube服务器是一次性的设置。组织希望集成的每个项目管道的配置每个项目进行一次。 在每个应用程序管道中连接SonarQube项目之后,开发人员现在可以受益于在构建过程完成后立即不断接收有关其代码的反馈。将SonarQube扩展配置为与构建管道集成后,将启动构建,然后完成构建,随后将静态代码分析的结果发布到SonarQube项目页面。开发人员现在拥有一个非常易于使用的工具,该工具可以描述问题所在,问题原因以及代码中该问题的位置。SonarQube扩展评估应用程序并记录其分析中违反编码规则的任何代码段,即可确定应用程序中问题的摘要视图。 对应用程序代码的评估分为三类之一:错误,漏洞和代码味道[7]。尽管各个组织对分数的理解有所不同,但需要注意的是,开发人员现在拥有一个可在每次构建代码时立即提供反馈的工具。诸如SonarQube之类的工具可提供资源,以了解特定的编码实践为何会造成漏洞或错误,并提供示例来纠正在代码中检测到的问题。随着时间的推移,通过重复检查代码中的问题,开发人员将改变他们不良的编码习惯。 除了从应用程序安全性角度实现的好处之外,大多数管道扩展还提供了宝贵的报告,这些报告有助于提高开发中应用程序的质量。SonarQube扩展包含一个称为代码味道的部分,该部分突出显示了混乱且难以维护的代码段。有关该代码的其他信息被分类为几类,例如技术债务,代码覆盖率和重复项。 自动释放集成 生成过程完成后,可以构造一个发布管道来部署由于成功生成而生成的项目。在此阶段,我们可以集成动态应用程序扫描工具,如 Zed 攻击代理,这些工具将提供有关 Web 应用程序中最常见的已知漏洞的信息。在此实验室环境中进行的测试使发布管道执行增加了 3 分 35 秒。表 3 和表 4 显示了扫描每个应用程序所用的时间以及为每个 URL 发现的漏洞数。 5f984a89ed46a37f6f5c94b8800198da.png 27985167dab997361649edd606be4427.png 发现 如表5和表6所示,本研究进行的测试证实了以下假设:CI / CD管道中可用的工具具有与独立产品相同的功能。此外,集成这些工具所需的时间不会比传统安全团队使用的手动扫描方法显著更短或更长。 3e4c0a5e2e195dbdddd4249c7f1b2239.png 386478d71d351c77af4fcc1855880416.png 在CI/CD流水线中集成应用程序扫描扩展的成功取决于精心计划的过程。此处进行的研究演示了易于完成的步骤,这些步骤开始将安全工具集成到DevOps应用程序开发管道中。集成结束后,安全分析人员便能够继续增强扫描功能以及由于这些扫描而采取的措施。通过允许他们继续在此研究中进行的基本扫描测试的基础上,此配置将安全性引入CI/CD管道过程。 就像使用CI/CD管道的应用程序开发人员一样,负责集成这些扩展的安全分析人员将能够继续以高级应用程序检查的形式引入增强功能。这些检查的配置类似于开发人员在其发布管道中配置集成测试的方式。 尽管传统应用程序扫描配置与初始CI/CD配置之间的时间没有显着差异,但是从那时起,将节省大量时间。由于将在每次部署应用程序时执行应用程序扫描扩展的执行,因此不会涉及将来的时间要求。相反,每个版本的通知都必须包含IT安全性,如果组织继续使用传统的分析方法,则他们有时间分析新代码。从历史上看,IT安全团队被排除在现有应用程序的将来版本之外,如果在代码中引入漏洞,则会给组织带来重大风险。 需要注意的重要一点是,组织需要采取一种心态,即CI/CD管道中的集成应用程序扫描程序将评估最常见,众所周知的漏洞和常见的编码错误。了解这一点将使安全分析人员可以花更多的时间进行应用程序的深入功能测试,同时知道基线扫描在每次扫描期间都保持一致。 进一步采取行动 随着组织的DevOps计划不断成熟,其管道内的功能也在不断增长。成熟度以单元测试的形式出现,该单元测试的构建是为了确保代码各个方面的功能或流水线中各个阶段之间的门逻辑的功能。从安全角度考虑这种思想需要与开发团队保持牢固的合作关系,而开发团队的目标仍然是定期部署应用程序和功能更新。 一个良好的起点是将分析工具集成到管道中,而不会影响构建和发布功能。这一步将是获得应用程序中存在的漏洞和不良编码做法的可见性。当开发团队有机会审查扫描的结果并咨询安全分析人员以了解和纠正漏洞时,应做出决定,以实现可能无法进入下一阶段的大门, 漏洞被检测到。 DevOps管道中具有多种控制机制,可通过管道控制应用程序的进度。应将配置为控制管道的下一阶段是否可以开始的门的概念用作成熟度机制。随着组织开始将安全工具引入其发布渠道,他们可以决定被动配置扩展。使用这种方法,组织可以自动执行源代码分析和应用程序扫描,同时仍然允许向客户发布产品。安全扩展集成的结果是生成报告,从而使开发团队有时间查看漏洞报告。然后,开发人员和安全分析人员可以在其积压的工作中对它们进行优先排序。 在CI / CD管道中进行集成的另一个好处是,对于那些没有按常规或频繁节奏发布的应用程序。安全分析师可以与开发人员合作以设置计划的版本,这将触发应用程序扫描扩展。由于源代码未更改,因此该重复计划不会影响应用程序的功能。许多动态代码分析工具正在不断开发可在扫描范围内执行的测试,以寻找在野外发现的最新漏洞。例如,在识别了Heartbleed漏洞之后,ZAP社区将测试配置为活动的扫描器功能,以测试其扫描的每个应用程序是否存在。如果使用安全扩展配置了管道并将其设置为定期发布,则即使代码没有任何更改,如果其应用程序容易受到新发现的漏洞的影响,开发人员也会收到通知。 在CI / CD管道中集成安全工具的另一个好处是,可以如何配置应用程序中的漏洞通知。许多扩展具有内置功能,这些功能可以重新集成到敏捷团队用来管理工作的工具中。例如,在Microsoft Azure DevOps工具集中,安全分析人员可以选择为每个检测到的漏洞自动创建工作单或错误项,并将它们放置在开发人员的积压任务列表中。使用此功能将有助于推动将安全性集成到DevOps文化中的采用。如果开发人员不需要采取手动步骤来查看和了解发现的漏洞,则他们将更有可能解决其代码中的漏洞。可用的扩展提供了有关漏洞的详细信息,其中包括有关如何更正它们的资源。 结论 改变任何组织的文化都需要多个团队的共同努力,而且并非一蹴而就。借助当今可用的工具,以及以越来越快的速度不断发布应用程序或对现有应用程序进行功能更新的愿望,IT安全社区必须帮助保持这些应用程序及其处理的数据的安全。通过利用可用的CI/CD管道扩展,组织可以开始在DevOps流程中集成安全思想体系,并将安全编码放在开发人员思想的最前沿。必须实现这一点, 而且可以实现,而不必强迫开发人员放弃他们今天所习惯的CI/CD工具。

参考资料

1.2018 State of DevOps Report. (n.d.). Retrieved from https:// puppet.com/resources/whitepaper/state-of-devops-report. 

2. Docker Hub. (n.d.). Retrieved from https://hub.docker.com/. 

3. Kim, G., Debois, P., Willis, J., Humble, J., & Allspaw, J. (2017). The DevOps handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. Portland, OR: IT Revolution Press, LLC. 

4. OWASP WebGoat Project. (2019). Retrieved from https:// www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_ Project. 

5. OWASP Zap Attack Proxy Project. (2019). Retrieved from https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project. 

6. Ponemon Institute – “Bridging the Digital Transformation Divide: Leaders Must Balance Risk & Growth” (2018) Retrieved from https://www.ibm.com/downloads/cas/ON8MVMXW. 

7. SonarQube Resources. (2019). Retrieved from https://sonarqube.org/features/integration/.

关于作者

e7e4a9270af8de8644b1fd7b04d5400b.png

Jon-Michael Lacek

目前正在SANS技术学院寻求信息安全管理理学硕士学位。他在网络和安全领域拥有近15年的经验,他希望在过渡到管理领域时充分利用这一经验,目前他负责管理一家私有零售组织的运营,NOC,DevOps和自动化团队。除CISSP外,乔恩·迈克尔(Jon-Michael)目前还拥有5项GIAC认证。可以通过jmlacek@gmail.com与他联系。

来源:网络安全与网络战,rekingshui,版权归原著作者所有 原文:https://mp.weixin.qq.com/s/ikW_iM6p9CCxYd_aRrQ8DQ
bca3589bc6a19b1729e26e2f86b8a01d.png

DevOps安全社

专注于DevOps安全、DevSecOps、开发安全、开源安全等行业领域的优质内容分享与传播。一个真正懂DevSecOps的订阅号。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值