5 款阿里常用代码检测工具，免费用！

谁践踏了优雅 2022-09-10 15:15 234阅读 0赞

作者 | 喻阳

# **面临问题** #

在日常研发过程中，我们通常面临的代码资产问题主要分为两大类：代码质量问题和代码安全漏洞。

# **1、代码质量问题** #

代码质量其实是一个老生常谈的话题，但问题是大家都知道它很重要，却又不知道如何去提升和维护这一团队的共同财产。一方面开发人员可能为了功能及时上线，疏忽了对质量的把控，另一方面开发人员编码习惯和程序理解风格各异。

长期下来代码质量下降通常会自成因果，因为业务压力大而趋于下降，又因此开发效率下降，进一步加大业务压力，导致恶性循环。

# **2、代码安全问题** #

安全类问题往往隐藏在缺乏安全意识的编码逻辑和未经检测或维护的开源依赖组件中，难以在日常开发和代码评审中被及时察觉。

代码安全问题也可以分两个方面进行分析：

*  编码安全问题，即：安全规范类问题，通过避免不符合规范的代码进入企业代码库，减少隐私数据泄露、注入类风险、安全策略漏洞的出现。
 *  依赖安全问题，即：开源依赖三方组件引入的安全漏洞。根据 Synopsys 2020 开源安全报告显示，99%以上的组织使用了开源技术。使用开源组件本身带来的技术交流和站在巨人肩膀上协作、降低开发成本、加快迭代周期、提高软件质量等优势已经不必赘述，但是，开源软件带来一系列便利的同时，也暗藏大量安全风险，据审计，75%的代码库存在安全漏洞，其中 49%包含高危问题，另外 82%的代码库仍在使用超过 4 年的 outdated 组件。

代码安全类问题，一方面也需要进行准入性检查，根据业务场景和规范配置安全编码规范检测和卡点。另一方面需要定期维护，对于新爆发出的安全漏洞进行及时察觉并修复。

# **5 款阿里常用代码监测工具推荐** #

## **1、代码质量检测** ##

###  ###

*  Java 代码规约检测

阿里巴巴在实践过程中，各个组织由于历史隔阂和业务风格差异，工程结构差别很大，代码风格迥异，规范不一，沟通成本大，合作效率低，维护成本高。集团发展到现在的规模，需要专业化的技术集团军迭代式、集约式发展，而不是动辄重复造轮，而真正专业化的团队一定会有统一的开发规约，这代表效率、共鸣、情怀、可持续。

基于上述背景，阿里制定了《阿里巴巴 Java 开发手册》，作为阿里内部 Java 工程师所遵循的开发规范，涵盖编程规约、单元测试规约、异常日志规约、MySQL 规约、工程规约、安全规约等。这是近万名阿里 Java 技术精英的经验总结，并经历了多次大规模一线实战检验及完善。

制订交通法规表面上是要限制行车权，实际上是保障公众的人身安全。试想如果没有限速，没有红绿灯，没有靠右行驶条款，谁还敢上路。同理，对软件来说，开发规约绝不是消灭代码内容的创造性、优雅性，而是限制过度个性化，推行相对标准化，以一种普遍认可的方式一起做事。

因此，代码规约的目标是：1、码出高效：标准统一，提升沟通效率和研发效能。2、码出质量：防患未然，提升质量意识和系统可维护性，降低故障率。3、码出情怀：工匠精神，追求极致的卓越精神，打磨精品代码。

代码规约通过 IDE 检测插件、流水线集成测试、代码评审集成等工具手段，深度融入了阿里巴巴的各种开发活动中。与此同时，在云效代码托管平台 Codeup 中，也内置集成了 Java 代码规约检测能力，为开发人员在代码提交和代码评审阶段提供更为方便的快速检查。

*  代码智能补丁推荐

