着力点：接入、发现、防护、管理
下图是笔者总结的第三方组件流通图，可以看到组件的分发过程很零散：
接入
读者们可否有信息回答这个问题:"作为安全负责人，你知道公司使用和开发的应用中使用的开源组件都是最新的，已经安装了所有的重要安全补丁？"答案一定是窘迫的，如果连自己公司正在使用哪些软件，用什么开发的系统都不知道，何谈为其安装安全补丁呢？原因在于许多企业所用的开源组件并没有保存准确、全面、更新的资产清单，所以要做好组件安全，首先要有清晰的组件列表，并实时后台自动维护。不仅仅关注外部引入的代码，也要区分商业组件、开源组件和内部组件的版本和漏洞。
发现
漏洞
开源组件的漏洞和风险主要是通过邮件列表，github issues，nvd漏洞库进行的标注，所以最重要的工作总是发现项目中的依赖->找到对应的cve漏洞，值得一提的NVD 不仅在优先级分配上难免受到主观因素的影响，而且 CVE 中的数据报告、评分和可操作性都有可能存在严重滞后、缺失问题。
软件许可协议
除了安全问题外，license问题也需要关注。远有思科供应链的的教训，FSF状告Cisco以 Linksys品牌出售的各种产品违反了FSF拥有版权的程序许可条款，包括 GCC、GNU Binutils和 GNU C库，最终以思科任命一名董事以确保Linksys产品符合自由软件许可，以及思科向FSF进行未公开的财务捐助作为收场。详情参看https://www.fsf.org/licensing/2008-12-cisco-complaint。
近有Oracle索赔谷歌88 亿美元的大事件,背景是OpenJDK这个GPL项目的著作权属于Oracle。当时在谷歌供职的Joshua Bloch直接从OpenJDK复制了9行代码到谷歌的Android项目中。要点是Android项目没有按GPL兼容的方式授权，这就触犯了oracle的著作权。这个故事告诉我们，软件供应链的license安全不仅仅是简单的引入组件的问题，复制粘贴的代码片段也是需要关注的点（面向csdn复制代码的小伙瑟瑟发抖）。
为大家展示价值88亿美元的所谓违反软件协议的9行代码.....
代码语言：javascript复制private static void rangeCheck(int arrayLen, int fromIndex, int toIndex) { if (fromIndex > toIndex) throw new IllegalArgumentException("fromIndex(" fromIndex ") > toIndex(" toIndex ")"); if (fromIndex < 0) throw new ArrayIndexOutOfBoundsException(fromIndex); if (toIndex > arrayLen) throw new ArrayIndexOutOfBoundsException(toIndex); }未按照开源许可证约定使用开源组件会引发潜在的法律纠纷，其中最常见的是 GPL（GNU 通用公共许可证）许可证违规。懵懵懂懂的用户使用了不合规的license，会导致产品下降或被传染被迫开放自有商业产品的源代码。在《金融领域应用安全源代码安全检查产品测评方案》就特别提出：“送检产品关键核心模块的源代码开源比例原则上不超过30%，所使用的开源代码中不应包含GPL等强制开源的类型”，这说明国家对某些重要领域的风险防控提出了“自主可控”的要求。
防护
自动化流程必须工具先行，下图囊括了商业工具的能力：
Fossa在中国已经有代理，jfrog的产品是xray（和长亭的重名了），snyk势头不错，和github集成推广力度大。商业工具的产品名介绍在这里：
WhiteSource属于老牌产品，奈何在国内知名度低，工具实现了通过执行静态扫描来确定漏洞优先级的功能，这可以方便定位应用程序是否直接调用组件的易受攻击部分。这是巨大的亮点，有时候代码的package.json或者requirements.txt写了高危组件，但是实际代码没有引用。另一个时髦功能是通过创建pull request以升级到符合公司策略的版本来自动修复漏洞，极大的节省了修复闭环时间。
Synopsys就是收购coverity的公司，也收购了Black Duck Hub和Protecode SC产品，实现了二进制溯源功能，直接进行二进制文件扫描和报告功能也是亮点，有时候做组件分析面对一些历史dll，完全不知道从哪个cpp库里编译出来的。但是对于更复杂的许可证合规扫描，synopsys就必须单独使用另外的Black Duck Protex和Black Duck软件。笔者认为Synopsys的扫描速度快、可靠，提供了详细的修复建议，但误报率相对高。产品具有非常强大的策略管理、SDLC集成以及强大的漏洞管理能力，适合企业对SDLC团队中有严格的要求，并且有额外精力针对不同类型的应用程序制定不同的扫描策略，类似于航天，车联网行业应该会受到欢迎，在互联网行业就笨重了。
Snyk的目标是使开发人员不依赖专业的安全专家也能够修复漏洞，因此不仅可以通过创建pull request进行自动修复，还可以为开发人员提供一个调用图，其中显示了其直接依赖项所包含的间接依赖项和相关漏洞，以帮助开发人员理解为什么需要某些补丁。这个功能十分重要，因为开发人员ctrf f查找pom.xml后，说我没有fastjson，实际上是可能com.alibaba.otter这个包，引入了fastjson。一般用mvn dependency:tree命令才能梳理清楚。
GitLab从2017年开始提供安全产品，现在除了二进制SCA之外，还提供静态和动态分析。GitLab倾向于不像sonar一样扫描出问题就通过“质量门槛”中断构建。相反是推崇使用安全reviewer的角色， 通过代码审查解决安全漏洞。我个人很喜欢它的理念--将安全前置，但是这样面向开发人员的特性会让安全人员工作量增大。例如在gitlab容许开发人员忽略任何漏洞，不管实际是不是高危严重的。这迫使安全人员仔细标记已被忽略的漏洞是不是误报。鱼与熊掌不可兼得，在效率和安全之间必须权衡。
还有几款蓬勃发展的开源或共享工具，读者部署起来也能为企业做软件成分分析。
首先推荐可以使用dependency check，支持各种语言，持续社区更新，有命令行、docker部署、丰富的报告格式。原理是基于开源的 NVD 开源漏洞数据库来监测安全漏洞的，缺点是基于文件名来使用Lucene分词匹配cpe不准确，这个环节引入一部分误报的问题。
另外一款工具是dependency track，是owasp新出的工具，界面较好，方便管理。
SAP公司开源了Java和Python SCA 工具，提供静态代码安全性测试功能，以后有时间会为读者们重点介绍。
对于node应用，有npm audit fix命令可以自动升级版本，原理是通过nodesecurity.io的接口查询漏洞，详情参看https://www.npmjs.com/solutions/security-compliance。
如果基于github，那么有snyk.io，git alert、lgtm、sonar oss免费服务可以使用。另外gitlab企业版，也直接提供了安全功能。
管理
管理层面要先行，想一下做到完全的安全是行不通的，没有管理的支持是说不通的。需要的安全管理参与范畴有：
•成立开源治理团队，包括管理者、法务、安全专家、研发负责人，梳理重点组件，推动大面积的升级版本•建立第三方软件引入制度，审核组件的历史漏洞、预估业务解耦风险，选型备用组件。•面向研发工程师进行政策、法规、案例的培训宣传。•聘请知识产权律师处理软件法律冲突，审核并购公司的合规性。•采购和部署自动化工具发现软件依赖的使用。
笔者据此勾勒了以下的支撑框架模型：
做组件分析的时机
在企业建设黑盒，白盒成熟阶段之后，如果你打算立项做软件成分分析的任务就要准备好分锅，是的，就是这样--你发现的低版本组件也许永远也不会形成漏洞，开发人员凭什么去费心修复？所以要提前沟通好职责：业务开发人员负责排查和升级日常的安全工作，而安全人员从更高的维度把控安全问题，例如建立更好的安全流程，给出专业的修复建议。本文最后要提醒读者们使用开源方案的优劣之处：当然优点除了免费，还有：
1.自动可靠检测和对应到手工无法找到的已知开源漏洞2.提供正在使用的开源软件的详细溯源3.可以实时管理业界新发现的漏洞4.相当于聚合全球开源社区的安全测试能力5.可以在整个SDLC中使用 使用开源方案有五个难点需要动手解决：1.不处理公司内部开发的代码。公司自主开发的代码，没有纳入漏洞管理范围，需要适配开发。2.不解决应用程序配置漏洞。如spring actuator组件是否存在漏洞，依赖于各个版本的不同配置。3.解决方案的完整性和有效性各不相同。由于漏洞批量信息的有效性和时间性，需要有经验的安全专家依据实际情况，处理妥善的漏洞修复方案。4.不能解决容器、镜像、软件所部署环境的安全问题。5.最重要的问题：如果你使用了免费软件，老板会认为你也是免费的，安全是不值得花钱投入的。
如果读者任何所在组织有必要做软件供应链安全，也接受投入资源做这件事的性价比，那从现在就行动吧！
