如何应对开源组件⻛险？软件成分安全分析（SCA）能力的建设与演进

跟着 DevSecOps 概念的推行，以及云原生安全概念的快速遍及，研制安全和操作环境安全现在现已变成了近几年十分热的词汇。现在，在系统研制的进程中，开源组件引进的份额越来越高，所以在开源软件办理层面安悉数分需求投入更多的精力。但因为前期技能债的问题，许多企业界部在整个研制流程中对运用了哪些开源组件、这些开源组件或许存在哪些严峻的安全隐患等相关的问题，几乎是没有任何才干去进行收敛，多年前的 SCA（Software Composition Analysis 软件成分剖析）技能又重出江湖，变成该范畴⻛险办理的一个“神器”。本文首要谈论如何运用 SCA 技能完结对开源组件⻛险办理相关才干的建造与落地，期望给咱们以启发或许帮忙。

1. 前言

SCA 概念呈现其实好久了。简略来说，便是针对现有的软件系统生成粒度十分细的 SBOM（Software Bill of Materials 软件物料单）清单，然后经过⻛险数据去匹配有没有存在⻛险组件被引用。现在，市面上比较出色的商业产品包含 Synopsys 的 Blackduck 、Snyk 的 SCA 、HP 的 Fortify SCA 等，开源产品包含国内悬镜的 OpenSCA 。

可是，经过对这些产品调研和剖析后咱们发现，它们因为比方⻛险数据库完好度、与现有研制流程耦合程度、功用和社区支撑不完好等原因，不能很好地融入企业界部的研制流程，可是在企业界部，这一部分才干关于 SDL 作业而言，又是不可或缺的一种才干。所以，企业界部的信息安全团队需求结合事务团队的需求，安全团队本身关于⻛险的了解，企业界部的研制流程现状，以及现有的技能与数据才干、运用本钱和 ROI 等现状和问题进行归纳考虑，打造归于自己的 SCA 才干，然后帮忙事务团队多、快、好、省地处理软件供应链层面上的信息安全问题，安全团队也可以更好地对组件⻛险问题完结全局的办理。

从上述的内容可以得知，在企业界部建造 SCA 才干的进程中，会涉及到许多的产品和运营方面的问题，比方跨部⻔协作、系统安稳性、事务和安悉数⻔关于⻛险的定义不一起等问题。本文首要介绍 SCA 才干在企业界部实践落地的进程、遇到的问题以及对 SCA 技能的观点和展望，期望可以为业界同仁供给一个可以参阅的处理计划和范本。

2. 安全视⻆下的研制⻛险

从企业界部的信息安全团队的视角看来，企业界部在整个研制流程傍边遇到的⻛险点仍是比较多的，经过关于各种进犯面的整理和剖析之后，咱们在研制流程中被常常提及的⻛险首要包含以下通用缝隙危险、供应链相关的危险以及过期维护的组件等三类，下文将逐个打开。

2.1 通用缝隙⻛险

在组件安全层面上，首要遇到的问题、也是最简略发现的问题便是缝隙问题，它形成的影响也十分直观，可以导致系统因为歹意运用呈现非预期的问题，进一步损坏系统的完好性和可用性。依据 2021 年 Synopsys 放出的软件供应链相关的数据显现，开源代码库房中至少存在一个缝隙的库房占全体开源库房的份额，从 2016 年的 67% 上升到了 84%；至少存在一个高危缝隙的代码库房占悉数库房的份额，从 2016 年的 53% 上升到了 60%；最高的时分是 2017 年，这一数字增加到了 77%。

而依据 2020 年 Snyk 发布的另一份开源组件与供应链安全的报告显现，缝隙的数量依然需求提高警惕，XSS 缝隙依然占有数量榜首，紧随其后的是命令履行类缝隙，这些缝隙会严峻影响系统的安稳性。

在上述所罗列出来的⻛险傍边，当注意力集中到歹意包（Malicious Packages）上时，咱们可以发现该类型的⻛险是 2019 年度上升幅度最快的要挟之一，这也引出了下面的问题。也便是软件供应链相关的⻛险。

2.2 供应链相关的⻛险

开源组件的出产-构建-发布进程，跟企业界部惯例的系统研制上线的流程基本上是一起的，简略来说可以笼统成下图中的样子：

开源软件作者完结代码编写后 Push 到源代码办理渠道（ 包含GitHub、码云、Gitlab私服渠道）等；然后在CI/CD 渠道上建议构建编译打包的流程，在这个进程中，CI/CD 渠道会从组件依靠渠道（Sonatype Nexus私服或是 MVNRepository 官方源）上获取需求依靠的包；在 CI/CD 渠道完结打包/镜像封装进程后，经过项目分发渠道分发到出产环境上，更为现代的方法是直接拉取 Docker 镜像做布置，完结系统的上线。这个进程看似简略，可是实践上环节仍是有不少的，咱们把每个环节拆解来看，实践上每个环节都是会有许多⻛险的，如下图所示：

