CN114371870A - 代码扫描、提交方法及代码扫描服务器、客户端和服务端 - Google Patents

Abstract

本发明公开一种代码扫描、提交方法及代码扫描服务器、客户端和服务端，该代码扫描方法包括：接收客户端的预推送钩子发送的第一代码提交信息；接收服务端的预接收钩子发送的第二代码提交信息和代码变动文件；基于第一代码提交信息和第二代码提交信息获取与代码变动文件相关联的基线代码，并基于代码变动文件确定基线代码中的修改部分；对基线代码中的修改部分进行扫描，得到第一扫描结果；对代码变动文件中的代码进行扫描，得到第二扫描结果；将第一扫描结果和第二扫描结果进行比较，得到本次推送操作的扫描结果，预接收钩子获取本次推送操作的扫描结果，以用于确定本次推送操作是否成功。该方法能够提高扫描效率和扫描精确性。

Description

代码扫描、提交方法及代码扫描服务器、客户端和服务端

技术领域

本申请涉及计算机技术领域，具体地涉及一种代码扫描、提交方法及代码扫描服务器、客户端和服务端。

背景技术

现有主流的代码扫描方式都是基于整个代码库或者基于不同的分支之间的diff进行代码扫描(diff同difference是不同的意思，此处diff表示代码之间的差异)。通过调用静态代码扫描工具等工具进行代码扫描，然后生成代码扫描报告。

例如，一种常见的方案是通过定时任务或相似的方式，定期触发代码的全量扫描，该方式扫描不够及时且全量扫描耗时非常严重。另一种常见的方案是在代码已经提交到系统中之后，再进行代码检查，该方式是一种事后策略，代码推送(push)成功后，再检查代码是否存在问题，此时问题代码已经引入了代码库。再一种常见的方案是在代码push操作中获取增量代码和目标分支进行合并成为完整的代码，并进行代码扫描操作，该方式相当于对完整的代码库进行扫描，和前述的第一种方案相比更为及时，但仍是扫描了全量的代码，耗时严重。

发明内容

为了解决上述问题中的至少一个而提出了本申请。根据本申请一方面，提供了一种代码扫描方法，所述方法包括：接收客户端的预推送钩子发送的第一代码提交信息，所述第一代码提交信息是用户在所述客户端针对本地提交的代码发起推送操作后由所述预推送钩子获取的；接收服务端的预接收钩子发送的第二代码提交信息和代码变动文件，所述第二代码提交信息和所述代码变动文件是所述预接收钩子从所述客户端接收到所述本地提交的代码后获取的；基于所述第一代码提交信息和所述第二代码提交信息获取与所述代码变动文件相关联的基线代码，并基于所述代码变动文件确定所述基线代码中的修改部分；对所述基线代码中的修改部分进行扫描，得到第一扫描结果；将所述代码变动文件中的代码加入所述基线代码中生成所述本地提交的代码，对所述代码变动文件中的代码进行扫描，得到第二扫描结果；将所述第一扫描结果和所述第二扫描结果进行比较，得到本次推送操作的扫描结果。

其中，所述的客户端包括但不限于linux操作系统(centOS、ubuntu等)、windows操作系统、macOS操作系统等各种可以提交代码的介质。

在本申请的一个实施例中，所述方法还包括：在得到所述扫描结果后，调用所述预接收钩子中开放的接口，以主动向所述预接收钩子通知扫描完成，从而使得所述预接收钩子获取本次推送操作的扫描结果，以用于确定所述本次推送操作是否成功；或者在得到所述扫描结果后，所述预接收钩子通过轮询的方式获取所述本次推送操作的扫描结果，以用于确定所述本次推送操作是否成功。

在本申请的一个实施例中，所述将所述第一扫描结果和所述第二扫描结果进行比较，得到本次推送操作的扫描结果，包括：对于所述第二扫描结果中的每个程序错误，确定所述程序错误所在的代码行是否是相对于所述基线代码的新增行；如果所述程序错误所在的代码行不是相对于所述基线代码的新增行，则确定所述程序错误不是新增的程序错误；如果所述程序错误所在的代码行是相对于所述基线代码的新增行，则确定所述程序错误为新增的程序错误，所有所述新增的程序错误作为本次推送操作的扫描结果。

在本申请的一个实施例中，当所述代码变动文件中的代码是所述基线代码中不存在的新增代码时，不存在所述修改部分和所述第一扫描结果，将所述第二扫描结果作为所述本次推送操作的扫描结果。