缺陷检测和补丁推荐几十年来一直是软件工程领域的难题，又是研究者和一线开发者最为关心的问题之一，这里讲的缺陷不是网络漏洞、系统缺陷，而是隐藏在代码中的缺陷。帮助开发者识别这些缺陷，并进行修复，能够大幅提升软件质量。  
基于业界和学术界较为流行的缺陷检测手段，并分析和规避其局限性，阿里巴巴 Codeup 的算法工程师们提出了一种新的算法，实现更加精准和高效的分析代码缺陷并推荐优化方案，该算法已被国际软件工程大会（ICSE）收录。  
![1.jpg][]  
1、根据 commit message 中的关键词找出修复型的 commit，只取涉及文件小于 5 个的 commit（涉及文件过多的 commit 可能会稀释修复行为）。这个步骤十分依赖开发者良好的 commit习惯，希望开发者能用好 commit，写好 message。

2、从这些修复型 commit 中以文件级别提取删除内容和新增内容，即 Defect and Patch pairs(DP Pair)，这一步难免会有很大的噪声。

3、利用改进的 DBSCAN 方法对 buggy 和 patch 对同时聚类，将相似的缺陷和补丁代码聚在一起。（也可以做片段级的聚类）通过将相似的缺陷和修复做聚类，减少了上一步留下的大量噪声，同时历史代码提交中大家共同犯过的错具有很强的借鉴意义。

4、利用自研的模板提取方法总结缺陷代码和补丁代码，并根据不同的变量来适配上下文。

代码补丁推荐服务目前应用于合并请求的代码自动扫描场景，在代码评审过程中检测可优化代码片段并给出优化建议，将历史评审中的人工经验沉淀下来持续提升企业代码质量。

## **2、代码安全检测** ##

*  敏感信息检测

近年来，业内发生多起敏感信息（API Key、Database credential、OAuth token 等）通过某些站点被无意识地泄露出去的事件，给企业带来了安全风险，甚至直接的经济损失。

在我们的实践过程中，我们也面临了类似的问题，硬编码问题出现非常高频，而又缺乏有效的识别机制。因此开发者和企业管理者亟需一款稳定健全的敏感信息检测方法和系统。通过调研我们了解到，目前已有的敏感信息检测工具大多单纯使用规则匹配或信息熵技术，导致其召回率或准确率难以满足预期。因此我们在规则匹配和信息熵技术的基础上，结合上下文语义，提出了一款采用多层检测模型的敏感信息检测工具——SecretRadar。  
![2.jpg][]  
SecretRadar 的技术实现思路主要分为三层，第一层采用规则匹配这种传统敏感信息识别技术，规则匹配具有良好的准确度和扩展性，但是非常依赖比较固化的长度、前缀、变量名，难以应对不同开发者的不同编码风格，容易造成漏报。针对难以固定规则捕捉的场景，在第二层我们采用了信息熵算法。信息熵算法用于衡量代码行混乱程度，对随机生成型密钥和随机身份信息识别效果良好。但信息熵算法也有其局限性，召回率提升的同时误报也增多了。因此在第三层我们采用了模板聚类和上下文语义分析等方法进行过滤优化，针对信息熵结果聚合提取常见关键字，结合上下文语义和当前语法结构提升模型准确率。

敏感信息检测工具不止服务我们内部开发同学，在云效平台上也支持了超过 2 万代码库、3 千家企业，帮助开发者解决了超过 9 万硬编码问题。

*  源码漏洞检测

阿里巴巴采用 Sourcebrella Pinpoint 源伞检测引擎，进行源码漏洞检测，主要涉及到注入类风险和安全策略类风险检测。

