一种面向持续集成部署的安全分析方法及装置

技术领域

本发明属于持续集成部署领域，尤其涉及一种面向持续集成部署的安全分析方法及装置。

背景技术

持续集成(Continuous Integration，CI)和持续部署(Continuous Deployment，CD)在现代软件工程实践中被广泛应用。通过将应用程序的构建、测试和部署自动化，持续集成和持续部署显著地提升了软件开发效率。近些年，开源代码托管平台也引入了持续集成和持续部署(CI/CD)服务，允许开发者配置自动化的CI/CD流水线，用以减少开源软件的维护负担。例如，GitHub就在2019年11月正式支持自建的持续集成和持续部署服务，Gitee也推出了自建的持续集成和持续部署服务Gitee Go。目前，Gitee、GitHub、GitLab等主流开源代码托管平台引入的CI/CD服务正在成为一个现象级应用，在近3年里，CI/CD广泛地被各类软件所采用，并且在开源领域愈发流行。

尽管持续集成和部署在开源领域十分流行，但持续集成流水线常常缺少足够的安全防护。由于开源领域的持续集成服务才刚引入不到3年，持续集成部署脚本的作者和用户(比如代码仓库的维护者)还没有充分意识到持续集成和部署存在安全威胁，对攻击方式和攻击后果关注甚少，大家更注重代码本身的安全性，而忽略了作为辅助的持续集成流水线的安全性，导致当前研究工作缺乏对CI/CD安全问题的深入研究。在实现本发明的过程中，发明人发现当前研究多集中在个例或单个漏洞的分析，缺乏对使用了持续集成部署配置的代码仓库的大规模数据收集和综合分析，同时缺乏对持续集成部署流水线的有效安全性评估。

由于在当前的持续集成部署生态中实际存在多种安全问题：首先，恶意的脚本作者可能会发布包含恶意代码的持续集成部署脚本，这些脚本可能会被数以千计的受害仓库所使用。其次，即使脚本本身不是恶意的，它们依然可能含有安全漏洞。这些脚本一经使用，便会给受害者的持续集成流水线引入漏洞，削弱流水线的安全性。目前还没有能够实现自动数据收集和量化的可攻击面分析的面向持续集成部署流水线的安全分析方法。

发明内容

针对现有技术的不足，本申请实施例的目的是提供一种面向持续集成部署的安全分析方法及装置，自动化地爬取指定的开放源代码仓库，从中提取出持续集成部署配置文件；并基于持续集成部署配置文件的语法、语义分析代码的安全问题；最终生成开源项目的安全风险报告并提交给用户。

根据本申请实施例的第一方面，提供一种面向持续集成部署的安全分析方法，包括：

在开源代码托管平台上收集开源项目中关于持续集成部署配置相关的数据信息，通过对所述数据信息进行数据清理，提取出持续集成部署配置文件并保存到数据库；

对所述持续集成部署的配置文件进行安全分析，其中所述安全分析包括脚本识别、运行环境识别、密钥识别、敏感操作识别、脚本认证识别、脚本版本滞后识别、漏洞版本识别；

根据安全分析的结果，生成对应的安全分析报告。

进一步地，在开源代码托管平台上收集开源项目中关于持续集成部署配置相关的数据信息，通过对所述数据信息进行数据清理，提取出持续集成部署配置文件并保存到数据库，包括：

通过开源代码托管平台中的代码仓库查询API，获取开源项目代码仓库的索引；

将所述索引存储进数据库进行保存，以便后续的代码拉取调度和分析；

根据所述数据库中储存的索引，调度到多个线程上拉取开源项目源代码；

从所述开源项目源代码中抽取持续集成部署的配置文件并将所述配置文件保存到数据库中。

进一步地，所述脚本识别用于对所述持续集成部署的配置文件中所引用的脚本进行识别。

进一步地，所述运行环境识别用于通过语法解析识别持续集成部署运行时的环境。

进一步地，所述密钥识别用于通过分析所述持续集成部署的配置文件，识别密钥条目并计算密钥的数量。

进一步地，所述敏感操作识别用于通过分析将脚本分为对应的类别：发布产物或者持续部署，其中所述发布产物是指对软件项目进行持续的自动化的编译打包构建测试发布，所述持续部署是基于持续交付的优势自动将经过测试的代码推入生产环境的过程。

