为什么我们需要制品管理？

一、什么是制品与制品库？



制品是指由源码编译打包生成的二进制文件，不同的开发语言对应着不同格式的二进制文件，这些二进制通常可以直接运行在服务器上。



制品库用来统一管理不同格式的软件制品。 除了基本的存储功能，还提供了版本控制、访问控制、安全扫描、依赖分析等重要功能，是一种企业处理软件开发过程中产生的所有包类型的标准化方式。





二、哪里痛？

概况：

• 第三方依赖包下载管理混乱，没有准入管控；

• 交付包使用FTP或者SVN进行管理，管理粒度相对较粗；

• 第三方依赖包的安全风险管理形同虚设，或者滞后；

• 由于受到监管约束，一键部署是不可能任务，跨网段的包交付智能依赖于手工拷贝；

• 团队内部搭建的制品库是单点的，缺乏集群部署；

• 因为没有统一的制品库，存在重复建设的问题；维护成本高，或者说目前根本就没有维护；

• 针对引入进来的第三组件没有进行组件扫描，极易引入漏洞；



安全风险：



从底层操作系统、到容器、开源脚手架、再到三方组件，我们在系统开发过程中引用着越来越多的开源组件，研发效率确实是提升上去了，但是带来的安全风险是越来越高。从以下图可以看出来，我们自己写的代码量只占了0.1%，但对应的第三方依赖却占了99.9%。因此，对于制品的管理（包括版本管理、风险管理）就尤其显得重要。另外，已知30%的Docker镜像，14%的npm package，59%的maven中央库都还包含已知漏洞，而且漏洞平均修复周期约为2年。



组件准入 ：



拿maven举例子吧，程序员只需在pom文件配一个新依赖就可直接从中央库上拉取一个不知名的三方包，当然一般有点血性的同学还是会拉取高知名度的三方包；而且最要命的是你根本都不知道整个研发团队的组件引用情况是怎样的，因此你的整体风险评估根本无法下手做。根据2018年synk发布的信息安全状态报告，我可以从以下两个维度去告诉你风险在哪里。



1、从趋势上来说，maven中央库新增漏洞在2018年增长了27%，npm则增长了47%（如下图一）。随着我们工程的依赖越多，我们引入漏洞的风险几率也是正比增加的； 



2、从依赖层次来说，npm、Maven和Ruby中的大多数依赖项都是间接依赖项，间接依赖项中的漏洞占总体漏洞的 78%（如下图二），这样就使得

• 通过人工发现的依赖漏洞变得越困难，因为漏洞藏得越深；

• 漏洞发现后的修复工作需要更长时间。而根据过往经验，在一天或更短的时间内解决高危或关键漏洞的基本是很困难。





版本溯源 ：



从下图可以看出来【制品管理】就是我们整个DevOps流水线的枢纽。首先，它控制着部署包的按配置规则自动分发部署，可以避免人工因一时抽风带来的版本问题；其次，它是可以设成自动化，让分发部署变成一种自助式服务；具体可以问问你旁边的同事，你问问他们更愿意用APP、ATM机还是人工柜台去转账，道理就不言自明。 

• 如果版本发布错误怎么办？如何追溯？

• 如果版本引入了安全漏洞怎么办？推到重来，业务方允许吗？

• 等着紧急发版测试，手工传包的同事逛街去了怎么办？估计开发要被拉去祭天得了。



只有引入了制品库，才能真正实践Once Integration，Run anytime anywhere，才能真正无缝实现所测即所部署。



三、如何管控？

安全左移



目前由于我们的第三方组件扫描都是滞后的，当我们的版本基本上到了SIT或UAT尾声才交付给信息安全进行组件扫描。如果这个时候扫描出一些第三方组件有严重的安全漏洞。那还要不要投产？如果继续投，我们是求神拜佛保佑漏洞不被发现且利用吗？如果修复后再脱产，因为部分可能涉及到底层框架的改动（如Spring、Struts2这类），如果要在临近投产的这么短时间内完成改造首先不现实，其次是高风险，同时也有可能会导致项目延期。



那应该要怎么办呢？对了，进行安全左移。如果要实现安全左移，我觉得需要从策略、流程、工具、培训四个维度开展。