• IDE 插件投毒 ：为了更高功率地开发软件，开发人员往往会在自己的 IDE 傍边引进各种各样的插件来提升自己的开发体验与功率。这是一件看起来十分正常的作业，可是软件开发人员往往没有满意的安全意识，导致自己的 IDE 中或许会安装了一些有问题的组件，乃至 IDE 本身也呈现了供应链“投毒”的状况，这种 Case 数不胜数。比较出名的是在 2021 年 5 月份， Snyk 发表的一份安全报告中显现进犯者在 VSCode 的插件商场建议了“投毒”行为，一些有问题的扩展是“LaTeX Workshop”、“Rainbow Fart”、“在默许浏览器中打开”和“Instant Markdown”，一切这些有问题的扩展累计安装了大约 200 万次，此次作业所形成的影响也对错常广泛的。
• 提交缺点代码 ：在软件开发环节，开发人员因为水平、安全意识的许多原因，往往会在开发进程中引进缝隙，这本身是一件十分正常的作业。但关于开源软件而言，因为几乎一切人都可以向开源项目提交代码，而且经过审阅后就可以 Merge 进项目，所以总会有不怀好意的人成心引进有问题的代码，比较典型的 Case 是 2021 年 4 月，明尼苏达大学 Kangjie Lu教授带领的研讨团队因成心向 Linux引进缝隙，导致整所大学被禁止参与 Linux 内核开发。抛开品德问题不谈，这种⻛险实践上有或许因为审阅的忽略导致⻛险直接被引进。
• 源代码渠道被攻陷 ：其实 Git 渠道本身因为维护不当，也有极大的概率被攻陷。尽管说攻陷 GitHub 这种渠道本身不太现实，可是有许多开源项目都是自己搭设的 Git 渠道，再加上一些众所周知的原因，Git 渠道本身缺少维护是一件较大约率发生的作业。在 2021 年 3 月，PHP 的官方 Git 就遇到了相似的 Case，因为 PHP 官方团队在 git.php.net服务器上维护的 php-src Git 库房中被推送了两个歹意提交。进犯者在上游提交了一个奥秘的改动，称其正在“修正排版”，伪装这是一个小的排版更正，而且伪造签名，让人认为这些提交是由已知的 PHP 开发者和维护者 Rasmus Lerdorf 和 Nikita Popov 完结的。所以 Git 渠道的安全维护本身也是需求被提高注重的。
• 代码 branch 被篡改导致打包成果不一起 ：因为开源项意图 Git 库房是向一切人敞开的，有些进犯者会尝试新建不同的 branch 植入代码然后进行发布，尽管编译往后的包带有 CI/CD 渠道的签名，可是依旧会引发严峻的安全隐患。早在 2019 年的 DEFCON 会议上，就有安全研讨员就发现了 WebMin 的 1 .890 在默许装备中存在了一个很严峻的高危缝隙，1. 882 到 1.921 版别的 WebMin 会遭到该缝隙影响。但奇怪的是，从 GitHub 上下载的版别却未遭到影响，影响规模仅限于从 SourceForge 下载的特定版别的 WebMin，后来经过查询后发现，是代码库房没有增加分支维护机制，从动导致呈现问题，引发了此类的安全⻛险。
• CI/CD 系统被攻陷 ：研制前期，假如咱们完结了代码完好性检测的话，假如流程没有被篡改或许构建渠道都运转正常的话，一般状况下，呈现问题的几率很低。但假如 CI/CD 渠道和前面的 Git 相同被歹意篡改或是损坏，也会呈现安全隐患，SolarWind 作业便是因为这一原因导致的，进犯者在 CI/CD 进程中嵌入了“后⻔”，经过了签名校验，再经过 OTA 分发补丁之后，导致呈现了让人震动的供应链进犯作业。
• 不安全组件引进 ：在依靠引进的进程中，假如引进了有问题的组件，则适当于引进了⻛险，这也是现在最典型的供应链进犯手法，经过咱们对各个源的安全查询和剖析后发现，“投毒”的重灾区在 Python 和 NodeJS 技能栈（一个原因是因为前端的“挖矿”现已很老练，简略被黑产滥用，别的一个原因是 Python 的机器学习库适当丰厚，加上机器学习配套的核算环境功用强悍，导致“挖矿”的收益会比入侵普通 IDC 主机更高）。因为比方较多，这儿就不一一列举了。
• 外部 CI/CD 流程构建 ：因为 CI/CD 渠道有时分不能满意需求，或开发者出于其他要素考量，会运用非官方的 CI/CD 进行构建，而是自己上传打包好的 JAR 或许 Docker 镜像来布置，更有甚者会一起把打包东西链和源代码一同打包上传到容器实例，然后本地打包（极端状况下，有些“小可爱”的依靠库房都是自己树立的 Sonatype Nexus 源办理系统）。因为许多开源软件的运用者不会去做 CI/CD 的签名校验（比方说简略匹配下 Hash ），导致这类进犯时有发生。早在 2008 年的时分，亚利桑那大学的一个研讨团队就对包含 APT、YUM 在内的 Linux 包办理渠道进行了剖析和研讨，发现绝大多数源都不会对包进行校验，这些包跟着分发，形成的安全问题也越来越广泛。
• 直接布置有问题的包 ：有些打包好的制品在运用的时分，因为没有做校验和查看，导致或许会布置一些有问题的包，最典型的比方是 Sonatype 之前发表的 Web-Broserify 包的作业，尽管这个包是运用了数百个合法软件开发的，但它会对搜集方针系统的主机信息进行侦查，所以形成了适当大规模的影响。