进一步地，所述脚本认证识别用于通过分析持续集成部署所引用的脚本中包含的创作者信息，判断该脚本是否经过了所述开源代码托管平台的官方认证，进而将脚本分成认证和未认证两种类别。

进一步地，所述脚本版本滞后识别用于通过分析持续集成部署所引用的脚本的版本，对比该版本发布的时间戳与脚本发布者发布的最新版本的时间戳，得到脚本版本的更新延迟时间。

进一步地，所述漏洞版本识别用于通过匹配现有的持续集成部署所引用脚本的漏洞和版本信息，判断开源代码托管平台中的开源项目是否引用了曾经含有公开漏洞的脚本，并进一步检测可能仍留存在配置文件中的漏洞。

根据本申请实施例的第二方面，提供一种面向持续集成部署的安全分析装置，包括：

提取模块，用于在开源代码托管平台上收集开源项目中关于持续集成部署配置相关的数据信息，通过对所述数据信息进行数据清理，提取出持续集成部署配置文件并保存到数据库；

分析模块，用于对所述持续集成部署的配置文件进行安全分析，其中所述安全分析包括脚本识别、运行环境识别、密钥识别、敏感操作识别、脚本认证识别、脚本版本滞后识别、漏洞版本识别；

生成模块，用于根据安全分析的结果，生成对应的安全分析报告。

本申请的实施例提供的技术方案可以包括以下有益效果：

(1)系统化的安全敏感操作分析：本申请是首个系统针对持续集成部署流水线的安全分析工具。本申请能够自动收集使用了持续集成部署配置的开放源代码仓库并解析用例，提取有关安全的关键信息，包括持续集成部署的运行时环境、敏感操作、脚本使用情况和已知漏洞影响范围。

(2)跨平台支持：本申请无需额外的人工开销就可以移植到多数主流操作系统(Windows，Unix，Linux，FreeBSD，macOS等)和主流的系统架构上(x86_64，aarch64等)。

因此，本申请具有很好的推广应用前景。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1是根据一示例性实施例示出的一种面向持续集成部署的安全分析方法的流程图。

图2是根据一示例性实施例示出的持续集成部署数据收集流程图。

图3是根据一示例性实施例示出的持续集成部署流水线安全分析流程图。

图4是根据一示例性实施例示出的一种面向持续集成部署的安全分析装置的框图。

图5是根据一示例性实施例示出的电子设备的示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

图1是根据一示例性实施例示出的一种面向持续集成部署的安全分析方法的流程图，如图1所示，该方法应用于终端中，可以包括以下步骤：

步骤S11：在开源代码托管平台上收集开源项目中关于持续集成部署配置相关的数据信息，通过对所述数据信息进行数据清理，提取出持续集成部署配置文件并保存到数据库；

步骤S12：对所述持续集成部署的配置文件进行安全分析，其中所述安全分析包括脚本识别、运行环境识别、密钥识别、敏感操作识别、脚本认证识别、脚本版本滞后识别、漏洞版本识别；

步骤S13：根据安全分析的结果，生成对应的安全分析报告。

由上述实施例可知，本申请是首个系统针对持续集成部署流水线的安全分析工具。本申请能够自动收集使用了持续集成部署配置的开放源代码仓库并解析用例，提取有关安全的关键信息，包括持续集成部署的运行时环境、敏感操作、脚本使用情况和已知漏洞影响范围。本申请无需额外的人工开销就可以移植到多数主流操作系统(Windows，Unix，Linux，FreeBSD，macOS等)和主流的系统架构上(x86_64，aarch64等)。

在步骤S11的具体实施中，开源代码托管平台上保存并管理了开源项目的源代码仓库，这些源代码仓库中包含了关于持续集成部署配置相关的数据信息，通过对所述数据信息进行数据清理，提取出持续集成部署配置文件并保存到数据库；

具体地，如图2所示，此步骤具体包括以下子步骤：

步骤S21：通过开源代码托管平台中的代码仓库查询API，获取开源项目代码仓库的索引；

具体地，例如当爬取开源代码托管平台Github中的开源项目代码仓库时，即是通过Github REST API和Git操作对Github进行多次的代码仓库query(查询)请求，每次请求可以获取在id上连续的100个公开的开源项目代码仓库的所引。当前主流的开源代码托管平台有Gitee、GitHub、GitLab等。

步骤S22：将所述索引存储进数据库进行保存，以便后续的代码拉取调度和分析；

