Coverity Scan - Static Analysis
前面几期介绍了Fortify及Checkmarx的使用,本期介绍另一款代码审计工具Coverity的使用,Coverity可以审计c、c++、Java等代码,使用起来非常麻烦,相比于Fortify和Checkmarx,Coverity对于代码审计工作最大的遗憾就是,Coverity要求代码完美编译(不知道有没有网友可以解决这个缺憾),而我们在日常的工作中,不太可能拿到可以完美编译的源代码,因此我不常用这个工具,这大概也是Coverity在国内使用量不如Fortify和Checkmarx的原因吧。
求助:哪位朋友有Codesecure、Klockwork、IBM Security AppScan Source的破解版或者是试用版,方便的话发我试用一下,保证不外传,保证不用于商业目的,Thanks♪(・ω・)ノ
Part2 审计Java代码过程
- 客户端使用过程
Coverity安装完成之后,双击桌面的快捷方式cov-wizard.exe可以打开一个gui界面,建议初学者可以先通过gui界面入手,熟悉之后,再从非常复杂的命令行使用入手。
首先新建一个项目名“project111”:
接下来开始配置Coverity代码审计的各项参数:
1 “工作目录”,指定你想要进行代码审计的Java代码文件夹。
2 “中间目录”,指定输出扫描结果的文件夹,为以后生成代码审计报告做准备。
3 “构建设置”,指定Java代码的编译方法。
命令行构建对于java可以用多种方法,我列举两种亲测可用的编译方法:
1. 清除:mvn clean , 构建:mvn package
2. 清除:ant clean , 构建:ant
接下来点击“下一步”,勾选相应的扫描规则,也可以按照默认勾选。
点击“高级分析选项”,可以设置“最大工作内存(MB)”,同时可以手工设置“攻击性级别”。
接下来点击“运行分析”,即可开始代码审计工作了。
点击“控制台”按钮,可以看到代码扫描的整个过程。
如下图所示,是“mvn clean”过程。
如下图所示,Coverity开始为代码分析做准备。
如下图所示,展示了各种Web漏洞对应的扫描结果。
接下来点击“中间目录详情”,可以看到代码审计结果的概况。
- Web界面的使用
客户端的完成代码扫描之后,可以将扫描结果上传到Coverity的Web端,Coverity默认的http端口是8080,https端口是8443,我们可以输入在安装过程中设置的用户名及密码进行登录。
登录成功之后会显示以下Web界面。
在“配置-项目和数据流”界面下,新建一个“数据流”,名字起为“111111”,后续可以将代码审计结果放在此“数据流”下展示。
访问如下网址,点击“创建并下载”可以生成一个auth-key.txt文件,这个文件是需要提供给客户端程序cov-analysis.exe来使用的。
https://win-iccdc05mgj6:8443/authentication-keys
- 客户端提交扫描结果
在客户端程序“Coverity Wizard”界面下,在“验证秘钥文件”处导入auth-key.txt文件,点击“测试连接”,提示“已成功连接”,说明我们的配置没问题。
接下来选择“提交到数据流”的“111111”名称,然后点击“提交缺陷”,即可将扫描结果上传到Web界面进行展示。
非常遗憾的是,之前我测试时,Web界面的使用都是可以成功的,但是现在始终显示“[ERROR] The server's certificate is not yet valid. It will become valid on 2022-12-23 06:58:26 UTC.”这个错误,如果您有解决办法,请后台留言告诉我,Thanks。正常不出错的话,代码审计结果会这样展示:
为了查看扫描报告,最后通过导出html报告的方法,在本地浏览器中,查看最终的代码审计结果报告。
1 如下图所示,这是SQL注入漏洞的结果展示。
2 如下图所示,这是Xpath注入漏洞的结果展示。
3 如下图所示,这是XSS代码漏洞的结果展示。
Part3 总结
1. 国内很多研究者,更喜欢使用Coverity进行C及C++的代码审计,它的功能很强大,就是使用起来非常麻烦,需要大家仔细研读使用说明书。
2. 大家有新版的Coverity程序,方便的话可以发我一个研究下。
3. Help: Which friend has a cracked or trial version of Codesecure, Klockwork, and IBM Security AppScan Source? If it's convenient, send it to me for trial, and I guarantee that it will not be used for commercial purposes。
///
Coverity Prevent SQS
Prevent SQS(软件质量系统)是检测和解决C、C++、Java源代码中严重缺领先的自动化方法。可以对构建环境、源代码和开发的过程给出一个完整的分析,Prevent SQS建立了获得高质量软件的标准。
静态源代码分析允许我们在软件开发生命周期的早期阶段发现和修复缺陷,节省数以百万计的相关成本,Prevent SQS是业界标准,因为只有Coverity理解和掌握静态源代码分析技术所具有的严格的要求。
检测缺陷(C/C++)
Prevent SQS源代码分析引擎利用软件DNA图谱来分析代码的各个方面。
Prevent SQS模块化缺陷检测平台能够使很多模块(或检查器)同时分析代码,查找不同类别的缺陷。
Prevent SQS预配置的库说明了作为产品的一部分的第三方库APIs和功能。
Prevent SQS针对C/C++的分析引擎
引擎
功能
路径流程引擎
通过构建一个表示经过每一个函数的所有的路径的图表分析代码中的每个函数的控制流
数据追踪引擎
用于分析从程序中每个路径中的声明收集的所有的整型和布尔型等数据
统计引擎
用于分析代码作为一个整体的行为特征
过程间调用总结引擎
一个主要的创新,是的Prevent SQS可以执行整个程序的分析,分析文件间和模块间的热河层次的复杂的调用链
类型流程引擎
用于提高C++分析中依赖于类层次关系的报告的结果的精度
虚假路径引擎
用于分析每个分支条件,以确定在当前路径它将真、假、或不确定
加速引擎
保存横越每个路径时的每个缺陷分析所收集的信息。消除冗余路径,不需要横越任何不必要的路径来找到最多的缺陷
数据传播引擎
吧过程检调用总结引擎产生的所有总结和数据追踪引擎记录的所有数据汇总起来,是Coverity特有的、上下文敏感的过程检分析能力的关键
增量分析引擎
通过缓存分析数据来提高性能,以便后续的分析仅需要包含变化的数据
解决缺陷(C/C++)
Prevent SQS内嵌的自动分发功能吧缺陷结果发给能够修复缺陷的开发人员和团队。
可处理的缺陷报告在几分钟内提供一个直观的界面和说明,而不是几小时或几天。
缺陷工作流程管理器帮助开发团队创建客户化的检测、分析、解决Prevent SQS报告的缺陷的流程。
每个缺陷的完整路径在源代码中被清洗的显示,开发人员能够快速追踪错误的根源。
缺陷的关键属性直接嵌入在源代码中,这样开发人员能够理解分析引擎用于检测错误的逻辑。
能够发现的C/C++缺陷
并发
死锁
错误使用的阻塞条用
性能下降
内存泄漏
文件句柄泄漏
定制的内存和网络资源泄漏
数据库连接泄漏
导致崩溃的缺陷
空指针引用
释放后引用
多次释放
不正确的内存分配
不匹配的数组新建、删除
不正确的程序行为
逻辑错误导致的死代码
未初始化变量
负数的无效引用
不正确的APIs使用
STL使用错误
API错误处理
C/C++安全性问题
安全编码缺陷
缓冲区溢出
整型溢出
缺失、不充分的恶意数据和字符串输入的验证
格式化字符串的不安全
SQL注入攻击
交叉站点脚本攻击
隐含的缺陷
整个系统折衷
服务拒绝攻击
优先权扩张
保密数据泄露
数据丢失
仲裁代码执行
Coverity一般是部署在企业内部的,通过https页面的方式向程序员报告扫描的安全隐患。
Coverity多次检测同样的代码(两次之间,被检测的代码有改动),不会覆盖先前的报告,即第一次检测得到的report item number还是有效的,不会被新的报告覆盖,搜索它仍然可以查看先前检测出来的问题。
Coverity虽然很强大,但其实检测也是有缺陷的,毕竟它只是个辅助工具,不能完全达到人的水平,有时报的问题是误报。
///
1.说明:Coverity代码扫描工具可以扫描java,C/C++等语言,可以和jenkins联动,不过就是要收钱,jenkins上的插件可以用,免费的,适用于小的java项目
2.这是Coverity的github地址 https://github.com/jenkinsci/coverity-plugin
3.以下是coverity在jenkins上操作 jenkins=詹金斯
安装插件使用插件管理器,重启詹金斯。
Coverity配置工具(管理詹金斯>全球工具配置)
添加Coverity静态分析工具:
添加一个或多个工具,为多个平台配置工具可以在这里管理。 命名为“默认”将优先的工具,否则可以配置工具路径(或重写)每个节点和/或工作配置。
注意:在詹金斯詹金斯2之前,全球的工具配置系统
配置Coverity全局设定(管理詹金斯>配置系统)
Coverity连接实例添加连接细节
将证书添加到存储Coverity连接用户名和密码(通过管理凭证插件)。 Coverity插件仅支持“用户名与密码”证书。
点击检查验证您的设置和Coverity用户账户权限
配置节点的特定工具(如果需要)
如果喜欢,可以覆盖默认的工具路径通过设置工具位置节点配置设置
使用的工具也可以配置每个任务配置(或重写)如果这对分布式构建更有效的体系结构
从头开始创建工作,通过创建或复制从现有的工作。
下构建中,选择添加构建步骤并选择调用Coverity捕捉构建,如果必要的。
如果没有提供调用Coverity捕捉构建,Coverity插件将透明地调用构建捕获所有构建步骤在您的构建。
下Post-build行动中,选择添加post-build行动并选择Coverity。
选择Coverity连接实例,项目和流相关的这份工作。
如果你想要的插件调用cov-build / cov-analyze / cov-commit-defects给你,请检查执行Coverity构建、分析和提交。 您可以添加额外的参数为每个这些工具,使用和配置中间目录(可选)。
如果您的构建已经调用Coverity,放任的复选框。
如果你想失败构建当缺陷被发现时,检查对应的复选框。 默认情况下所有缺陷被认为是,但您可以指定过滤器。 每个过滤器都应该匹配一个缺陷被包括。
如果你想要这个插件调用测试和测试顾问功能,检查执行Coverity测试顾问和提交。 您可以添加额外的参数和功能构建通过输入您的源代码控制(可选)配置。
构建完成后,链接Coverity缺陷可以在构建页面。
在项目页面,图与历史缺陷计数是可见的(只要超过一个构建已经完成)。
访问Coverity插件配置对话框,首先选择一个项目在詹金斯服务器,并选择配置。 Coverity-specific设置下是可用的构建和Post-build行动部分。
Coverity构建操作有以下选项:
选项描述
构建器选择将包裹的构建步骤cov-build。 注意,如果Coverity捕捉构建步骤不是添加,然后构建步骤都是包装。
Coverity post-build行动有以下选项:
选项描述
检查配置点击确认Coverity连接的连接到一个流是正确配置。
Coverity连接实例Coverity连接实例选择(从全局配置)。
项目项目包含流和获取缺陷。
流流和获取缺陷。
缺陷的过滤器选择显示缺陷分类、行动、严重程度、影响,组件,检查器,或日期首次检测到。
执行Coverity构建、分析和提交当这个选项被选中时,使用cov-build詹金斯将监控建设,运行分析,并提交缺陷Coverity连接。 各种参数可以指定优化构建过程。
执行Coverity测试顾问和提交设置测试顾问配置,覆盖配置设置特定于C / c++, c#和Java。
源代码控制配置“供应链管理”(可选)作设定,使检索源代码控制的版本历史。
失败构建如果找到匹配的缺陷构建失败如果缺陷发现通过过滤器的所有缺陷。
如果找到匹配的缺陷构建标记为不稳定构建标记为不稳定如果缺陷发现通过过滤器的所有缺陷。
构建后不获取缺陷吗选择这个如果构建缓慢或获取缺陷太多资源。
保持每个构建后中间目录构建后保持中间目录。 这只会产生影响是一个非默认选择中间目录。
隐藏的缺陷图在项目页面隐藏的缺陷图在项目页面。 这个设置可以加快页面加载时存在大量的缺陷或构建。
Coverity先进解析
Coverity插件的基本支持一些管道功能。 (https://jenkins.io/doc/pipeline/steps/coverity)
它提供了一个withCoverityEnv一步调用和包装工具coverityResults一步从Coverity连接视图检索问题。 为了使用这些步骤你需要设置Coverity工具在全球工具配置和全球配置(见Coverity连接实例开始详情)。
这个步骤将使用指定的Coverity工具安装和bin /目录添加到路径包裹的任何步骤。 这将允许管道脚本访问Coverity工具(如cov-build、cov-analyze和cov-commit-defects)直接从脚本步骤(如一个Shell脚本或Windows批处理脚本)。 同时,这个步骤提供了用户绑定Coverity连接实例信息,如主机/端口/凭证环境变量。
建议用法:
withCoverityEnv(coverityToolName: 'default', connectInstance: 'Coverity Connect Instance Name') {
// execute any coverity commands with either `sh` or `bat` script step
// (all Coverity Tools in /bin available on PATH)
// By default, Coverity Connect Instance information will be avaible in following environment variables
//
// HOST -> COVERITY_HOST
// PORT -> COVERITY_PORT
// USER -> COV_USER
// PASSWORD -> COVERITY_PASSPHRASE
//
// Users can customize all the above default environment variables
}
这将使用Coverity静态分析工具安装名为‘默认’和‘/ bin目录添加到路径范围内构建包装。
提示:使用管道语法片段的发电机withCoverityEnv确保你选择一个配置工具的安装和配置Coverity连接实例
用一个变量在脚本访问coverity工具目录中,例如:
def covHome = tool name: 'default', type: 'coverity'
sh "${covHome}/bin/cov-build --dir idir <build-command>"
// followed by other coverity commands (using "${covHome}/bin")
手动更新env。 脚本的路径
env.COV_HOME = tool name: 'default', type: 'coverity'
env.PATH="${env.COV_HOME }:${env.PATH}" // on windows node use ;
sh "cov-build --dir idir <build-command>"
// followed by other coverity commands (all in /bin available on PATH)
你也可以把withEnv与tool一步Coverity工具目录设置为任何环境变量
工具目录将解决的节点执行管道(见开始有关工具安装和每个节点位置)
注意,对于任何Coverity工具执行构建/分析/提交步骤必须共享相同的中间目录值(见Coverity分析用户和管理员指南更多细节)
这个插件提供了一个coverityResults一步将从Coverity连接配置实例检索问题,项目,和视图。 通过添加这一步的管道将包括任何结果以同样的方式发现问题构建结果管道。
使用示例:
coverityResults connectInstance: 'cov-connect', connectView: 'JenkinsPipelineView', projectId: 'my project'
使用管道语法片段发生器得到帮助选择Coverity连接实例和验证项目和视图的价值观
高级选项可以中止管道,管道或管道标记为失败不稳定,如果任何问题被发现在Coverity连接视图(使用abortPipeline,failPipeline或unstable默认值,这些选项是错误的)。
abortPipeline优先于failPipeline和failPipeline优先于unstable。
视图可以配置在Coverity连接用户界面(使用相同的用户凭证,将连接在管道运行)。 看到Coverity平台用户和管理员指南信息配置视图。
视图必须配置为一个“快照”问题:视图类型。 这可以确保最近提交问题,通过保持默认视图的“Snaphost范围”last()。
视图应该包括列“CID”,“检查”,“文件”,“功能”为了妥善记录问题/管道运行(否则就计数可能如图所示)。
视图过滤器应该配置为管道的问题提交。 一个例子将过滤的“分类”“未分类”|“等待”|“错误”或“状态”的“新”|“筛选”
视图组通过设置必须设置为“无”与一组检索问题的观点是不支持。
注意,这个管道工作步骤大大不同于自由泳post-build步骤在两个主要方面:
检索的结果是每个项目,而不是每流。
在这种情况下,多个管道(或工作)提交到多个流在相同的项目中,不同的观点必须由适当的配置过滤流。
过滤配置完全Coverity连接,而不是在詹金斯配置
这允许过滤列上没有提供在post-build步骤以及更加动态日期过滤功能。
下面的脚本使用一个Coverity静态分析工具安装命名default,配置“用户名与密码”credentialId的凭据jenkins-cov-user,名叫Coverity连接配置实例cov-connect。 Coverity连接实例有一个项目命名my project(包含一个流命名为“我的流”)和一个名为“快照”问题:视图my view。
node {
stage('Preparation') {
// checkout the source code
git `<URL to Git Repository>`
}
stage('Run Coverity') {
// use a variable for the shared intermediate directory
iDir = 'cov-idir'
withCoverityEnv(coverityToolName: 'default', connectInstance: 'Coverity Connect Instance Name') {
// run cov-build capture command
sh "cov-build --dir ${iDir} <build-command>"
// run cov-analyze command
sh "cov-analyze --dir ${iDir}"
// run cov-commit-defects command
sh "cov-commit-defects --dir ${iDir} --host ${COVERITY_HOST} --port ${COVERITY_PORT} --stream my stream"
}
// cleanup intermediate directory after commit was made (optional space saving step)
dir("${iDir}") {
deleteDir()
}
}
stage('Coverity Results') {
coverityResults connectInstance: 'cov-connect', connectView: 'my view', projectId: 'my project'
}
}
在这个例子中Coverity执行保存在一个Run Coverity阶段,为了打破Coverity命令到单独的阶段需要一个共享的中间目录。 建议使用外部工作空间管理器插件如果这是必要的(中间目录通常是大型储备/ unstash步骤)。
///
//