2.3 过维护期的组件

在实践的出产环境中，有许多的开发者运用的运转时版别、组件版别以及 CI/CD 渠道版别都是现已好久未更新的。当然，站在安全的⻆度上讲，安全团队期望一切的系统都用上最新版别的组件和中间件，可是事实状况是，根据事务本身的规划迭代，或许因为大版别改动较多简略引发兼容性问题，然后导致晋级搬迁本钱过高等许多原因，使得落地这件作业就变的不是那么简略。为了让安全性和易用性达到平衡，许多企业界部往往会进行妥协，经过其他手法收敛进犯面而且树立旁路的感知系统，来确保安全问题，也可以及时发现和止损。可是⻓久看来，引进过期版别的组件会引发许多的问题：

• 维保问题 ：因为开源社区的人力和精力有限，往往只能维护几个比较首要的版别（相似于操作系统中的 LTS 版别，即 Long-Term Support，⻓期支撑版别是有社区的⻓期支撑的，可对错 LTS 版别则没有），所以一旦运用过期好久的版别，在安全更新这一部分就会呈现严峻的断层现象。假如呈现了高危缝隙，官方不维护，要么便是自己编写补丁修正，要么便是晋级版别，达到“⻓痛不如短痛”的效果，要么便是像一颗定时炸弹相同放在那里不管不问，请求进犯者或许“蓝军”的运气差一点。
• 安全基线不完好 ：跟着信息安全技能的开展和内生安全的推进，版别越新的安全组件往往会 Secure By Design，让研制安全的要求贯穿整个研制规划流程。但前期因为技能、思路、进犯面的局限性，这一部分作业往往做了跟没做相同。感受特别深的两个比方，一个是前几年 APT 安排运用的一个 Office 的 0day 缝隙，瞄准的是 Office 中一个年久失修的组件，这个组件或许根本连基本的 GS（栈维护）、DEP（数据区不可履行）、ASLR（内存地址随机化）等现代的代码安全缓解机制都没有运用。熟悉虚拟化缝隙挖掘的同学们或许知道，QEMU/KVM 环境中比较大的一个进犯面是 QEMU 模拟出来的驱动程序，因为 QEMU/KVM 模拟的驱动许多都是老旧版别，所以会存在许多现代化的安全缓解技能没有运用到这些驱动上面，然后引进了进犯面。其实，在开源软件的运用进程中也存在相似的状况，咱们统称为“运用不具备完好安全基线的开源软件”。
• 未经过严谨的安全测试 ：现在的许多开源组件供给商，比方 Sonatype 会在分发前进行必定程度的安全检测，可是时刻越早，检测的规模越小。换句话说便是，组件越老呈现的问题越多。究竟之前不像现在相同有好用的安全产品和安全思路，乃至开发的流程也没有嵌入安全要求。而这样就会导致许多时分，新发布的版别在修正了一个缝隙的一起又引进了一个更大的缝隙，导致⻛险越来越大，越来越不可控。

综上所述，从安全团队的视⻆看来，⻛险无处不在。可是在一个非安全事务的安全公司，往往事务关于⻛险的了解和要求，跟安全团队的观点或许大相迳庭。

3. 事务视⻆下的安全研制⻛险

实践上在事务同学看来，他们也十分注重信息安全的相关作业，有些公司的事务技能团队乃至树立了专⻔的安全团队来帮忙研制同学处理安全相关的问题。可⻅事务不是排挤乃至抵抗安全作业，而是缺少合理和可操作的安全辅导，从而导致事务同学不知道产品有什么⻛险。在实践的组件⻛险修正进程中，咱们也收到了许多事务同学的反应和吐槽。总结起来首要有以下几种状况：

• 兼容性问题 ：在推进以版别晋级为首要收敛手法的⻛险修正中，事务提出最多质疑的往往是兼容性问题，究竟安稳性关于事务来说十分重要。所以一般状况下，咱们在推进晋级时，往往会推送安全保险且安稳性最高的修正版别，作为首要的晋级版别。但这种问题不是个例，每次遇到此类型推修的时分，事务都会问到相似问题。考虑到本文篇幅原因，这儿就不再进行打开。
• 安全版别的问题 ：跟上一个问题相似，事务同学在引进组件时也会考虑安全性的问题，但事务同学因为缺少一些安全常识，导致自己关于“安全版别“的判断存在必定的收支，所以事务同学会把这个问题抛给安全同学。可是安全同学很难100%正确回答这个问题，因为开源组件太多，绝大多数企业不能像Google、微软相同把市面上一切的组件安全性全都剖析一遍，所以一般只能现用现查。一来一去，会拉低这一部分的质量和功率。所以这一部分需求也是重要且急切的。
• 寻求“必定安全” ：有些事务同学也会直接问，究竟该怎么做，才干安全地运用各种组件？话虽直接，可是可以体现出背后的问题：安全的规范和评价规范不行透明。让安全问题可量化，而且寻求规范透明也对错常急切的作业，考虑到这更像是运营层面的问题，在此也不打开叙说了。
• 合规问题 ：许多事务因不了解开源协议，导致违反了开源协议的束缚，引发了法务或许常识产权问题。