具体地，这里的索引指的是开源项目代码仓库的URL，即代码仓库在开源代码托管平台中的存储地址。

步骤S23：根据所述数据库中储存的索引，调度到多个线程上拉取开源项目源代码；

在一实施例中，采用go-colly爬虫框架，多线程、分布式进行开源项目源代码的爬取。在具体实施中也可以采用其他爬虫框架，本申请中不对其作出限制。

步骤S24：从所述开源项目源代码中抽取持续集成部署的配置文件并将所述配置文件保存到数据库中；

具体地，根据URL所拉取的代码仓库不一定使用了持续集成部署，还需要对这些仓库的内容进行进一步分析。例如针对Github中的开源项目代码仓库，分析其.github/workflows/路径下的文件，如果包含了yml格式的配置文件(持续集成部署配置文件)，便认定该项目使用了持续集成部署工具。便将与之相关的持续集成部署配置文件数据存储进数据库，留待后续安全性分析。

步骤S12：对所述持续集成部署的配置文件进行安全分析，其中所述安全分析包括脚本识别、运行环境识别、密钥识别、敏感操作识别、脚本认证识别、脚本版本滞后识别、漏洞版本识别；

具体地，步骤S11中大规模地获取了使用持续集成部署的开放源代码仓库，并从中提取出持续集成部署配置文件，本步骤对持续集成部署的配置文件进行多方面的安全分析，如图3所示，此步骤可以包括以下子步骤：

2.1脚本识别：对所述持续集成部署的配置文件中所引用的脚本进行识别。

具体地，以YAML文件的语法格式读取配置文件，在配置文件的语法中，用户通过uses字段引用持续集成部署脚本(包括名称和版本信息)。因此，本方法通过解析该字段获取持续集成部署所引用的脚本，并将该脚本和引用关系存储进数据库中。

2.2运行环境识别：运行环境是持续集成部署配置的依赖项之一，通过语法解析识别持续集成部署运行时的环境。

具体地，从持续集成部署配置文件中，提取using字段的内容，如node(Node.js是一个基于Chrome V8引擎的JavaScript运行环境)、docker(Docker是当前一个主流的开源应用容器引擎，通过让开发者打包他们的应用以及依赖包到容器中，即可将标准化的业务程序部署到任意生产环境中)。从using字段中包含的名称和版本信息可以分析脚本运行时的软件环境，这也将作为一个重要的分析项目被记录在数据库中。

2.3密钥识别：密钥的使用是安全敏感的，一旦被误用或泄漏将会导致严重的提权攻击。通过分析持续集成部署配置文件，识别密钥条目并计算密钥的数量。

具体地，用户通常使用{{secrets.XXX}}字段来传递密钥，因此通过分析遍历代码仓库中的持续集成部署配置文件，找出含有{{secrets.XXX}}字段的条目作为一条被传递的密钥，计算密钥的数量，这些信息将用来对持续集成部署流水线进行安全风险评估。

2.4敏感操作识别：发布产物(Publishing)和持续部署(Deployment)操作直接影响了代码仓库的下游用户，因此也是一种敏感操作。敏感操作识别是通过分析将脚本分为对应的类别：发布产物或者持续部署，并存储进数据库。

具体地，例如根据Github Marketplace下的category(分类)里所记录的分类信息对已收集的持续集成部署脚本进行判断，分析其功能是属于发布(Publishing)或是部署(Deployment)。发布产物是指对软件项目进行持续的自动化的编译打包构建测试发布，持续部署是基于持续交付的优势自动将经过测试的代码推入生产环境的过程。攻击者可以容易地利用脚本中的漏洞或恶意代码，向发布的产物注入后门或者污染部署产物，因此发布产物和持续部署作为敏感操作被记录下来，也作为安全风险的衡量标准之一。

2.5脚本认证识别：通过分析持续集成部署所引用脚本中包含的创作者信息，判断该脚本是否经过了所述开源代码托管平台的官方认证，将脚本分成Verified(认证)和Unverified(未认证)两种类别，并存储进数据库。

具体地，较大规模的组织或有较大影响力的个人开发者会进行官方认证，经过审核和认证的作者的持续集成脚本一般可靠性更高。而相对来说，未被官方认证的作者的脚本可能没有接受足够的代码审查，因而出现安全漏洞的可能性会更大。因此通过验证创作者的认证信息来判断脚本是否认证，也是评价持续集成部署流水线安全性的指标之一。