在本申请的一个实施例中，当所述代码变动文件指示所述本地提交的代码是所述基线代码被删除了部分代码而得到的时，不执行代码扫描。

在本申请的一个实施例中，所述第一代码提交信息包括用户名、本地提交标识符、远端提交标识符和代码库地址；所述第二代码提交信息包括用户名、本地提交标识符、远端提交标识符和目标代码分支名。

在本申请的一个实施例中，所述代码变动文件为带相对路径的代码变动文件所构成的压缩文件。

在本申请的一个实施例中，所述基线代码是预先从所述服务端下载并经存储的。

在本申请的一个实施例中，所述方法还包括：对失败的所述推送操作呈现一键推送按钮，所述一键推送按钮在被用户点击后，将强制提交所述本地提交的代码。

在本申请的一个实施例中，所述一键推送按钮仅对预设权限级别的用户可用。

在本申请的一个实施例中，所述客户端为git客户端，所述服务端为gitlab服务端、github服务端、Gitea代码托管服务端、GitkKaken代码托管服务端或者Beanstalk代码托管服务端。

根据本申请另一方面，提供了一种代码提交方法，所述方法包括：在用户针对本地提交的代码发起推送操作时，由经配置的预推送钩子进行信息截取，以获取第一代码提交信息；将所述第一代码提交信息发送至代码扫描服务器，从而由所述代码扫描服务器执行上述的代码扫描方法。

根据本申请再一方面，提供了一种代码提交方法，所述方法包括：在从客户端接收到本地提交的代码后，由经配置的预接收钩子进行提交拦截，以获取第二代码提交信息和与所述本地提交的代码相关联的基线代码；基于所述本地提交的代码和所述基线代码确定代码变动部分，以生成代码变动文件；将所述第二代码提交信息和所述代码变动文件传送至代码扫描服务器，从而由所述代码扫描服务器执行上述的代码扫描方法。

根据本申请又一方面，提供了一种代码扫描服务器，所述代码扫描服务器用于执行上述的代码扫描方法。

根据本申请再一方面，提供了一种客户端，所述客户端用于执行上述的代码提交方法。

根据本申请又一方面，提供了一种服务端，所述服务端用于执行上述的代码提交方法。

根据本申请再一方面，提供了一种代码提交服务器，所述服务器包括：接收模块，用于接收客户端的预推送钩子发送的第一代码提交信息，并接收服务端的预接收钩子发送的第二代码提交信息和代码变动文件，其中所述第一代码提交信息是用户在所述客户端针对本地提交的代码发起推送操作后由所述预推送钩子获取的，所述第二代码提交信息和所述代码变动文件是所述预接收钩子从所述客户端接收到所述本地提交的代码后获取的；扫描模块，用于基于所述第一代码提交信息和所述第二代码提交信息获取与所述代码变动文件相关联的基线代码，基于所述代码变动文件确定所述基线代码中的修改部分，对所述基线代码中的修改部分进行扫描，得到第一扫描结果，并将所述代码变动文件中的代码加入所述基线代码中生成所述本地提交的代码，对所述代码变动文件中的代码进行扫描，得到第二扫描结果；比较模块，用于将所述第一扫描结果和所述第二扫描结果进行比较，得到本次推送操作的扫描结果。

根据本申请又一方面，提供了一种客户端，所述客户端包括：信息截取模块，用于在用户针对本地提交的代码发起推送操作时，由经配置的预推送钩子进行信息截取，以获取第一代码提交信息；发送模块，用于将所述第一代码提交信息发送至代码扫描服务器，从而由所述代码扫描服务器执行上述代码扫描方法。

根据本申请再一方面，提供了一种服务端，所述服务端包括：提交拦截模块，用于在从客户端接收到本地提交的代码后，由经配置的预接收钩子进行提交拦截，以获取第二代码提交信息和与所述本地提交的代码相关联的基线代码；生成模块，用于基于所述本地提交的代码和所述基线代码确定代码变动部分，以生成代码变动文件；传送模块，用于将所述第二代码提交信息和所述代码变动文件传送至代码扫描服务器，从而由所述代码扫描服务器执行上述代码扫描方法。

根据本申请又一方面，提供了一种存储介质，所述存储介质上存储有计算机程序，所述计算机程序在运行时，执行上述代码扫描方法或代码提交方法。