从实践状况来看，事务同学并不排挤做安全作业，许多时分是因为缺少一个有用的机制，咱们需求告知他们引进的软件依靠是否安全，需求完结那些操作和装备才干让开源组件用起来愈加安全。作为安全工程师，咱们需求站在事务的视角去设身处地地想想，这些问题是不是真的不可以被处理。因为事务和安全两边都有关于组件安全相关的需求，刚好 SCA 这项技能可以很好地满意事务和本身的需求，所以在整个 SCA 建造的进程中，咱们需求不断去挖掘这些需求。

4. SCA 建造的进程

其实，SCA 并不是一项很先进的技能，只是在现代的研制进程中跟着流程的规范化、组件的丰厚化、开源社区的活泼以及开发本钱的降低一级许多原因，使得一个项目中纯自己写的代码占整个项目中悉数代码的份额变得越来越低了。也就意味着供应链问题发生的影响会越来越大，跟着 DevSecOps 的火爆，就重新带火了 SCA 这一传统的技能。

依据许多企业界部的实践，以及业界关于 SCA 技能的了解，咱们认为 SCA 比较中心的功用首要包含以下几点：

• 软件财物的透视 ：企业界部需求对一切的运用系统引用了哪些组件这件作业有着十分明晰的认知，在考虑尽量多的状况下，尽量掩盖绝大多数的场景（事务运用系统、Hadoop 作业等数据服务、Puppet 等运维服务等），而且研讨它们的开发流程，剖析哪些阶段可以引进 SCA 才干做⻛险发现。
• ⻛险数据的发现 ：现在是一个数据爆破的年代，安全团队每天需求重视的安全⻛险信息来历五花八⻔，可是需求尽或许多地去搜集⻛险相关的数据，而且做上下文整合，使之可以自动化和半自动化地运营起来。但仔细想一下，除了寻求⻛险数量，能否更进一步寻求更强的实效性，达到先下手为强的效果？经过企业界部多年的安全要挟情报才干建造，一起寻求实效性和可用性的两层 SLA 是可行的。除此之外，需求重视的⻛险，不能仅仅局限于缝隙和“投毒”这两个场景，还需求对开源软件的基线信息进行搜集。
• ⻛险与财物相关根底设施的建造：前面的两个方向是数据维度的需求，考虑 SCA 落地不单单是信息安悉数⻔的作业，在实践落地进程中，还需求跟事务的质量功率团队、运维团队树立良性的互动机制，才干让安全才干深化到事务，所以需求建造相关的根底设施去完结中心 APIs 才干的建造，对事务进行赋能。尽管听上去很简略，但实践上开发的东⻄或许是 UDF 函数，也或许是某些剖析服务的插件，乃至或许是 CEP（Complex Event Process 复杂作业处理，一种运用于实时核算的剖析技能）的规矩。
• 可视化相关需求 ：既然有了⻛险，安全团队及事务相关团队的同学除了自己知道之外，还需求让负责系统开发相关同学也了解⻛险的存在，而且要及时给出处理计划，辅导事务完结修正，一起安全团队也需求经过获取运营数据，了解⻛险的修正进展。

正所谓“罗⻢不是一日建成的”。尽管现在确认了 SCA 建造需求和建造的方向，但落地依然需求分阶段完结。正如建造其他的安全子系统相同，安全团队需求按照从根底数据/SOP 开始建造，然后是渠道化系统化的建造，从而完结整个 SCA 才干的落地。所以在实践操作进程中，应该将全体建造分红三个阶段进行：

• 第一阶段 ：数据盘点与搜集，在项目建造前期，信息安全团队应当跟企业界部的根底架构相关的团队，完结企业界部根底组件的数据财物盘点，旨在从根底技能和信息安全的视⻆完结对研制技能栈、研制流程链路的摸排，在适宜的方位进行数据卡点，然后获取相关数据，完结对财物数据的搜集。另一方面，信息安悉数⻔在现有的要挟情报经历和数据上，对组件数据进行数据封装和整合，树立一个单独的开源组件⻛险数据库，旨在搜集来自于全量互联网上发表的⻛险，便利与后面的财物数据进行联动。
• 第二阶段 ：SOP（Standard Operating Procedure，规范运营流程）和概念验证建造，信息安全团队经过自己的缝隙修正经历进行 SOP 的固化，经过不断地调优，完结一个通用的缝隙修正 SOP，经过实践的演练和概念验证（PoC，即Proof-of-Concept）证明，该 SOP 可以在现有的技能条件下很好地完结⻛险修正这一部分作业。一起结合 SOP，对之前搜集的财物数据和⻛险数据进行查漏补缺，完结对数据和数据链路的校验作业，确保系统高可用。在这个阶段，SCA 的服务供给方需求敞开部分的中心 API 给部分事务的质量功率团队，帮忙他们进行测试并搜集反应，让其融入到自己的⻛险办理环节。
• 第三阶段 ：渠道化及配套安稳作业的建造，当 SOP 开始成型而且完结了概念验证之后，应当需求建造对应的渠道和子系统，让这一部分作业脱离手动核算，使其接近 100% 线上化。得益于内部 SOC 的模块化规划，可以在现有的渠道上轻松构建出 SCA 相关的子系统，完结才干的数据。针对终端用户可视化⻛险这一问题，SCA 子系统会供给中心的 APIs 给面向研制同学端的 SOC 渠道完结⻛险信息的同步。为了确保服务的高可用，后续还会建造配套的数据链路查看机制，不断完善数据的可用性。

