开源对软件的发展可以说具有深远的意义,它帮助我们共享成果,重复使用其他人开发的软件库,让我们能够专注于我们自己的创新,它推进了技术的快速发展。据不完全统计78% 的企业都在使用开源,但是其中有多少企业关注第三方开园依赖的安全呢?其中仅有13% 将安全作为第一考虑因素。可喜的是仍然有50% 的企业将安全列为第二或第三位考虑因素,越来越多的公司开始重视第三方依赖的安全性。
想象我们交付的软件 Application 是一张饼,我们自己开发的代码仅占其中很小一部分,见下图:
而开源依赖并不等于是安全的,当然也不等于不安全,自2000年,仅有几家大厂贡献开源,其中有Apache, Linux, IBM, OpenSSL等,而到了2015年之后,任何人都在贡献开源社区,下图是主流软件库的发展 ,数量庞大
而我们在使用这些依赖的时候,一定要意识到:
1. 开源依赖往往很少有进行安全性测试的
2. 开源软件开发人源对安全意识普遍不高
3. 开源软件提供方没有多余的预算进行安全性测试
4. 黑客的主要攻击目标是开源,因为攻击一个,影响范围很大
让我们一起看几组第三方依赖安全的调查数据:
我们看到第三方依赖是存在非常大的安全隐患的,那我们应该如何做呢?不使用第三方依赖显然是不现实的,我们总结了四个步骤
1. 了解你都使用了哪些依赖
2. 删除你不需要的依赖
3. 查找并修复当前已知的漏洞
4. 持续监听新发现的漏洞,重复前三个步骤
相对简单,我们使用目前的依赖管理工具可以轻松做到,如maven的dependency tree
我们发现很对开发人员在维护依赖的时候,即使该依赖已经不适用,但不会删除,这显然会扩大黑客的攻击范围,因此我们需要定期检查删除不需要的依赖
第三步开始较为复杂,所幸已有很多开源组织提供了免费的漏洞库,如US-CERT,NVD,OSVDB等漏洞广播源,该类组织集中维护发现的已知漏洞,对外提供表述漏洞数据描述以及漏洞广播,为开源社区安全提供数据支持,有了漏洞数据源之后,判断我们的依赖中是否有依赖就简单了,我们仅需要根据我们的依赖包与漏洞数据库进行对比,就可以发现我们发布的应用中是否包含已知的漏洞,甚至有些开源组织会在漏洞库的基础上提供关于漏洞的修复建议,如 Synk.io,JFrog 和 Sync 合作贡献了一个漏洞数据源(JXray),其中包含主流漏洞数据源,包括刚才提到的几个,这样我们就可以对我们包含对漏洞进行漏洞升级。
我们知道漏洞是持续增长的,近几年每年平均都有900左右的新漏洞,我们需要持续监听这些新产生的漏洞,并与我们内部软件生命周期集成,与DevOps有机结合(DevSecOps),这显然需要一套平台或系统帮助我们系统的管理第三方漏洞安全,下面我们整理了一个漏洞扫描平台技术需求设计
能力分类 |
技术指标 |
指标需求描述 |
价值描述 |
扫描能力 |
多语言支持 |
支持主流语言漏洞扫描能力,如war,jar,docker,npm,python,debian,rpm等 |
统一监管企业各种技术栈的开发,漏洞风险与License合规分析,全面避免漏洞上线到生产环境 |
深度扫描能力 |
对二进制包深入逐层进行漏洞扫描,如war包中包含jar包 |
细粒度,深层次发现可能的漏洞,处理混合式软件发布体系,如Docker镜像,rpm等 | |
分析能力 |
正向依赖分析 |
能够分析定位出扫描目标漏洞包所在位置,标出具体哪个依赖出现漏洞 |
为企业快速定位问题及恢复提供数据依据 |
反向依赖分析 |
能够自动化分析出漏洞包的影响范围 |
快速分析漏洞问题的影响范围,加速线上漏洞的恢复,最大程度降低企业风险 以及评估风险成本 | |
漏洞库 |
开源漏洞数据集成 |
集成NVD等漏洞数据中心 |
针对第三方依赖包,对外部依赖包进行统一监管 |
商业漏洞数据集成 |
集成第三方商业漏洞工具能力,如 BlackDuck , WhiteSource 等 |
丰富漏洞数据库,最大程度降低第三方依赖漏洞风险 | |
本地漏洞数据中心 |
对第三方依赖或企业自研件添加自定义漏洞,如与Jira等缺陷管理系统的集成 |
针对企业内部构建的软件监管,避免团队内部漏洞包进一步扩散到其他团队 | |
其他漏洞扫描工具集成 |
通过API,自定义扩展对接第三方漏洞数据库,如病毒扫描工具集成 |
进一步丰富漏洞扫描范围,加强漏洞扫描能力,如木马病毒等 | |
告警 |
自定义告警规则 |
不同项目管理人员可以监听各自项目或软件制品 |
同时提供全局监管与分级监管机制,提高项目团队自主安全意识 |
告警通知,自动化 |
邮件通知及webhook支持, 发现漏洞可以与自动化任务集成,如高危漏洞触发回滚任务 |
提高企业漏洞快速相应能力,甚至漏洞自修复能力,降低企业风险 | |
生态,CI/CD |
作为CI/CD软件交付质量关卡 |
可以在软件交付流水线中集成,根据扫描结果,继续或阻止流水线运行 |
多维度加强软件交付质量,增加流水线质量关卡,保证软件交付质量 |
RestAPI 支持 |
提供RestFul方式对接漏洞扫描平台 |
方便企业与内部工具链集成 | |
可视化 |
漏洞分析报表 |
漏洞扫描趋势图 漏洞频率top图 |
可视化漏洞监管能力 提供决策依据 |
License 报表 |
License 分布图 License 兼容性分析图 |
可视化企业在用License 提供决策依据 |
JFrog Xray 是一个通用的漏洞扫描平台,可以满足我们对第三方漏洞安全管理的所有需求,其主要有以下几个特性
Java,Docker,Npm,Python,Ruby Gems,Nuget,Rpm,Debian等主流语言漏洞扫描,统一对所有开发技术栈进行安全管理
我们会深入分析软件的依赖及其传递依赖,甚至是Docker 镜像中的操作系统层,如Docker 镜像中ubuntu操作系统Layer中某一个debian包存在漏洞。下图是一个Docker 镜像中包含的一个基础maven jar包含漏洞的分析图
当我们监听到一个新的漏洞后,我们往往很难定为其被哪些项目依赖并试用,极为耗时,且总会有遗漏的情况出现,提高了企业损失的几率。
JFrog Xray 会根据所有收集到的依赖拓扑,进行反向依赖性分析,逐层找到所有包含漏洞包的上层应用。快速分析漏洞的影响范围,评估漏洞上线风险,指导企业进行漏洞修复
可以扩展与其他第三方漏洞数据平台集成,如Whitesource,Blackduck等,通过Xray 平台提供的Rest Api,甚至可以与企业自己漏洞数据源进行集成,形成企业安全的统一管理闭环。
我们可以在软件持续交付流水线中集成漏洞扫描能力,将安全机制集成进来,作为企业软件质量关卡中的一部分,当发现漏洞的时候,阻止漏洞包交付到生产环境,如下图
JFrog Xray 采用微服务架构设计,其中主要包含以下几个微服务,
l Server,主服务,UI
l Indexer,索引层,进行软件包索引
l Persist,持久层,存储漏洞及扫描结果
l Analysis,分析层,分析依赖拓扑及反向依赖,发现漏洞并告警
JFrog Xray同时支持高可用集群方式,针对企业级安全管理,提高漏洞扫描的效率及稳定性,并且与 JFrog Artifactory 通用二进制包管理系统原生集成,共同组成制品管理统一管理方案。
本次分享,介绍了在使用第三方依赖时的安全隐患,以及针对该类问题,我们应该如何管理第三方依赖的安全,同时介绍了JFrog Xray 的安全管理特性,帮助企业轻松管理第三方漏洞,降低企业安全风险,避免含有漏洞的包上线到生产环境或客户环境中。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。