本申请的方案基于代码差异进行的代码扫描，相对于全量代码扫描方式，大大减少了扫描时间。此外，本申请的方案扫描了差异文件的旧版本和新版本的存在问题，并通过算法得到了新增问题；新增问题是与本次提交强相关的，方便代码提交人快速定位自己修改部分的代码存在的问题，节约时间和人力成本，为企业创造价值。而且，本申请的方案是一种事先策略(代码提交到服务端之前)，可以有效地阻止问题代码汇入代码仓库，从而保证代码仓库的代码的安全性。

附图说明

通过结合附图对本申请实施例进行更详细的描述，本申请的上述以及其他目的、特征和优势将变得更加明显。附图用来提供对本申请实施例的进一步理解，并且构成说明书的一部分，与本申请实施例一起用于解释本申请，并不构成对本申请的限制。在附图中，相同的参考标号通常代表相同部件或步骤。

图1示出根据本申请实施例的代码扫描方法的示意性流程图。

图2示出根据本申请一个实施例的代码提交方法的示意性流程图。

图3示出根据本申请另一个实施例的代码提交方法的示意性流程图。

图4示出根据本申请实施例的代码扫描和提交方法的示意性流程框图。

图5示出根据本申请实施例的代码扫描服务器的示意性结构框图。

图6示出根据本申请实施例的客户端的示意性结构框图。

图7示出根据本申请实施例的服务端的示意性结构框图。

具体实施方式

为了使得本申请的目的、技术方案和优点更为明显，下面将参照附图详细描述根据本申请的示例实施例。显然，所描述的实施例仅仅是本申请的一部分实施例，而不是本申请的全部实施例，应理解，本申请不受这里描述的示例实施例的限制。基于本申请中描述的本申请实施例，本领域技术人员在没有付出创造性劳动的情况下所得到的所有其他实施例都应落入本申请的保护范围之内。

push操作是将本地代码推送到远端代码版本控制系统中的操作。用户在进行代码管理时，会对代码进行静态扫描等一系列操作，但是全量的代码扫描结果，对于一个项目来讲是巨大的工作量以及长期的改进。本技术针对当前现业界现有的操作模式的痛点提供了一个新的代码解决思路，在代码push时将代码进行扫描来实现将大问题精确切分为针对每次push的小问题，以大化小，各个击破。程序员在push代码时，只需较小的工作量就可以保证提交的代码合规、安全并且低风险。由于发现程序错误(bug)的时间与解决bug所耗费的代价是成正比关系的，越早发现bug，解决的成本越低。因此，本申请的技术方案可为公司解决大量的人力成本并提高产品的质量，从而能够创造巨大的商业利益。

下面参照附图结合具体实施例来描述本申请的方案。

图1根据本申请实施例的代码扫描方法100的示意性流程图。如图1所示，代码扫描方法100可以包括如下步骤：

在步骤S110，接收客户端的预推送钩子发送的第一代码提交信息，第一代码提交信息是用户在客户端针对本地提交的代码发起推送操作后由预推送钩子获取的。

在步骤S120，接收服务端的预接收钩子发送的第二代码提交信息和代码变动文件，第二代码提交信息和代码变动文件是预接收钩子从客户端接收到本地提交的代码后获取的。

在步骤S130，基于第一代码提交信息和第二代码提交信息获取与代码变动文件相关联的基线代码，并基于代码变动文件确定基线代码中的修改部分。

在步骤S140，对基线代码中的修改部分进行扫描，得到第一扫描结果。

在步骤S150，将代码变动文件中的代码加入基线代码中生成本地提交的代码，对代码变动文件中的代码进行扫描，得到第二扫描结果。

在步骤S160，将第一扫描结果和第二扫描结果进行比较，得到本次推送操作的扫描结果。

在本申请的实施例中，代码扫描方法100可以由代码扫描服务器来执行，其在代码push时对代码进行扫描。

具体地，用户在客户端(如git客户端)针对本地提交的代码发起push操作，在此之后，不是直接将本地提交的代码传送至服务端(如gitlab服务端)，而是由客户端的预推送钩子(pre-push hook)进行信息截取，得到第一代码提交信息，并将该第一代码提交信息传送至代码扫描服务器。此处，第一代码提交信息为与本次代码提交相关的信息，诸如用户名(user name)、本地提交标识符(local-commit_id)、远端提交标识符(remote-commit_id)和代码库地址，为了与下文中描述的第二代码提交信息相互区分而如此命名。代码扫描服务器接收到该第一代码提交信息后，可以根据第一代码提交信息确定与其相关联的基线代码，以用于后续操作。

