DevOps 安全威胁,你值得关注!

随着开源软件被大量引用,线上运行的代码中超过80%的部分是开源代码。软件安全的重点已经从内部代码转移到所引用开源部分上。 DevOps安全需要关注内部研发团队的自研代码以及外部第三方开源软件的安全,对于内部代码,所使用的依赖必须清楚,如果底层依赖有风险,还必须快速反向分析哪些其他软件受到同样的威胁;目前DevOps安全团队和持续交付团队往往独立运行,信息交互频繁且效率低导致质量难以保证,安全问题整改的计划外工作量大,成为DevOps安全工作常见的痛点。

开源安全威胁日趋严重

随着互联网化的趋势日趋普遍,各大中小型企业都会基于开源软件构建各种业务系统,可以说开源已经成为了目前企业内部构建业务系统的重要组成部分。开源软件缩短了软件交付周期的优势确实很明显,但是开源软件的安全性也给企业带来很多麻烦,尤其是涉及关键业务的一些系统。引入开源组件的途径多种多样,有可能是开源的源码,也有可能是开源的第三方类库,或者从互联网上复制下来的代码段。

这里写图片描述

开源软件进入企业内部之后,还可能被其他团队继续使用,在经历了长时间的开发周期后,某个第三方开源软件被引用的情况已经变得无从追踪,一旦某个开源软件出现问题,影响范围无从确定,更谈不上风险控制。

DevOps 安全问题的维度

DevOps的落地使得软件交付的频率大幅度提升,这就进一步使得DevOps安全问题变得更加需要重视。那么,有哪些层面的安全问题需要考虑呢?

自研代码的安全

内部研发的代码,建议通过单元测试、静态扫描等基本手段进行安全合规性检查。自研代码发现问题可以给研发人员指定相应的任务去解决,因为这些代码都是自主可控,而开源代码缺陷基本不可能去修复,这是应对自研代码安全威胁的优势。自研代码经过扫描之后,可以知道目前的技术债务(Technical Debt)情况,防止技术债务不停增长。

技术债务类似于金融债务,它也会产生利息,这里的利息其实就是指由于鲁莽的设计决策导致需要在未来的开发中付出更多努力的后果。我们可以选择继续支付利息,也可以通过重构之前鲁莽的设计来将本金一次付清。虽然一次性付清本金需要代价,但却可以降低未来的利息。

这里写图片描述

开源的安全问题

传统开源安全威胁解决手段通常是成立开源技术专家组(委员会),列出目前已知的、企业必须重视的安全威胁列表,在上线前由安全组对交付件进行扫描,发现问题立即进行整改,然后再次反复此流程直到符合上线安全规范。从目前市场调查的情况来看,开源问题所带来的威胁遍布各行各业,且比例呈上升趋势。

这里写图片描述

从流程上来看,计划外工作量很大,并且在拔除一个安全威胁后,不清楚目前发现的这些威胁还是否影响到其他软件。造成这种的原因是交付件的依赖不清晰,导致不能反向排查安全问题的威胁。目前的一些工具(如Eclipse)提供了一些单个项目的依赖视图,但对于企业内部跨团队的分析依然显得能力不足。

这里写图片描述

解决策略

自研代码检查

目前比较流行的SonarQube提供了多种语言的基于静态规则的扫描,对用户的行为习惯侵入性极小,支持单元测试结果、代码重复率、技术债务等一系列非常有用的指标。很多企业在持续交付流水线中集成了SonarQube静态代码扫描的步骤。

在主流的二进制仓库Artifactory上,可以通过元数据将Sonar扫描的结果通过RestApi的方式记录在交付件上,这样在任何一个DevOps生命周期,都可以很清晰地知道这个交付件的静态质量,从而发布人员可以依据这些信息制订合理的质量关卡,方便运维人员筛选合适上线的交付件。

这里写图片描述

第三方开源安全检查

为避免在上线前紧急排查问题的窘境,必须将安全问题前置,即在构建甚至开发阶段发现问题并立即解决问题,再做构建或者测试。目前企业内部都是构建各自的私服,各个私服对于安全管控的能力参差不齐,必须有一种支持各种语言的第三方安全扫描的平台。

JFrog 公司提供的Artifactory + Xray 就是很好的一个组合。Artifactory提供了全语言的第三方依赖管理,Xray提供安全扫描,针对引入的任何第三方开源组件进行递归扫描,并提供可视化视图。

这里写图片描述

从上图中可以发现对于安全威胁给出了级别(高危、中级、低级),并且会由一些推荐的建议,方便及时作出调整。从这个层面解决了某一个软件引入的开源组件不清晰的问题,比Eclipse等工具的单一视图丰富很多。

对于开发工具,也可以有本地支持,比如在本地构建时从中央仓库获取依赖,并且触发第三方开源漏洞扫描的过程,立即反馈结果到开发者本地,开发者根据反馈决定是否提交代码到版本控制系统(或者内置策略阻止代码提交)。

这里写图片描述

对于反向排查安全威胁影响范围,Xray也有很好的支持,能够快速反向查询有哪些其他团队收到了该问题的威胁,这样可以及时通知相关团队进行修正并且不会有任何遗漏。值得一提的是,Xray还支持用户自定义的Issue,比如旧版本、性能问题等等,也可以据此快速反向排查影响范围。

这里写图片描述

统一的流程

关于DevOps安全,从流程角度来看,一个重要的痛点是流程割裂,即持续交付团队和安全团队难以协作实现真正的24小时持续运作的自动化流程。这个过程中涉及到很多规范的沟通协商,这些沟通依赖于人工来实现,距离如下图所示的理想流程相去甚远。

这里写图片描述

目前Xray支持统一的理想流程,帮助企业实现24小时动态监测所有外部依赖是否满足合规性。具体做法通常是在Jenkins上集成Artifactory,然后调用Artifactory 的 XrayScan 进行安全扫描。

stage('XrayScan') {
        def scanConfig = [
            'buildName'     : buildInfo.name,
            'buildNumber'   : buildInfo.number,
            'failBuild'     : true
        ]
        def scanResult = artiServer.xrayScan scanConfig
        echo scanResult as String
}

为了尽可能早地发现和解决研发依赖的安全问题,我们提供了IDE的插件,开发人员在引入依赖的时候,我们就会对其进行深度递归扫描,对相应安全的风险进行提示,确保开发人员可以有信心地引用第三方源。

这里写图片描述

总结

安全是一个永久的话题,我们只有日趋接近,无法真正到达。DevOps的逐渐落地使得软件交付频率达到了前所未有的速度,对于DevOps过程中的安全管控提出了更严峻的挑战,只有自动化的统一流程结合全面深入的安全扫描才能够实现对任何一个安全细节都兼顾到,并且可以快速了解安全问题的影响范围。在这方面Artifactory + Xray 方案显然已经走在了前面,除了自身的扫描能力,也自持BlackDuck、aqua、whitesource、snyk等一系列主流安全漏洞扫描工具,值得大家关注与试用。

猜你喜欢

转载自blog.csdn.net/afandaafandaafanda/article/details/82226576