一些比较重要的作业如上图所示。三个阶段完结之后，SCA 的才干大约就建造好了，但在建造进程中，安全团队需求考虑许多东⻄。假如说安全厂商的安全产品和服务可以被认为是问题处理的“分子”的话，甲方安全团队的作业更多的是做大做全的“分母”，要把各种状况都考虑得面面俱到，才干确保⻛险不被遗失。

首要，在财物建造方面，企业界部的安全团队、质量功率团队以及数据渠道团队等存在研制流程的技能团队，需求合作完结自己所辖的 CI/CD 系统数据和数据服务构建数据的搜集作业，一起也为 IDE 插件团队供给 SCA 的 API，完结从代码开发环节到运用上线环节的数据搜集。

可是，咱们在运用这一部分数据之后发现了许多问题，除开数据本身质量和精确度不谈（不谈不代表重要，相反这一部分很重要，后面会介绍这一部分），按照前面提到的场景，还会有许多额定场景。比方说，事务在灰度了一部分之后就忘掉了还没灰度完，导致一个服务下面只修正了一部分机器；再比方有许多“小可爱”会绕过企业本身的 CI/CD 流程进行布置操作（有些乃至仍是自己人）。为了考虑到这些破例的状况，咱们应该从主机的粒度重新考虑这件作业，也便是说经过主机实例（Docker 容器、虚拟机、物理机）本地的 HIDS Agent ，完结文件信息、进程信息、环境变量、Shell-Log 等信息的剖析，确认主机实例修正结束。这样，咱们就树立了一个构建链路-主机维度的数据正反校验机制。从理论上讲，主机端 HIDS Agent 掩盖度和存活率都合格的话，咱们几乎可以得到一份具体的软件财物的数据（当然数据禁绝、延迟这些问题必定仍是会有的）。具体的落地中心工程和结构联系，咱们可以参阅下图：

在数据掩盖的差不多的时分，咱们需求经过数据总线传递给数据库房和核算引擎，完结数据的穿插和剖析作业，得出的成果便是存在哪些⻛险和⻛险进展。在这儿，实时引擎一方面需求承当增量财物数据的剖析，另一方面也会保存许多聚合的 CEP 规矩进行剖析。离线引擎则是完结存量⻛险的周期性发现和办理作业。

在谈论完财物数据的搜集之后，咱们来议论⻛险数据的搜集。早在要挟情报系统化建造阶段，组件缝隙情报就作为根底安全情报运用场景下缝隙情报的一个子集，一直存在。但因为之前局限于“缝隙=⻛险”的观念，导致实践履行进程中只存放了组件缝隙相关的⻛险信息，在归纳评估完现有的需求和实践状况之后，咱们发现当前组件缝隙数据，只能承当一部分研制安全⻛险的办理作业。而像关于供应链投毒、开源组件基线状况等其他类型的⻛险数据，因为当时还没有数据可以供给老练的才干输出给事务方运用，经历过充分的谈论和调研之后，决定将组件相关的缝隙数据独立出来，而且新增搜集供应链安全的其他⻛险数据，重新树立一个组件安全相关的数据库，完结⻛险数据的存储和运用。

经过结合本身要挟情报的实践，以及业界关于组件⻛险搜集的最佳实践，咱们打算从 5 个维度对组件相关⻛险进行搜集和存储：

• NVD/CNVD/GitHub-GHSA 等通用缝隙数据库：这个是基本操作，旨在搜集缝隙⻛险，结合缝隙实践状况进行人工和研判。
• Jira、Commit、Release 和 Bugzilia 等 Pull-Request 相关的数据 ：经过获取相关的数据，结合自研的 NLP（Natural Language Process，自然语言剖析）剖析引擎对内容进行倾向性判断，过滤并输出安全相关的信息，然后安排人工或自动化研判，经过实践，咱们发现可以大幅度提早发现⻛险（笔者在 ISC2019 上曾经阐述过⻛险发现前置的必要性和落地经历）。
• 组件专用⻛险库：经过咱们关于缝隙数据相关的调研，比方 Github 和 Snyk 这些安排会有专⻔的组件⻛险库对外供给，经过获取并剖析这些信息，经过加工后可以得到可用性极高的组件⻛险库，可按需研判。
• 软件危险相关的新闻资讯和 RSS 订阅 ：这类源首要是处理 0day 和被 APT 安排在野运用等特别发表的缝隙，同 Pull-Request 数据相同，该类型的绝大部分⻛险数据都是需求经过 NLP 剖析引擎进行情报数据剖析，进一步进行情感推断后才达到可用的规范。
• 手动录入 ：这也是惯例操作，尽管搜集了许多类型的⻛险，但的确受限于供应链进犯的多种多样和开展，所以不或许考虑得面面俱到，依旧需求手动接口补充需求运营的⻛险。但安全团队仍期望将手动录入的⻛险占悉数⻛险的份额，操控到一个合理的规模，确保这部分才干不会因为运营人员的问题（如经历不足、离任等），而导致才干的闪崩性缺失。