另一方面，在预推送钩子进行信息拦截后，本地提交的代码上传至服务端，服务端不是直接将其存入代码库，而是由服务端的预接收钩子(pre-receive hook)进行提交拦截，以获取第二代码提交信息。此处，第二代码提交信息为与本次代码提交相关的信息，诸如用户名、本地提交标识符、远端提交标识符和目标代码分支名，为了与上文中描述的第一代码提交信息相互区分而如此命名。此外，预接收钩子还获取与本地提交的代码相关联的基线代码，将本地提交的代码与基线代码进行比较，确定代码变动部分，并基于此生成代码变动文件(该代码变动文件可以为一个带路径的压缩包文件，以用于减少数据传输量)，将代码变动文件以及前面的第二代码提交信息传送至代码扫描服务器。

代码扫描服务器根据接收到的第一代码提交信息和第二代码提交信息，可以获取与代码变动文件相关联的基线代码。该基线代码可以是从代码扫描服务器的一个数据库中获取的，该数据库中存储的是预先通过代码仓库地址使用项目负责人的访问令牌(accesstoken)以及remote-commit_id下载过的各种基线代码。这是一种使用空间换区时间的方案，将代码库代码预先拉取到代码扫描服务器上，即服务器撒花姑娘保留一份代码仓库副本，当进行代码扫描时，直接切换到push时对应的remote分支从而减少代码拉取耗时。在代码扫描结束后进行revert恢复为remote commit id的代码。可以维护一个仓库名称和项目负责人access token以及代码仓库地址的关系表，以用于查询并获取与代码变动文件相关联的基线代码。

获取与代码变动文件相关联的基线代码后，代码扫描服务器可以根据代码变动文件中的代码确定基线代码中的修改部分(即本地提交的代码相对于基线代码修改了基线代码的哪些部分)。然后，代码扫描服务器可以扫描该修改部分，得到第一扫描结果，该扫描结果是次push操作之前基线代码中未来将被修改的那部分的bug。另一方面，代码扫描服务器可以将代码变动文件中的代码添加到基线代码中，生成用户在客户端推送的本地提交的代码，对所添加的代码(即代码变动文件中的代码)进行扫描，得到第二扫描结果，该扫描结果是本次push操作提交的代码中的bug。因此，通过对比第一扫描结果和第二扫描结果，可检出新增bug，作为本次push的扫描结果。根据预定规则(诸如根据新增bug的数量和/或种类)，即可确定本次push是否成功。

在本申请的实施例中，步骤S160涉及如何进行扫描结果的diff。传统的diff方式直接比较扫描结果的行号及其问题内容。此种方式的缺陷为：例如：当文件A中有10个bug被扫描出来了，此时对文件A进行修改，修改后文件为A*；在A中非最前面或者最后面加入一段有5个bug的代码；此时比较A与A*文件diff。业内通常使用通过比较行号以及内容的方式进行比较，会导致在插入代码段后面的bug在扫描时的行号发生变化，diff时会误认为在此处的bug和原有的bug为非同一个bug，导致diff结果不准确。最好的情况是新增代码在原有文件A的最后，diff结果最准确，为5个bug。最坏的情况是新增代码在文件A的最上方，导致原有十个bug的行号都发生变化，认为整个文件的全部bug都是diff。基于此，本申请给出了解决方案：即通过对原有文件A和A*进行分析，判断出哪一行是A*新增行，哪一行是A*删除的行。如果diff的bug所在行为新增行，那么bug为新增bug；如果bug所在行为非新增行，则为原有bug，需在diff统计结果中剔除该原有bug。

因此，在本申请的实施例中，步骤S160中将第一扫描结果和第二扫描结果进行比较，得到本次推送操作的扫描结果，可以包括：对于第二扫描结果中的每个程序错误(bug)，确定该bug所在的代码行是否是相对于基线代码的新增行；如果该bug所在的代码行不是相对于基线代码的新增行，则确定该bug不是新增的bug；如果该bug所在的代码行是相对于基线代码的新增行，则确定该bug为新增的bug，所有新增的bug作为本次推送操作的扫描结果。