源伞检测引擎是香港科技大学 Prism 研究组在过去十年的时间内的技术研究成果。该引擎吸收了国际上近十年的软件验证技术研究成果，并且加以改进和创新，独立设计和实现了一套技术领先的软件验证系统。其主要验证方式是将编程语言翻译成一阶逻辑和线性代数等数学表达，通过形式化验证技术推理缺陷成因。迄今为止，一共发表了四篇核心技术相关的论文，一篇 PLDI 和三篇 ICSE，研究型的同学可以点击文末链接阅读。  
源伞检测引擎能够在活跃度比较高的大型开源项目中发现隐藏超过 10 年的缺陷，以 MySQL 检测 \[5\] 为例，这些缺陷都是市面上其他检查工具无法扫描出来的，并且能够在 1.5 小时完成 200 万行大型开源项目的检测。在保持扫描的高效率同时，还能够将误报率控制在 15%左右。对于复杂且体量庞大的分析项目来说，源伞检测引擎所表现的扫描效率和误报率在业内也处于领先水平。

「源码漏洞检测」集成了源伞检测引擎的安全分析能力，能够在分析精度、速度、深度等方面均衡得到较好的分析结果，具备的核心优势：

1、支持分析字节码，二三方包的代码逻辑都不会遗漏；  
2、擅长跨函数长调用链路的逻辑分析；  
3、可以处理引用、指针等带来的间接数据修改；  
4、精度高，相比于同类工具，如 Clang、Infer，在精度和有效问题识别上表现更佳；  
5、性能好，目前单应用平均 5 分钟左右分析完毕；  
![3.jpg][]  
源伞检测引擎可以精确的追踪代码中的数据流向，拥有高深度高精度的函数调用链分析能力，可以找到跨越多层函数的深度问题。在发现缺陷的同时还能给出问题触发的过程，完整展示相关的控制流以及数据流，这样可以辅助开发者快速理解和修复问题，在软件开发早期更低成本地提高软件质量，大幅减少生产成本，提高研发效能。

*  依赖包漏洞检测

我们期望对于开源组件的安全可信程度，为开发者建立一种有效的检测和管理机制，因此我们实现了依赖包漏洞检测服务和依赖包安全问题报表。在实践过程中，开发者普遍反映依赖包漏洞修复成本大多高于修复自身编码漏洞，从而不愿意或难于处理此类问题。究其原因，一方面是大部分漏洞并非直接引入，而是依赖的第三方组件又间接依赖了其它组件，另一方面是不确定具体哪个版本是干净可用且兼容的。  
![4.jpg][]  
为了降低开发者的修复难度，我们对依赖项的引用关系进行了进一步识别分析，清晰的标注出直接依赖和间接依赖，并定位到具体的依赖包引入文件，方便开发者快速找到关键问题位置。同时，通过对漏洞数据的聚合，智能推荐修复漏洞的版本升级建议，因为一个依赖可能对应多个漏洞问题，开发者可以针对建议评估是否接受采用。通过分析不同版本间的 API 变更和代码调用链路，衡量版本升级成本，为开发人员自动创建修复评审，最大程度的帮助开发人员更高效地维护代码安全。

\*\*无论是代码质量检测还是代码安全检测，以上 5 款阿里代码自动检测工具，开发者们都可以在云效 Codeup 内免费体验。

# **检测服务应用** #

## 1、代码提交 ##

检测服务的最直接的应用便是在代码提交场景中，企业可以根据业务场景和规范，制定和配置不同项目的检查方案。当开发者将代码变更推送至服务端，自动触发当前代码库配置的检测服务，可以为开发者检查当前 commit 版本中的全量问题，帮助开发者及早发现新增问题，并确认存量问题的解决情况。通过接入上述检测服务，可以从代码规范、代码质量、代码安全等多个维度进行测试左移，在开发人员刚完成编码时就进行快速检测和反馈。

## 2、代码评审 ##

在企业项目协同中，开发者多以合并请求的方式将特性分支代码合入主干分支，合并请求过程需要项目开发负责人或模块负责人进行代码评审和人工检查。一方面人工审查代码需要投入较大精力，另一方面人工审查难以覆盖代码各个维度的潜在问题。因此，通过合理配置检测服务，可以极大地减少人工评审的工作量，加速代码评审的工作过程。同时，通过丰富、筛选、沉淀检测规则集和人工经验，检测服务可以更加贴合企业的业务场景进行卡点，避免不符合规范或存在风险的代码进入企业代码库。