经过上述内容，咱们发现这儿面绝大部分数据都对错结构化的，换句话来讲，咱们不可以直接拿来运用，需求处理（异构数据、自然语言数据）后才干够运用，所以咱们在处理时会引进 NLP 剖析引擎，而且对缝隙⻛险数据打标后（首要作业是增加 RepoID 用来和财物数据联动），才干够向下传递给数据引擎和 APIs 。

从要挟情报数据建造的⻆度来看，2019 年前后，根底安全相关的要挟情报完结了结构情报和非结构情报的份额约为 1:1 ，现在非结构的情报数据远高于结构化的情报数据，这也越来越接近于规划的方针，具体的落地中心作业界容和联系结构如下图所示：

在⻛险信息处置环节，实时核算引擎和离线引擎的效果，与财物数据处理时是一起的，首要处理增量和存量的问题。一起考虑到事务本身会有自助排查⻛险的需求，SCA 渠道也会供给一些中心的 APIs 给事务方。

在开始着手建造这些数据相关的根底设施时，需求提出一些建造目标，防止一些要害的功用因为渠道本身的问题，导致服务大规模不可用。在财物方面，现在财物数据库的根底设施可以支撑 TB 等级财物数据的检索才干，回来时刻不超过 100 毫秒；而在⻛险数据建造方面，现在掩盖了合计 10 个技能栈（包含主流的 Maven/Gradle、PyPi、NPM、SPM、APT/Yum、CocoaPods 在内）合计约 59 万条⻛险数据，更新周期在两小时以内，经过核算引擎可以和财物数据进行快速匹配，节省了将近 95% 的排查时刻，大大提升了运营功率。

在匹配规矩建造方面，因为数据来历较多且凌乱，咱们经过自研的 NLP 剖析引擎进行大规模的练习和处理数据之后，可以统一到一个比较固定的数据结构里边，在打标处理后可以完结和财物数据的高效联动。

鉴于 NLP 模型的练习进程和练习方法不归于 SCA 建造进程中比较重要的技能，所以本文中不会打开叙说具体的练习进程和情感推断练习进程。除了财物信息相关之外，⻛险数据库可以一起完结对 CVSS（即 Common Vulnerability Scoring System，即通用脆弱性评分系统）的匹配，及时推送满意 CVSS 影响规模（这儿不是指 CVSS 分数，而是指 CVSS 的描绘表达式）的缝隙信息，提醒安全运营的同学重视相关⻛险并及时进行研判。

关于⻛险的基线数据，现在基线建造数据没有一个相对完好的参阅规范，可是 Google 推进树立的 OpenSSF 基金会（Open Source Security Foundation，在 Google 等互联网企业和美国政府的推进下树立的开源组件安全基金会）在 2021 年下旬发布的 ScoreCard 功用是一个很好的参阅规范，结合同样是 OpenSSF 推出的 AllStar 基线检测东西，可以完美补充组件基线相关的数据。

5. SCA 建造中遇到的问题

当然，在 SCA 建造进程中也不是一帆⻛顺的，咱们总结一下比较困难的地方，首要包含以下几个方面：

• 缝隙-财物相关规矩缺少一个老练且有用的行业规范：在 SCA 范畴，现在没有一个老练的可以匹敌 NVD 相关的生态环境，在 NVD 系统下，有用来描绘缝隙信息的 CVE ，有描绘财物影响规模的 CPE（Common Product Enumunation），有描绘进犯途径的 CAPEC（Common Attack Pattern Enumeration and Classification），还有描绘⻛险类型的 CWE（Common Weakness Enumunation）。可是在组件安全范畴，因为各家公司的根底设施建造老练度和技能选型差异巨大，所以没有一个可用的完好生态可以做到“开箱即用”，所以咱们需求根据现有的技能架构和根底设施来规划自己的规矩，一起推行这套规范在安全运营作业中落地。
• 数据质量与数据链路的可靠性：数据质量和可用性问题是从立项开始一直到后期运营阶段都会呈现的问题，问题或许来自于上游搜集逻辑不齐备或搜集错误，还有数据链路不安稳导致写入核算引擎呈现大批量丢掉的问题，还有数据链路没有查看机制，导致不知道具体问题出在哪里，乃至因为运用的数据剖析技能栈的原因，导致打过来的数据是紊乱的，紊乱的数据有或许会影响 CEP 规矩的精确性和有用性。这傍边的有些问题不是偶发的，乃至有些问题在实在运用的场景下会高频呈现，所以树立一个⻓效的数据拨测机制和数据污点追寻才干是必要且有必要的。
• ⻛险数据的数据结构与精确度：因为在⻛险数据中引进了过多的来历，且许多引进了机器学习和 NLP 技能，将非结构化数据转换成结构化数据，考虑到模型练习的精度、练习样本数据、练习网络等问题，导致渠道提取出来的缝隙信息许多时分会有必定的收支，而且因为⻛险情报数据比较依靠上下文和实效性，所以需求在各方面做取舍，这个问题其实和数据的问题相同，不是一朝一夕能处理的，需求许多的实践运营和拨测机制 Case by Case 地去推进处理。
• CI/CD 控制与非规范财物的办理：这一方面实践上与 SCA 落地的联系不是很大，可是提及的原因是 SCA 本身是一个需求强相关研制流程的才干，好的 SCA 渠道除了可以供给规范化的 APIs 和 GUI 让用户快捷操作，一起也需求兼容非规范的发布流程和上线规范，这便是为什么除了首要的几个技能栈之外，依旧掩盖了一些偏小众的技能栈，如 C#/Powershell 的 NuGet、ErLang 的 Hex 包办理等。
• 财物透视深度： 这一部分其实是 SCA 中心才干的体现，从理论上讲，SCA 是有才干剖析比方 FatJar 这种开源组件嵌套的 JAR 包，但实践上受制于数据质量和技能才干，往往无法剖析到一个十分细的粒度，所以这一部分需求去规划一个 MTI（Maximum Tolerate Index 在这儿表示可接受的最粗剖析粒度）目标去辅导相关的规划。

