SCA 概念出现其实很久了。简单来说,就是针对现有的软件系统生成粒度非常细的 SBOM(Software Bill of Materials 软件物料单)清单,然后通过⻛险数据去匹配有没有存在⻛险组件被引用。目前,市面上比较出色的商业产品包括 Synopsys 的 Blackduck 、Snyk 的 SCA 、HP 的 Fortify SCA 等,开源产品包括国内悬镜的 OpenSCA 。
但是,通过对这些产品调研和分析后我们发现,它们由于诸如⻛险数据库完整度、与现有研发流程耦合程度、性能和社区支持不完整等原因,不能很好地融入企业内部的研发流程,但是在企业内部,这一部分能力对于 SDL 工作而言,又是不可或缺的一种能力。所以,企业内部的信息安全团队需要结合业务团队的需求,安全团队自身对于⻛险的理解,企业内部的研发流程现状,以及现有的技术与数据能力、应用成本和 ROI 等现状和问题进行综合考虑,打造属于自己的 SCA 能力,从而帮助业务团队多、快、好、省地解决软件供应链层面上的信息安全问题,安全团队也可以更好地对组件⻛险问题实现全局的治理。
从上述的内容可以得知,在企业内部建设 SCA 能力的过程中,会涉及到很多的产品和运营方面的问题,诸如跨部⻔协作、系统稳定性、业务和安全部⻔对于⻛险的定义不一致等问题。本文主要介绍 SCA 能力在企业内部实际落地的过程、遇到的问题以及对 SCA 技术的看法和展望,希望可以为业界同仁提供一个可以参考的解决方案和范本。
从企业内部的信息安全团队的视角看来,企业内部在整个研发流程当中遇到的⻛险点还是比较多的,通过对于各种攻击面的梳理和分析之后,我们在研发流程中被经常提及的⻛险主要包含以下通用漏洞风险、供应链相关的风险以及过期维护的组件等三类,下文将逐一展开。
在组件安全层面上,首先遇到的问题、也是最容易发现的问题就是漏洞问题,它造成的影响也十分直观,可以导致系统因为恶意利用出现非预期的问题,进一步破坏系统的完整性和可用性。根据 2021 年 Synopsys 放出的软件供应链相关的数据显示,开源代码仓库中至少存在一个漏洞的仓库占整体开源仓库的比例,从 2016 年的 67% 上升到了 84%;至少存在一个高危漏洞的代码仓库占全部仓库的比例,从 2016 年的 53% 上升到了 60%;最高的时候是 2017 年,这一数字增加到了 77%。
而根据 2020 年 Snyk 发布的另一份开源组件与供应链安全的报告显示,漏洞的数量仍然需要提高警惕,XSS 漏洞仍然占据数量榜首,紧随其后的是命令执行类漏洞,这些漏洞会严重影响系统的稳定性。
在上述所罗列出来的⻛险当中,当注意力集中到恶意包(Malicious Packages)上时,我们可以发现该类型的⻛险是 2019 年度上升幅度最快的威胁之一,这也引出了下面的问题。也就是软件供应链相关的⻛险。
开源组件的生产-构建-发布过程,跟企业内部常规的系统研发上线的流程基本上是一致的,简单来说可以抽象成下图中的样子:
开源软件作者完成代码编写后 Push 到源代码管理平台( 包括GitHub、码云、Gitlab私服平台)等;然后在CI/CD 平台上发起构建编译打包的流程,在这个过程中,CI/CD 平台会从组件依赖平台(Sonatype Nexus私服或是 MVNRepository 官方源)上获取需要依赖的包;在 CI/CD 平台完成打包/镜像封装过程后,通过项目分发平台分发到生产环境上,更为现代的方法是直接拉取 Docker 镜像做部署,完成系统的上线。这个过程看似简单,但是实际上环节还是有不少的,我们把每个环节拆解来看,实际上每个环节都是会有很多⻛险的,如下图所示:
在实际的生产环境中,有很多的开发者使用的运行时版本、组件版本以及 CI/CD 平台版本都是已经很久未更新的。当然,站在安全的⻆度上讲,安全团队希望所有的系统都用上最新版本的组件和中间件,但是事实情况是,基于业务自身的规划迭代,或者因为大版本改动较多容易引发兼容性问题,从而导致升级迁移成本过高等诸多原因,使得落地这件事情就变的不是那么容易。为了让安全性和易用性达到平衡,很多企业内部往往会进行妥协,通过其他手段收敛攻击面并且建立旁路的感知体系,来保证安全问题,也可以及时发现和止损。但是⻓久看来,引入过时版本的组件会引发诸多的问题:
综上所述,从安全团队的视⻆看来,⻛险无处不在。但是在一个非安全业务的安全公司,往往业务对于⻛险的理解和要求,跟安全团队的看法可能大相迳庭。
实际上在业务同学看来,他们也十分重视信息安全的相关工作,有些公司的业务技术团队甚至成立了专⻔的安全团队来协助研发同学处理安全相关的问题。可⻅业务不是排斥甚至抵制安全工作,而是缺乏合理和可操作的安全指导,进而导致业务同学不知道产品有什么⻛险。在实际的组件⻛险修复过程中,我们也收到了很多业务同学的反馈和吐槽。总结起来主要有以下几种情况:
从实际情况来看,业务同学并不排斥做安全工作,很多时候是因为缺乏一个有效的机制,我们需要告诉他们引入的软件依赖是否安全,需要完成那些操作和配置才能让开源组件用起来更加安全。作为安全工程师,我们需要站在业务的视角去设身处地地想想,这些问题是不是真的不能够被解决。由于业务和安全双方都有关于组件安全相关的需求,恰好 SCA 这项技术可以很好地满足业务和自身的需求,所以在整个 SCA 建设的过程中,我们需要不断去挖掘这些需求。
其实,SCA 并不是一项很先进的技术,只是在现代的研发过程中随着流程的标准化、组件的丰富化、开源社区的活跃以及开发成本的降低等诸多原因,使得一个项目中纯自己写的代码占整个项目中全部代码的比例变得越来越低了。也就意味着供应链问题产生的影响会越来越大,随着 DevSecOps 的火爆,就重新带火了 SCA 这一传统的技术。
根据很多企业内部的实践,以及业界对于 SCA 技术的理解,我们认为 SCA 比较核心的功能主要包括以下几点:
正所谓“罗⻢不是一日建成的”。虽然现在确定了 SCA 建设需求和建设的方向,但落地仍然需要分阶段完成。正如建设其他的安全子系统一样,安全团队需要按照从基础数据/SOP 开始建设,然后是平台化系统化的建设,进而完成整个 SCA 能力的落地。所以在实际操作过程中,应该将整体建设分成三个阶段进行:
一些比较重要的工作如上图所示。三个阶段完成之后,SCA 的能力大概就建设好了,但在建设过程中,安全团队需要考虑很多东⻄。如果说安全厂商的安全产品和服务可以被认为是问题解决的“分子”的话,甲方安全团队的工作更多的是做大做全的“分母”,要把各种情况都考虑得面面俱到,才能保证⻛险不被遗漏。
首先,在资产建设方面,企业内部的安全团队、质量效率团队以及数据平台团队等存在研发流程的技术团队,需要配合完成自己所辖的 CI/CD 系统数据和数据服务构建数据的采集工作,同时也为 IDE 插件团队提供 SCA 的 API,完成从代码开发环节到应用上线环节的数据采集。
但是,我们在应用这一部分数据之后发现了很多问题,除开数据本身质量和准确度不谈(不谈不代表重要,相反这一部分很重要,后面会介绍这一部分),按照前面提到的场景,还会有很多额外场景。比如说,业务在灰度了一部分之后就忘掉了还没灰度完,导致一个服务下面只修复了一部分机器;再比如有很多“小可爱”会绕过企业本身的 CI/CD 流程进行部署操作(有些甚至还是自己人)。为了考虑到这些例外的情况,我们应该从主机的粒度重新考虑这件事情,也就是说通过主机实例(Docker 容器、虚拟机、物理机)本地的 HIDS Agent ,完成文件信息、进程信息、环境变量、Shell-Log 等信息的分析,确定主机实例修复完毕。这样,我们就建立了一个构建链路-主机维度的数据正反校验机制。从理论上讲,主机端 HIDS Agent 覆盖度和存活率都达标的话,我们几乎可以得到一份详细的软件资产的数据(当然数据不准、延迟这些问题肯定还是会有的)。详细的落地核心工程和结构关系,大家可以参考下图:
在数据覆盖的差不多的时候,我们需要通过数据总线传递给数据仓库和计算引擎,完成数据的交叉和分析工作,得出的结果便是存在哪些⻛险和⻛险进度。在这里,实时引擎一方面需要承担增量资产数据的分析,另一方面也会保存很多聚合的 CEP 规则进行分析。离线引擎则是完成存量⻛险的周期性发现和治理工作。
在讨论完资产数据的采集之后,我们来谈论⻛险数据的收集。早在威胁情报体系化建设阶段,组件漏洞情报就作为基础安全情报应用场景下漏洞情报的一个子集,一直存在。但由于之前局限于“漏洞=⻛险”的观念,导致实际执行过程中只存放了组件漏洞相关的⻛险信息,在综合评估完现有的需求和实际情况之后,我们发现当前组件漏洞数据,只能承担一部分研发安全⻛险的治理工作。而像对于供应链投毒、开源组件基线情况等其他类型的⻛险数据,由于当时还没有数据能够提供成熟的能力输出给业务方使用,经历过充分的讨论和调研之后,决定将组件相关的漏洞数据独立出来,并且新增采集供应链安全的其他⻛险数据,重新建立一个组件安全相关的数据库,完成⻛险数据的存储和应用。
通过结合自身威胁情报的实践,以及业界关于组件⻛险收集的最佳实践,我们打算从 5 个维度对组件相关⻛险进行收集和存储:
通过上述内容,我们发现这里面绝大部分数据都是非结构化的,换句话来讲,我们不可以直接拿来使用,需要处理(异构数据、自然语言数据)后才可以使用,所以我们在处理时会引入 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 基线检测工具,可以完美补充组件基线相关的数据。
当然,在 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 能力的过程中,我们会逐步加入对抗的检测和加固,防止“漏网之⻥”。
以上是我们在整个 SCA 能力建设过程中积累的一些想法和实践。在建设 SCA 能力的过程中,通过与各团队的协同工作和沟通,了解了很多业务对于组件安全方面的想法和真实需求,通过需求得出需要建设的能力。在技术方案落地中,企业内部部署的很多安全产品,诸如 HIDS Agent 和 RASP 等,可以从主机的⻆度去反向验证建设的过程是否正确。
此外,SCA 能力的落地离不开安全团队与业务团队的配合。实际上在 SCA 的建设过程中,我们如果再往更深层次去看,会发现诸如闭源软件、开源软件的跨架构、跨编译器的识别、其他载体(比如容器镜像、软件成品)的安全分析等,这些技术挑战对于实际企业内落地 SCA 能力而言还是蛮高的,考虑到目前的解决方案还停留在 PoC 阶段,就不在这里进行过多的阐述了。
当然,抛开整个落地的过程,考虑到各家在基础设施、核心技术栈、主机信息监控能力的参差不⻬,所以必定会有不能落地的地方。而站在安全服务提供商的⻆度上看,SCA 相关产品未来的建设可能需要更加轻量化、开放协同化。
所谓轻量化,是指产品的核心功能可以在脱离基础设施多种多样的前提下,能够稳定高效地去提供核心能力,能很好地与客户的研发流程完美衔接。从调研结果来看,目前市面上所有的 SCA 产品,基本上都存在一个架构设计比较重的问题,不能很好去融入现有的 CI/CD 流程。所谓开放协同化,是指可以通过多种方式去和其他的安全产品和安全能力提供数据的共享机制,实现与其他安全设备在数据上的联动,互相补⻬对应的⻛险发现能力,做到简洁、高效。
以上就是我们 SCA 能力建设过程当中的一些想法。从⻓远的⻆度看,我们希望从源端建立起一套完整的零信任供应链⻛险管控体系,覆盖从引入-开发-编译-部署-使用的全生命流程,做到真正意义上的 Secure-by-Default。
从纵向来看,我们需要在研发流程的框架下尽可能全地理清整个系统的 SBOM 级的数据依赖情况。同时从横向来看,我们还需要保证目前收集到的组件相关的⻛险数据和极限数据所覆盖的技术栈足够的全面和准确。恰好这两部分能力是 SCA 能力中比较核心的两个能力,也就说明了 SCA 能力是这一体系当中比较重要的一环,可以为整个体系提供一套完整的知识库,为后续供应链⻛险检测逻辑提供一套完整的数据。
最后,特别感谢美团质量效率团队、基础技术团队、到店事业群技术部餐饮的测试团队在整个 SCA 能力建设过程中提供帮助和建议。同时,也欢迎大家在文末留言评论。
李中文(e1knot),美团安全高级工程师。
美团信息安全部,肩负统筹与负责美团线上安全与平台治理的重要职责。随着业务升级与拓展,我们拥有诸多全球化安全与⻛控领域人才、依托前瞻的安全技术视野、创新的机器学习技术、领先的产品运营体系,构建全方位、多维度的智能防御体系,为美团业务生态链上亿万C端、B端用户的安全提供有力保障。我们致力于建设业界卓越的安全团队,落地更多业界认可的实践,同时助力业务奔跑。期待你的加入,让我们奔赴热爱,无畏山海,共筑安全⻓城。目前团队多个岗位热招中,点击了解详情:安全团队春季热招岗位vol.1、安全团队春季热招岗位vol.2,欢迎大家积极投递简历。