上述扫描过程应用于如下场景：代码变动文件中的代码是基线代码中某部分代码修改后的结果，即代码变动文件中的代码是修改代码，此时前述的第一扫描结果即为基线代码中涉及修改的那部分代码的扫描结果，前述的第二扫描结果即为代码变动文件中的代码的扫描结果。在另一场景中，当代码变动文件中的代码是基线代码中不存在的代码，即代码变动文件中的代码是新增代码时，基线代码中不存在某部分代码是被修改的，此时不包括基线代码中的修改部分，没有前述的第一扫描结果，此时可以仅对该新增代码的扫描结果，该扫描结果直接作为本次push的扫描结果。在又一场景中，代码变动文件指示基线代码中部分代码被删除而得到本地提交的代码，此时可以无需执行代码扫描。总体上，可以根据代码变动文件确定本地提交的代码相对于基线代码的修改方式(修改、新增、删除)，根据修改方式的不同，之后执行的扫描也不同。

在本申请的实施例中，方法100还包括(未示出)：在得到扫描结果后，调用预接收钩子中开放的接口，以主动向预接收钩子通知扫描完成，从而使得预接收钩子获取本次推送操作的扫描结果，以用于确定本次推送操作是否成功；或者在得到扫描结果后，预接收钩子通过轮询的方式获取本次推送操作的扫描结果，以用于确定本次推送操作是否成功。总体上，通过轮询或者接口回调的方式，可以被动或者主动获取本次推送操作的扫描结果。

例如，可由服务端的预接收钩子通过轮询来获取本次push的扫描结果，以用于确定本次push是否成功。一般地，包括三种情况：1)未找到仓库地址，那么客户端未安装钩子，返回失败信息为客户端未安装指定程序，push失败；2)仓库地址存在，测试通过，那么继续执行push的后续流程；3)仓库地址存在，测试未通过，那么返回测试结果，push失败，并发送邮件给配置的用户告知push失败原因。

因此，本申请的方案是基于代码差异进行的代码扫描，相对于全量代码扫描方式，大大减少了扫描时间。此外，本申请的方案扫描了差异文件的旧版本和新版本的存在问题，并通过算法得到了新增问题；新增问题是与本次提交强相关的，方便代码提交人快速定位自己修改部分的代码存在的问题，节约时间和人力成本，为企业创造价值。而且，本申请的方案是一种事先策略(代码提交到服务端之前)，可以有效地阻止问题代码汇入代码仓库，从而保证代码仓库的代码的安全性。

在本申请的进一步的实施例中，方法100还可以包括(未示出)：对失败的push呈现一键推送按钮，该一键推送按钮在被用户点击后，将强制提交本地提交的代码。其中，该一键推送按钮仅对预设权限级别的用户可用。在该实施例中，能够通过权限进行紧急代码入库。具体地，因代码扫描未通过校验导致的push失败，在代码扫描服务器所有push的页面会对项目管理人员展示一个一键push的按钮，针对该条push此按钮触发的操作是通过代码扫描服务器账号通过remote_commit_id获取代码分支，并拉取最新代码，将代码变动的压缩包文件解压代码复制进去，并添加(add)、提交(commit)、push绕过代码扫描服务器扫描。代码冲突问题同常规方式。一键push后，在页面展示push结果。

在本申请的实施例中，还可以对失败的push进行如下管理：页面在push记录上点击强合，用户重新提交。在页面上可以通过user name以及时间等进行数据检索过滤push记录。Push上的强合按钮是通过权限管理进行展示的。普通用户只展示代码push记录以及查看详情功能，代码库owner账号可以展示强push按钮。按钮点击，数据库后台将push值置为1。用户在客户端重新push，pre-receive调用接口进行push值查询，扫描全部local-commitId、remote-commit Id、user name三个完全相同的任务(job)，如果标志位push为null那么继续扫描，如果有标志位push为1，则提交不做代码扫描，接口直接返回跳过扫描，pre-receive根据接口返回进行操作。如果遍历全部为null，那么做代码扫描。Push无需置位操作，几乎不会出现两个commit id和user name相同的提交。由于push为1的数量比较少，为了加速查询，可以迭代job Id优先判断push值。随着数据库内容增多，查询变慢，测试结果可以保存固定期限，例如一个月等等。如果用户push失败，代码冲突，需要重新提交，此时commit id变化，会重新进行代码检查。