6. SCA 技能未来的展望

在建造进程中，咱们参阅了许多公司和商业产品关于组件⻛险剖析和办理的最佳实践，翻阅了许多与软件成分剖析技能，以及软件供应链安全办理相关的论文文献、公开的专利以及企业的博客。其间 OpenSSF 基金会的一些研讨成果让人形象深入。

在 2021 年 6 月份 OpenSSF 发布 SLSA （Supply chain Levels for Software Artifacts，即软件供应链安全等级）之后，环绕 SLSA 这一套规范陆续发布了许多有助于咱们剖析的数据服务和产品，比方准 SCA 产品 Open Source Insight，缝隙⻛险库 OSV（Open Source Vulnerabilities，开源组件⻛险数据），软件安全基线查看东西 AllStar 和 ScoreCard，开源组件⻛险奖赏计划 SOS Rewards（可以了解为是开源组件的缝隙奖赏计划）。

咱们开始看到未来 SCA 的建造道路应该是三个方向： 寻求满意细粒度的财物和⻛险透视才干，⻛险的自动辨认才干和开源软件的基线查看才干。换句话讲，SCA 假如想做到满意有用，需求掩盖从软件开发到上线的一切环节，包含代码完好性、流程完好性和基线巡检功用，这些都需求 SCA 的中心才干。

除了 SCA 供给的⻛险透视才干，在整个 DevSecOps 环节，安全团队、质量功率团队、运维团队和事务团队需求十分默契地进行合作，咱们各司其职，一起处理研制方面的⻛险。这其间，安全团队可以供给的，除了⻛险数据和修正建议之外，还需求供给一些对应的根底设施服务，帮忙事务团队更高效地处置⻛险。扩展到整个开源软件⻛险办理方面，也可以给咱们一个 Cheatsheet 做参阅。

当然，想要做到以上一切的项目，实践上关于企业的根底架构和根底设施都有必定的要求，但好在现在开源社区关于供应链安全办理供给了一些安全的处理计划，比方国外由 OpenSSF 或许商业公司牵头规划开发的一系列东西链，如 ChainGuard.dev，SigStore，Anchore 等等，当然国内也有许多优异的开源处理计划。可以在进行必定修正之后，集成到现有的根底架构中。

考虑到安全的对立属性在里边，SCA 东西假如交融进企业界的研制流程中，必然会引发许多对立 SCA 检测的路子，何况在调研进程和实践处置进程中，绕过固有研制流程的状况是比较常⻅的，所以后续在持续建造 SCA 才干的进程中，咱们会逐渐参加对立的检测和加固，防止“漏网之⻥”。

7. 结语

以上是咱们在整个 SCA 才干建造进程中堆集的一些主意和实践。在建造 SCA 才干的进程中，经过与各团队的协同作业和交流，了解了许多事务关于组件安全方面的主意和实在需求，经过需求得出需求建造的才干。在技能计划落地中，企业界部布置的许多安全产品，比方 HIDS Agent 和 RASP 等，可以从主机的⻆度去反向验证建造的进程是否正确。

此外，SCA 才干的落地离不开安全团队与事务团队的合作。实践上在 SCA 的建造进程中，咱们假如再往更深层次去看，会发现比方闭源软件、开源软件的跨架构、跨编译器的辨认、其他载体（比方容器镜像、软件制品）的安全剖析等，这些技能应战关于实践企业界落地 SCA 才干而言仍是蛮高的，考虑到现在的处理计划还停留在 PoC 阶段，就不在这儿进行过多的阐述了。

当然，抛开整个落地的进程，考虑到各家在根底设施、中心技能栈、主机信息监控才干的参差不⻬，所以必定会有不能落地的地方。而站在安全服务供给商的⻆度上看，SCA 相关产品未来的建造或许需求愈加轻量化、敞开协同化。

所谓轻量化，是指产品的中心功用可以在脱离根底设施多种多样的前提下，可以安稳高效地去供给中心才干，能很好地与客户的研制流程完美衔接。从调研成果来看，现在市面上一切的 SCA 产品，基本上都存在一个架构规划比较重的问题，不能很好去融入现有的 CI/CD 流程。所谓敞开协同化，是指可以经过多种方式去和其他的安全产品和安全才干供给数据的共享机制，完结与其他安全设备在数据上的联动，互相补⻬对应的⻛险发现才干，做到简练、高效。

