开源对软件的发展可以说具有深远的意义，它帮助我们共享成果，重复使用其他人开发的软件库，让我们能够专注于我们自己的创新，它推进了技术的快速发展。据不完全统计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 的安全管理特性，帮助企业轻松管理第三方漏洞，降低企业安全风险，避免含有漏洞的包上线到生产环境或客户环境中。