以上方法100是从代码扫描服务器的角度描述的代码扫描方法，其也描述了客户端和服务端的配合操作。下面参照图2和图3分别从客户端的角度和服务端的角度来描述。

图2示出根据本申请一个实施例的代码提交方法200的示意性流程图，其可以由客户端(如git客户端)来执行。如图2所示，代码提交方法200可以包括如下步骤：

在步骤S210，在用户针对本地提交的代码发起推送操作时，由经配置的预推送钩子进行信息截取，以获取第一代码提交信息。

在步骤S220，将第一代码提交信息发送至代码扫描服务器，从而由代码扫描服务器执行前文所述的代码扫描方法。

该代码提交方法200主要描述客户端，尤其是客户端的预推送钩子在本申请的代码扫描方法中执行的操作，前文中已经详细描述过，此处不再赘述。

图3示出根据本申请另一个实施例的代码提交方法300的示意性流程图，其可以由服务端(如gitlab服务端)来执行。如图3所示，代码提交方法300可以包括如下步骤：

在步骤S310，在从客户端接收到本地提交的代码后，由经配置的预接收钩子进行提交拦截，以获取第二代码提交信息和与本地提交的代码相关联的基线代码。

在步骤S320，基于本地提交的代码和基线代码确定代码变动部分，以生成代码变动文件。

在步骤S330，将第二代码提交信息和代码变动文件传送至代码扫描服务器，从而由代码扫描服务器执行前文所述的代码扫描方法。

该代码提交方法300主要描述服务端，尤其是服务端的预接收钩子在本申请的代码扫描方法中执行的操作，前文中已经详细描述过，此处不再赘述。

总体上，本申请的代码扫描、提交方法涉及客户端、服务端以及代码扫描服务器这三者的操作，可结合图4来理解其详细过程，前文已经描述过，此处不再文字赘述。根据本申请另一方面，还提供了一种代码扫描服务器、客户端和服务端，其分别用于执行前文所述的方法100、200和300，前文已经详细描述过，此处不再赘述，仅结合图5到图7描述其主要结构。

图5示出根据本申请实施例的代码扫描服务器500的示意性结构框图。如图5所示，服务器500包括：接收模块510，用于接收客户端的预推送钩子发送的第一代码提交信息，并接收服务端的预接收钩子发送的第二代码提交信息和代码变动文件，其中第一代码提交信息是用户在客户端针对本地提交的代码发起推送操作后由预推送钩子获取的，第二代码提交信息和代码变动文件是预接收钩子从客户端接收到本地提交的代码后获取的；扫描模块520，用于基于第一代码提交信息和第二代码提交信息获取与代码变动文件相关联的基线代码，基于代码变动文件确定基线代码中的修改部分，对基线代码中的修改部分进行扫描，得到第一扫描结果，并将代码变动文件中的代码加入基线代码中生成本地提交的代码，对代码变动文件中的代码进行扫描，得到第二扫描结果；比较模块530，用于将第一扫描结果和第二扫描结果进行比较，得到本次推送操作的扫描结果。

图6示出根据本申请实施例的客户端600的示意性结构框图。如图6所示，客户端600包括：信息截取模块610，用于在用户针对本地提交的代码发起推送操作时，由经配置的预推送钩子进行信息截取，以获取第一代码提交信息；发送模块620，用于将所述第一代码提交信息发送至代码扫描服务器，从而由所述代码扫描服务器执行上述代码扫描方法100。

图7示出根据本申请实施例的服务端700的示意性结构框图。如图7所示，服务端700包括：提交拦截模块710，用于在从客户端接收到本地提交的代码后，由经配置的预接收钩子进行提交拦截，以获取第二代码提交信息和与所述本地提交的代码相关联的基线代码；生成模块720，用于基于所述本地提交的代码和所述基线代码确定代码变动部分，以生成代码变动文件；传送模块730，用于将所述第二代码提交信息和所述代码变动文件传送至代码扫描服务器，从而由所述代码扫描服务器执行上述代码扫描方法100。

根据本申请又一方面，还提供了一种存储介质，所述存储介质上存储有计算机程序，所述计算机程序在运行时，执行上述代码扫描方法100、200或300。