1、要把安全策略从被动转为主动，把组件扫描前置到开发过程中；传统的做法是在UAT快结束时才把源码交付给安全部门进行一系列的漏扫或者渗透测试；这样可以理解，毕竟可以节省安全部门本来就人手不足的现状。但是我觉得既然有人手不足的现状，我们更要想办法从工具层面给开发人员赋能（如下图一）;



2、 质量保证一直是软件开发生命周期的一部分。但是在过去，安全防护从未包括在软件质量中，至少没有体现在开发及测试阶段。因此，就好像我们设置SIT准入一样，我们对于源码的交付也要设置安全准入（如组件扫描中的CVE漏洞不能出现中高危）；



3、上面说到的两点，如何给开发人员赋能当然也是需要工具的支撑（因为在先进这么多技术栈、依赖引用嵌套那么复杂的情况下如果单靠人就好像大海捞针一样）。目前了解到的是JFrog Xray可以支持类似的功能，它能够在开发IDE端侦听POM文件的依赖及依赖传递的变化，一旦POM文件发生任何变化，Xray就可以对该工程的所有的依赖进行深度递归扫描，将扫描结果呈现在IDE上（如下图二），这样就可以让开发马上收到关于关于该新引进组件的安全情况反馈（这是不是也是很"DevOps"呢）。



4、安全左移的最后一步，就是确保作为编码主体的人员在开发初期便创建安全的代码。DevOps服务提供商GitLab最近发布的一项调查进一步强调了这一点，其中发现有 70% 的程序员应该编写安全的代码，但只有 25% 认为所在企业的安全实践“还不错”。因此，信息安全开发层面的培训还是的跟上。



被动转主动：



依赖递归扫描：



建立安全白名单制度



这里借用JFrog的一些部署方案（如下图），大致解决方案如下：



1. 在外网建立安全漏洞库，开源的可以从NVD、VnlrDB定时更新，商业可以购买synk的服务；同步建设有白名单制度用于特殊包申请，统一整合到整体的信任规则库；

2. 在DMZ区建设DMZ代理公网镜像仓库，根据安全漏洞库的规则过滤从公网上拉取第三方包。如果第三方包是被扫描到漏洞的，则禁止拉取到内网的制品仓库。

使用制品库进行组件版本溯源 



传统制品仓库无法管理构建过程，因此对构建过程中的依赖也无法统一管理，该部署包具体含有多少个依赖包，依赖包的二级依赖包又有什么包，完全是两眼一抹黑。因此，这时候就需要对二进制制品的所有内容有一个清晰的视图，它需要提供以下功能：



1. 正反向依赖：能够清楚知道应用程序引入的依赖组件清单，同时能够知道某个依赖组件的使用范围。 

2. 依赖可用性：能够通过人工识别，工具扫描等方式判断依赖组件的可用性

3. 依赖控制：当某个依赖组件不可用时能够根据组件的严重级别实施不同的控制策略，控制阶段就是上面提到的『编译阶段』

4. 依赖知识库：沉淀依赖组件知识库，能够记录依赖组件的基本信息，问题记录，黑名单，白名单。当开发人员在引入组件时就能知道依赖组件是否可用，而不需要到后面的阶段在被拦截。

5. 依赖度量：度量依赖组件使用情况，能够通过统计图表的展现形式统计组件的最多使用，以及分布，问题版本统计，问题版本产生的问题统计，以及特定时间范围内的趋势。



据前期的使用调研（当然可能也不全面），Nexus没有针对编译包的整个依赖管理及正反向解析功能，而Artifactory 将构建任务、构建历史及依赖信息有条理地管理起来，方便对正反向依赖进行追踪，能够清晰了解安全威胁传递的路径、影响范围(项目、团队、产品)等信息，能够为开发人员提供可视化的能力。（以下为Artifactory的依赖分析的一个依赖路径概念图）



四、有哪些工具？



制品库比较出名的有Nexus和Artifactory，当然现在大厂目前推出的DevOps平台也集成了类似的功能（如阿里云效、CODING、京东的JCI）；



关于Nexus OSS Repository

具体的安装使用请参考我以前的一篇文章：https://blog.csdn.net/justyman/article/details/89279395



关于Arifactory

目前是有免费开源版，后面在另外一篇文章介绍具体的用法。