以上便是咱们 SCA 才干建造进程傍边的一些主意。从⻓远的⻆度看，咱们期望从源端树立起一套完好的零信赖供应链⻛险管控系统，掩盖从引进-开发-编译-布置-运用的全生命流程，做到真正意义上的 Secure-by-Default。

从纵向来看，咱们需求在研制流程的框架下尽或许全地理清整个系统的 SBOM 级的数据依靠状况。一起从横向来看，咱们还需求确保现在搜集到的组件相关的⻛险数据和极限数据所掩盖的技能栈满意的全面和精确。刚好这两部分才干是 SCA 才干中比较中心的两个才干，也就说明晰 SCA 才干是这一系统傍边比较重要的一环，可以为整个系统供给一套完好的常识库，为后续供应链⻛险检测逻辑供给一套完好的数据。

最终，特别感谢美团质量功率团队、根底技能团队、到店工作群技能部餐饮的测试团队在整个 SCA 才干建造进程中供给帮忙和建议。一起，也欢迎咱们在文末留言谈论。

8. 本文作者

李中文（e1knot），美团安全高级工程师。

9. 参阅文献

• Software Composition Analysis (SCA) reviews Reviews and Ratings
• Deep dive into Visual Studio Code extension security vulnerabilities
• That Time Linux Banned the University of Minnesota
• PHP’s Git server hacked to add backdoors to PHP source code
• Webmin backdoor blamed on software supply chain breach
• Highly Evasive Attacker Leverages SolarWinds Supply Chain to Compromise Multiple Global Victims With SUNBURST Backdoor
• Open Source Software Is Under Attack; New Event-Stream Hack Is Latest Proof
• Stork: Package Management for Distributed VM Environments
• Hello open source security! Managing risk with software composition analysis
• Introducing Microsoft Application Inspector
• Cyber Supply Chain Risk Management
• THE SOFTWARE BILL OF MATERIALS AND ITS ROLE IN CYBERSECURITY
• Cybersecurity Supply Chain Risk Management C-SCRM
• Introducing the Open Source Insights Project
• Announcing a unified vulnerability schema for open source
• Google stakes new Secure Open Source rewards program for developers with $1M seed money
• Introducing SLSA, an End-to-End Framework for Supply Chain Integrity
• Binary Authorization for Borg: how Google verifies code provenance and implements code identity
• A Kubernetes CI/CD Pipeline with Asylo as a Trusted Execution Environment Abstraction Framework
• AllStar: Continuous Security Policy Enforcement for GitHub Projects
• Google open-sources Allstar, a tool to protect GitHub repos
• Measuring Security Risks in Open Source Software: Scorecards Launches V2
• 2022 OPEN SOURCE SECURITY AND RISK ANALYSIS REPORT
• Focus on the Stability of Large Systems: Toward Automatic Prediction and Analysis of Vulnerability Threat Intelligence
• Open Source Security Explained
• CycloneDX Specification
• 4 Key Sigstore Takeaways: Recap of Twitter Space with Kelsey Hightower
• SLSA vs. Software Supply Chain Attacks
• The State of Open Source Vulnerabilities 2021
• GitHub 2020 Digital Insight Report
• 2020 State of the Software Supply Chain
• Making Sense of Unstructured Intelligence Data Using NLP
• OpenSCA-Cli
• MurphySec Code Scan
• Method and system for monitoring a software artifact
• Method and system for monitoring metadata related to software artifacts
• Method and system for evaluating a software artifact based on issue tracking and source control information
• sigstore – A non-profit, public good software signing & transparency service

10. 团队招聘

美团信息安悉数，肩负统筹与负责美团线上安全与渠道办理的重要职责。跟着事务晋级与拓宽，咱们具有许多全球化安全与⻛控范畴人才、依托前瞻的安全技能视界、立异的机器学习技能、领先的产品运营系统，构建全方位、多维度的智能防护系统，为美团事务生态链上亿万C端、B端用户的安全供给有力保障。咱们致力于建造业界卓越的安全团队，落地更多业界认可的实践，一起助力事务奔驰。等待你的参加，让咱们奔赴热爱，无畏山海，共筑安全⻓城。现在团队多个岗位热招中，点击了解详情：安全团队春季热招岗位vol.1、安全团队春季热招岗位vol.2，欢迎咱们积极投递简历。

阅读美团技能团队更多技能文章合集

前端 | 算法 | 后端 | 数据 | 安全 | 运维 | iOS | Android | 测试

| 在大众号菜单栏对话框回复【2021年货】、【2020年货】、【2019年货】、【2018年货】、【2017年货】等要害词，可查看美团技能团队历年技能文章合集。

| 本文系美团技能团队出品，著作权归属美团。欢迎出于分享和交流等非商业意图转载或运用本文内容，敬请注明“内容转载自美团技能团队”。本文未经许可，不得进行商业性转载或许运用。任何商用行为，请发送邮件至tech@meituan.com申请授权。