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

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

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

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

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

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

　　2、从依赖层次来说npm、Maven和Ruby中的大多数依赖项都是间接依赖项间接依赖项中的漏洞占总体漏洞的 78%如下图二这样就使得1通过人工发现的依赖漏洞变得越困难因为漏洞藏得越深2漏洞发现后的修复工作需要更长时间。而根据过往经验在一天或更短的时间内解决高危或关键漏洞的基本是很困难。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　系统 Java + MySQL 完整实训代码，MVC三层架构组织，包含所有用到的图片资源以及数据库文件，大三上学期实训，注释很详细，按照阿里巴巴Java编程规范编写

　　CODING 在前两天的 Kubecon 2019 大会上发布了 CODING 2.0。这背后是 CODING 对研发

　　和研发团队组建的思考。从 CODING 成立以来，我们一直在探索“让开发更简单”的方式。把“让开发更简单”这个大愿景进行拆分，具体到可量化的产品目标上去，实际上是希望通过工具的形式，可以减轻开发过程中的重复劳动，提高软件交付的速度与质量。 云端开发的初心 最开始做 CODIN...

　　的上传主要可以通过三种方式来进行，结合Apache Maven Deploy Plugin进行操作、通过Nexus提供的UI界面进行或者通过Nexus提供的API进行操作，这篇文章对二进制

　　可能是一个包、一个二进制文件或者一个docker镜像。CI/CD 管道的主要功能之一是验证新功能是否能够部署到生产中。这是逐渐发生的，因为管道中的每一步本质上都是对该功能执行额外检查。...

　　较少的协同。然而现代的软件开发、部署运行越来越多的采用分布式架构、集群环境，这就要求开发人员同运维人员的技能出现了不要的交集，双方

　　紧密协作才能确保应用的正常运行。随着越来越多的企业IT部门的团队在项目中采用敏捷过程进行应用的迭代开发，

　　库的分类如下图所示： 1、临时软件包库A 企业内部的临时软件包库用于存储企业内部团队开发的通过部署流水线生成代码的所有软件包，例如每次处罚构建后产生的二进制包。该仓库中的二进制包不能直接部署到生产环境。如果存在存储空间的限制问题，则临时软件包库的内容可以被清理。 2、正式软件包库B 正式软件包库用于存储那些结果部署流水线验证，被确认能够且将要被发布到生产环境（或用户手中）的软件包。一旦经过确认，这些软件包就应该从临时软件产物库移动到正式产品库中。正式软件包库中所存储的软件包应该

　　生命周期阶段高层生命周期阶段划分工程阶段设计和综合活动可预测性小、规模小的群组驾驭再划分初始阶段细化阶段生产阶段构造、测试、实施活动可预测性大、规模也较大的群组驾驭再划分构造阶段移交阶段过程中的

　　在2018年10月份发布的Nexus 3.14版中提供了CleanUp功能，这对于使用Nexus的用户是一个原本早就该提供的功能，在这个功能中提供了对于长时间不使用的二进制

　　（获取任发科演讲完整PPT，请看完本文章底部信息） 讲师介绍 任发科，网名常新居士，曾任职唯品会、会唐网、亚马逊、ThoughtWorks，有十余年软件开发、架构和

　　工具:1. 版本控制工具: 现在软件开发中使用的版本控制工具很多，商业化的产品（费用昂贵的产品），如Rational ClearCase, Microsoft SourceSafe, 等等；这里简单介绍一个目前为止最流行的开源版本控制系统CVS(Concurrent Version System), 由于这篇文章不是讨论CVS的具体使用, 感兴趣的读者可

　　目录 前言 安装 启动服务 使用与配置 上传构件包 前言 伴随着团队的微服务越来越多，测试团队也重视版本

　　并要求 “所测即所得”，即SIT/UAT通过测试的二进制编译包即是上线部署包，而非重新拉取代码再打包。因此，要达到这个目标，开发这边

　　做两个事情： 1、把配置从程序包中解耦。这块不是这篇文章的重点，我后续会开另外一篇说一下如何通过使用携程开源的配置中心Apollo进行解耦。...

　　这个新理念的出现，是为了应对IT环境中普遍面临的一些挑战。敏捷的出现缩小了上图所示的第一个隔阂，也就是商业需求和开发之间的隔阂，有效的加快了产品开发的周期和效率。那么这无疑为运营团队增加了很多压力。于是上图中第二个隔阂，也就是开发和运维之间的隔阂

　　，同时无缝对接现有的标准化构建和发布工具。 关于 JFrog Artifactory JFrog Artifactory 是目前全球唯一的支持所有开发语言，功能最强大的二...

　　（英文Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。[1]外文名

　　工具，类似于 centos 下的 yum，可以很方便地进行安装/卸载/更新各种软件包，例如：nodejs, elasticsearch, kibana, mysql, mongodb 等等，可以用来快速搭建各种本地环境，程序员必备工具 安装 brew 首先要通过如下命令安装 brew /usr/bin/ruby -e $(curl -fsSL https...

　　库打造自动化补丁， 从手动补丁痛点、解决方案、实施过程、效果收益介绍整个实践过程，其中主要使用到的JENKINS插

　　器和Maven私有存储库。我们希望它是有用的，并且如果这些概念对您来说是新的（特别是如果您...

　　工具(SVN/Git)、代码构建工具(Maven/Gradle/Conan)、持续集成工具(Jenkins/GitLab-CI)、常用测试工具(UT/Sonar/JMeter)和常用部署工具(Ansible/Kubernetes) 1.1.2支持可视化作业流水线 支持手动配置(fre...