基于上面的描述，本申请的方案基于代码差异进行的代码扫描，相对于全量代码扫描方式，大大减少了扫描时间。此外，本申请的方案扫描了差异文件的旧版本和新版本的存在问题，并通过算法得到了新增问题；新增问题是与本次提交强相关的，方便代码提交人快速定位自己修改部分的代码存在的问题，节约时间和人力成本，为企业创造价值。而且，本申请的方案是一种事先策略(代码提交到服务端之前)，可以有效地阻止问题代码汇入代码仓库，从而保证代码仓库的代码的安全性。

尽管这里已经参考附图描述了示例实施例，应理解上述示例实施例仅仅是示例性的，并且不意图将本申请的范围限制于此。本领域普通技术人员可以在其中进行各种改变和修改，而不偏离本申请的范围和精神。所有这些改变和修改意在被包括在所附权利要求所要求的本申请的范围之内。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其他的方式实现。例如，以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个设备，或一些特征可以忽略，或不执行。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本申请的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本申请并帮助理解各个发明方面中的一个或多个，在对本申请的示例性实施例的描述中，本申请的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该本申请的方法解释成反映如下意图：即所要求保护的本申请要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如相应的权利要求书所反映的那样，其发明点在于可以用少于某个公开的单个实施例的所有特征的特征来解决相应的技术问题。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本申请的单独实施例。

本领域的技术人员可以理解，除了特征之间相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其他实施例中所包括的某些特征而不是其他特征，但是不同实施例的特征的组合意味着处于本申请的范围之内并且形成不同的实施例。例如，在权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本申请的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本申请实施例的一些模块的一些或者全部功能。本申请还可以实现为用于执行这里所描述的方法的一部分或者全部的装置程序(例如，计算机程序和计算机程序产品)。这样的实现本申请的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本申请进行说明而不是对本申请进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本申请可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

以上所述，仅为本申请的具体实施方式或对具体实施方式的说明，本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。本申请的保护范围应以权利要求的保护范围为准。

Claims (20)

1.一种代码扫描方法，其特征在于，所述方法包括：

接收客户端的预推送钩子发送的第一代码提交信息，所述第一代码提交信息是用户在所述客户端针对本地提交的代码发起推送操作后由所述预推送钩子获取的；

接收服务端的预接收钩子发送的第二代码提交信息和代码变动文件，所述第二代码提交信息和所述代码变动文件是所述预接收钩子从所述客户端接收到所述本地提交的代码后获取的；

基于所述第一代码提交信息和所述第二代码提交信息获取与所述代码变动文件相关联的基线代码，并基于所述代码变动文件确定所述基线代码中的修改部分；

对所述基线代码中的修改部分进行扫描，得到第一扫描结果；

将所述代码变动文件中的代码加入所述基线代码中生成所述本地提交的代码，对所述代码变动文件中的代码进行扫描，得到第二扫描结果；

将所述第一扫描结果和所述第二扫描结果进行比较，得到本次推送操作的扫描结果。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在得到所述扫描结果后，调用所述预接收钩子中开放的接口，以主动向所述预接收钩子通知扫描完成，从而使得所述预接收钩子获取本次推送操作的扫描结果，以用于确定所述本次推送操作是否成功；或者

在得到所述扫描结果后，所述预接收钩子通过轮询的方式获取所述本次推送操作的扫描结果，以用于确定所述本次推送操作是否成功。

3.根据权利要求1所述的方法，其特征在于，所述将所述第一扫描结果和所述第二扫描结果进行比较，得到本次推送操作的扫描结果，包括：

对于所述第二扫描结果中的每个程序错误，确定所述程序错误所在的代码行是否是相对于所述基线代码的新增行；

如果所述程序错误所在的代码行不是相对于所述基线代码的新增行，则确定所述程序错误不是新增的程序错误；

如果所述程序错误所在的代码行是相对于所述基线代码的新增行，则确定所述程序错误为新增的程序错误，所有所述新增的程序错误作为本次推送操作的扫描结果。

4.根据权利要求1所述的方法，其特征在于，当所述代码变动文件中的代码是所述基线代码中不存在的新增代码时，不存在所述修改部分和所述第一扫描结果，将所述第二扫描结果作为所述本次推送操作的扫描结果。

5.根据权利要求1所述的方法，其特征在于，当所述代码变动文件指示所述本地提交的代码是所述基线代码被删除了部分代码而得到的时，不执行代码扫描。

6.根据权利要求1所述的方法，其特征在于，所述第一代码提交信息包括用户名、本地提交标识符、远端提交标识符和代码库地址；

