关于开源:如何应对开源组件⻛险软件成分安全分析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 申请受权。