2.6脚本版本滞后识别：通过分析持续集成部署所引用的脚本的版本，对比该版本发布的时间戳与脚本发布者发布的最新版本的时间戳，得到脚本版本的更新延迟时间，并存储进数据库。

具体地，利用时间戳实现了更新延迟计算功能。首先通过遍历代码仓库的持续集成配置文件，解析其中所引用脚本的版本，然后获取该版本发布时的时间戳，同时与该脚本发布的最新版本发布时的时间戳相比较，即可计算出更新延迟。通过量化地研究脚本发布者与引用者之间究竟存在着多大的更新延迟，更新延迟越大，留给恶意攻击者的漏洞利用时间窗口越大，就有可能带来更严重的安全威胁。

2.7漏洞版本识别：通过匹配现有的持续集成部署所引用脚本的漏洞和版本信息，判断开源项目是否引用了曾经含有公开漏洞的脚本，并进一步检测可能仍留存在配置文件中的漏洞，并存储进数据库。

具体地，首先通过在多个CVE(Common Vulnerabilities and Exposures)，即通用漏洞披露网站上进行搜索，可以获取现有已发现的持续集成部署脚本中的安全漏洞，然后根据包含漏洞的脚本的名称和版本信息，跟已经收集到的持续集成部署代码仓库中的配置文件中的脚本引用信息进行匹配，从而检测持续集成部署流水线中的漏洞情况。

基于上述安全分析，将得到的安全分析结果整合存储进数据库。

在步骤S13的具体实施中，根据安全分析的结果，生成对应的安全分析报告；

具体地，通过对持续集成部署流水线中一系列安全分析，对分析结果进行遍历、整合和存储，生成安全分析报告，并以Excel表格的形式提交给用户审阅。分析结果主要包含以下内容：

运行环境：持续集成部署所依赖的运行时环境

密钥传递：持续集成部署中密钥的传递情况

敏感操作：持续集成部署中的敏感操作和脚本的影响

脚本认证：持续集成部署脚本是否被认证

版本滞后：引用的持续集成部署脚本的版本滞后情况

漏洞版本：持续集成部署配置中引入的现有的漏洞情况

在一实施例中，所述安全分析报告中的分析项目和内容可以如下表1所示：

表1安全分析报告

与前述的面向持续集成部署的安全分析方法的实施例相对应，本申请还提供了面向持续集成部署的安全分析装置的实施例。

图4是根据一示例性实施例示出的一种面向持续集成部署的安全分析装置框图。参照图4，该装置可以包括：

提取模块21，用于在开源代码托管平台上收集开源项目中关于持续集成部署配置相关的数据信息，通过对所述数据信息进行数据清理，提取出持续集成部署配置文件并保存到数据库；

分析模块22，用于对所述持续集成部署的配置文件进行安全分析，其中所述安全分析包括脚本识别、运行环境识别、密钥识别、敏感操作识别、脚本认证识别、脚本版本滞后识别、漏洞版本识别；

生成模块23，用于根据安全分析的结果，生成对应的安全分析报告。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

相应的，本申请还提供一种电子设备，包括：一个或多个处理器；存储器，用于存储一个或多个程序；当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如上述的面向持续集成部署的安全分析方法。如图5所示，为本发明实施例提供的一种面向持续集成部署的安全分析方法所在任意具备数据处理能力的设备的一种硬件结构图，除了图5所示的处理器、内存以及网络接口之外，实施例中装置所在的任意具备数据处理能力的设备通常根据该任意具备数据处理能力的设备的实际功能，还可以包括其他硬件，对此不再赘述。

相应的，本申请还提供一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现如上述的面向持续集成部署的安全分析方法。所述计算机可读存储介质可以是前述任一实施例所述的任意具备数据处理能力的设备的内部存储单元，例如硬盘或内存。所述计算机可读存储介质也可以是外部存储设备，例如所述设备上配备的插接式硬盘、智能存储卡(Smart Media Card，SMC)、SD卡、闪存卡(Flash Card)等。进一步的，所述计算机可读存储介还可以既包括任意具备数据处理能力的设备的内部存储单元也包括外部存储设备。所述计算机可读存储介质用于存储所述计算机程序以及所述任意具备数据处理能力的设备所需的其他程序和数据，还可以用于暂时地存储已经输出或者将要输出的数据。

本领域技术人员在考虑说明书及实践这里公开的内容后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。