所述第二代码提交信息包括用户名、本地提交标识符、远端提交标识符和目标代码分支名。

7.根据权利要求1所述的方法，其特征在于，所述代码变动文件为带相对路径的代码变动文件所构成的压缩文件。

8.根据权利要求1所述的方法，其特征在于，所述基线代码是预先从所述服务端下载并经存储的。

9.根据权利要求1-8中的任一项所述的方法，其特征在于，所述方法还包括：

对失败的所述推送操作呈现一键推送按钮，所述一键推送按钮在被用户点击后，将强制提交所述本地提交的代码。

10.根据权利要求9所述的方法，其特征在于，所述一键推送按钮仅对预设权限级别的用户可用。

11.根据权利要求1-6中的任一项所述的方法，其特征在于，所述客户端为git客户端，所述服务端为gitlab服务端、github服务端、Gitea代码托管服务端、GitkKaken代码托管服务端或者Beanstalk代码托管服务端。

12.一种代码提交方法，其特征在于，所述方法包括：

在用户针对本地提交的代码发起推送操作时，由经配置的预推送钩子进行信息截取，以获取第一代码提交信息；

将所述第一代码提交信息发送至代码扫描服务器，从而由所述代码扫描服务器执行权利要求1-11中的任一项所述的代码扫描方法。

13.一种代码提交方法，其特征在于，所述方法包括：

在从客户端接收到本地提交的代码后，由经配置的预接收钩子进行提交拦截，以获取第二代码提交信息和与所述本地提交的代码相关联的基线代码；

基于所述本地提交的代码和所述基线代码确定代码变动部分，以生成代码变动文件；

将所述第二代码提交信息和所述代码变动文件传送至代码扫描服务器，从而由所述代码扫描服务器执行权利要求1-11中的任一项所述的代码扫描方法。

14.一种代码扫描服务器，其特征在于，所述代码扫描服务器用于执行权利要求1-11中的任一项所述的代码扫描方法。

15.一种客户端，其特征在于，所述客户端用于执行权利要求12所述的代码提交方法。

16.一种服务端，其特征在于，所述服务端用于执行权利要求13所述的代码提交方法。

17.一种代码提交服务器，其特征在于，所述服务器包括：

接收模块，用于接收客户端的预推送钩子发送的第一代码提交信息，并接收服务端的预接收钩子发送的第二代码提交信息和代码变动文件，其中所述第一代码提交信息是用户在所述客户端针对本地提交的代码发起推送操作后由所述预推送钩子获取的，所述第二代码提交信息和所述代码变动文件是所述预接收钩子从所述客户端接收到所述本地提交的代码后获取的；

扫描模块，用于基于所述第一代码提交信息和所述第二代码提交信息获取与所述代码变动文件相关联的基线代码，基于所述代码变动文件确定所述基线代码中的修改部分，对所述基线代码中的修改部分进行扫描，得到第一扫描结果，并将所述代码变动文件中的代码加入所述基线代码中生成所述本地提交的代码，对所述代码变动文件中的代码进行扫描，得到第二扫描结果；

比较模块，用于将所述第一扫描结果和所述第二扫描结果进行比较，得到本次推送操作的扫描结果。

18.一种客户端，其特征在于，所述客户端包括：

信息截取模块，用于在用户针对本地提交的代码发起推送操作时，由经配置的预推送钩子进行信息截取，以获取第一代码提交信息；

发送模块，用于将所述第一代码提交信息发送至代码扫描服务器，从而由所述代码扫描服务器执行权利要求1-11中的任一项所述的代码扫描方法。

19.一种服务端，其特征在于，所述服务端包括：

提交拦截模块，用于在从客户端接收到本地提交的代码后，由经配置的预接收钩子进行提交拦截，以获取第二代码提交信息和与所述本地提交的代码相关联的基线代码；

生成模块，用于基于所述本地提交的代码和所述基线代码确定代码变动部分，以生成代码变动文件；

传送模块，用于将所述第二代码提交信息和所述代码变动文件传送至代码扫描服务器，从而由所述代码扫描服务器执行权利要求1-11中的任一项所述的代码扫描方法。

20.一种存储介质，其特征在于，所述存储介质上存储有计算机程序，所述计算机程序在运行时，执行如权利要求1-11中的任一项所述的代码扫描方法或权利要求12-13中的任一项所述的代码提交方法。

Images