###  ###

## 3、代码度量 ##

检测服务除了在代码提交和代码评审阶段帮助开发者及早发现问题并解决问题，还可以帮助管理者进行企业代码质量度量和风险可视化。通过建设企业级报表服务和项目任务管理，可以更为直观地度量项目演进过程中的安全问题和质量问题。****

# **扩展阅读** #

1.  Pinpoint: Fast and Precise Sparse Value Flow Analysis for Million Lines of Code   
    [http://t.tb.cn/0qxIpFV5sRD5uxOcgED7o][http_t.tb.cn_0qxIpFV5sRD5uxOcgED7o]  
    
2.  SMOKE: Scalable Path-Sensitive Memory Leak Detection for Millions of Lines of Code   
    [http://t.tb.cn/2l96Jh2yqOGowsfs4oVk2m][http_t.tb.cn_2l96Jh2yqOGowsfs4oVk2m]  
    
3.  Pipelining Bottom-up Data Flow Analysis  
    [https://qingkaishi.github.io/public\_pdfs/ICSE2020a.pdf][https_qingkaishi.github.io_public_pdfs_ICSE2020a.pdf]  
    
4.  Conquering the Extensional Scalability Problem for Value-Flow Analysis Frameworks   
    [https://qingkaishi.github.io/public\_pdfs/ICSE2020b.pdf][https_qingkaishi.github.io_public_pdfs_ICSE2020b.pdf]  
      
    ****

# **活动推荐** #

![代码捉虫-PC.jpg][-PC.jpg]  
**5 款阿里常用代码检测工具免费体验，仅需 2 步，Cherry键盘、公仔抱回家，100%拿奖！**  
都 2021 年了，你还认为代码检测=语法/风格扫描？

大厂每年数百万采购的扫描软件，都在采购什么？如何不花钱白嫖？

落地 DevOps 的第 2 步是什么？

什么是接入成本最低的质量和安全提升工具？

\*\*云效 DevOps 实验室特推出【1 分钟代码自动捉虫】活动  
**1-3 分钟，给你的代码做个全身体检吧。**

体验完成，还可抽 Cherry 机械键盘、阿里云定制 GIt 命令鼠标垫、积木星球等，1000 分礼品，100%中奖！****

**点击下方链接**，立刻参与活动！*注：本活动仅限云效新用户参加*[https://developer.aliyun.com/adc/series/activity/bugdetect][https_developer.aliyun.com_adc_series_activity_bugdetect]

[1.jpg]: /images/20220829/c8fc8f95dacb4825a3fc7a4c746c27dd.png
[2.jpg]: /images/20220829/98e042cd96054aa784eb1240b4903e6e.png
[3.jpg]: /images/20220829/3b0ad326bb4f49e08d6a6748a31c09d9.png
[4.jpg]: /images/20220829/8334ece2f58d447a9efb096e726bfb13.png
[http_t.tb.cn_0qxIpFV5sRD5uxOcgED7o]: http://t.tb.cn/0qxIpFV5sRD5uxOcgED7o
[http_t.tb.cn_2l96Jh2yqOGowsfs4oVk2m]: http://t.tb.cn/2l96Jh2yqOGowsfs4oVk2m
[https_qingkaishi.github.io_public_pdfs_ICSE2020a.pdf]: https://qingkaishi.github.io/public_pdfs/ICSE2020a.pdf
[https_qingkaishi.github.io_public_pdfs_ICSE2020b.pdf]: https://qingkaishi.github.io/public_pdfs/ICSE2020b.pdf
[-PC.jpg]: /images/20220829/159d247c28c647c0b25bb3774b6b9c14.png
[https_developer.aliyun.com_adc_series_activity_bugdetect]: https://developer.aliyun.com/adc/series/activity/bugdetect