2021-07-13

滴滴~这家公司保护数据和隐私安全有点东西

随着我国互联网产业的蓬勃发展和超级平台的相继涌现,互联网对国民经济和人民生活的影响愈加深广。网络安全、个人隐私安全也越来越受到政府和网民的重视。想必大家都知道近日的滴滴事件。7 月 2 日晚,依据《中华人民共和国国家安全法》《中华人民共和国网络安全法》,网络安全审查办公室按照《网络安全审查办法》,对“滴滴出行”实施网络安全审查。随后公告称,“滴滴出行” App 存在严重违法违规收集使用个人信息问题,责令下架。滴滴事件我们未掌握足够信息不便评论,相信政府一定会合理、公正地进行处理。但对于网络安全和用户隐私的保护,鸿渐一直在努力。我们基于机器学习的移动应用隐私评级,应用前沿隐私泄露检测技术,帮助政府监管部门更好地保护用户隐私数据。而对企业来说,合法合规运营,才是健康、长久、高质量发展的坚实保证。当前,移动平台上广泛存在权限滥用问题。很多不法应用会在用户不知情的情况下,获取并泄露用户信息。为实现基于用户期望对应用的敏感行为进行隐私评分,我们基于数据源中用户对不同的<应用,权限,意图>组合的评分,使用机器学习技术、静态分析技术建立准确的隐私评级预测模型。实验结果表明,鸿渐隐私评级模型检测准确率高达 90.2%。我们通过对 17 个应用市场中数十万个应用进行分析,检测到大量隐私风险应用。虽然现在我国隐私保护之路依然任重道远,但相信随着国家相关法规的制定实施,以及政府和人民网络安全和隐私保护意识的提高,我国网络空间一定会越来越安全、规范、和谐。鸿渐科技愿在此过程中贡献自己的绵薄之力。

2021-06-25

8款国内外代码分析工具对比测试,来看哪一款适合你

       最近,鸿渐科技启动了关于SDL和开发安全的代码分析工具项目。调研了很多产品的功能及POC,下面分享一些调研心得,希望对大家有所帮助:1、百度搜索百度搜索“代码分析工具”,虽然发现不少相关工具,但其数据准确性还有待商榷,且具体功能也需进一步POC。2、开源工具我们研究过findbugs[1]的sec版、sonar[2]和cobra[3]等开源工具。它们虽然使用起来方便高效,但达不到项目要求的安全标准。不过测出的严重问题并不多。3、商用产品POC范围确认根据Gartner和国内权威第三方调研机构的调研,我们选出了若干获得普遍认可的工具,如国外的Fortify[4]、checkmarx[5]、Klocwork[6]和Coverity[7],国内的代码卫士[8]、Wukong[9]、鸿渐SAST[10]和酷德啄木鸟[11]。        根据项目需求,我们亦针对上述产品做了POC,汇总如下:表1:国外产品对比(含鸿渐SAST)注:国外工具1-4为Fortify、checkmarx、Klocwork和Coverity中的某一款,排序无对应关系。表二:国内产品对比注:国内工具1-3为代码卫士、Wukong和酷德啄木鸟中的某一款,排序无对应关系。       大家若想选出合适的工具产品,首先要根据项目需求确定供应商范围,然后再根据POC测试数据进行最终工具确定。以下是通过这次调研,我们总结的一个确定供应商的方法,供大家参考:       通过此次调研,我们发现越来越多优秀的国产工具开始崭露头角,尤其是像鸿渐科技的代码扫描工具SAST[12],目前已达国内领先,国际先进水平。通过POC结果看,也完全能支撑项目的大部分需求。相信随着它进一步迭代发展,达到国际领先,指日可待。       贸易战以来,美国对我国的打压已扩大到科技领域。国产替代的趋势亦逐渐盛大。“青山遮不住,毕竟东流去。”,相信中国必将突破外部封锁,驶入浩瀚大洋扬帆远航。国内代码分析企业也将迎来自己的高光时刻。以上就是这次调研的分享,大家有什么想法欢迎留言讨论哦。 参考资料:[1] http://findbugs.sourceforge.net/[2] https://www.sonarqube.org/[3] http://cobra.feei.cn/[4] https://www.joinfortify.com/[5] https://www.checkmarx.com/[6] https://www.perforce.com/products/klocwork[7] https://scan.coverity.com/[8] https://www.qianxin.com/[9] https://www.woocoom.com/[10] http://www.redrocket.cn/[11] http://www.codepecker.com.cn/[12] http://www.redrocket.cn/Home/Product_introduction/index.html?id=2

2021-06-24

重磅|鸿渐科技入选《中国网络安全百强报告(2021)》创新黑马

2021年6月16日,国内数字化产业第三方调研与咨询机构数世咨询正式发布了《中国网络安全百强报告(2021)》(以下简称百强报告)。鸿渐科技凭借其完全自主研发,技术自主可控的代码检测,源代码分析等技术,有幸入选了创新能力百强【业务场景】—【开发安全】代码检测领域的创新黑马。入选结果展示

2021-06-11

Java 静态代码分析工具-OWASP基准测试测评篇

Java 静态代码分析工具-OWASP基准测试测评篇一 背景源代码静态分析工具(SAST)作为软件安全的重要保障工具,已经在各个领域被广泛使用。随着开源SAST工具的广泛使用,工具种类的增加,使用者很难判断工具的优劣及适不适合企业的应用场景,本文从金融、互联网企业最常用的Java语言代码分析的角度,对静态分析进行一次简要的测评,为大家选择静态分析工具提供依据,此外,本文分析了目前静态代码分析工具存在的技术问题及工具评估的基本准则。二 概述一般来说,误报和漏报率是SAST最重要的技术评价指标,但由于没有通用意义上的测试集能够全面反应静态分析工具在检测精度能力方面高低暨分析的敏感度。由此,为了简化测试难度,本次测评我们选择了一个Java语言且偏安全的国际通用测试集OWASP benchmark,以反应代码分析工具在Java安全检测能力上的强弱。OWASP基准测试是一个示例应用程序,其中包含来自11个类别的数千个漏洞。基准测试中包括很难通过静态分析处理的代码片段,例如:间接调用、不可达分支、映射、依赖于配置文件的值。用例下载地址:https://github.com/OWASP/Benchmark/releases,可以在一定程度上反应代码分析工具的检测能力。1. 测试依据下表为某款工具的OWASP检测结果,如图所示,左侧一列表示所有类别,P/N为正/负样本数(badcase/goodcase),TP/FP为真/假阳性的数量(badcase报出数/误报数),TN/FN是真/假阴性的数量(good case报出数/漏报数),TPR和FPR是正确率和误报率,Y是约登指数,约登指数( Youden’s indx,YI)即正确指数,此指数值的范围只从0~1,约登指数越大, 其真实性亦越好。其中TPR、FPR、Y的计算公式如下:TPR=TP/PFPR=FP/NY=[TP/(TP+FN)+TN/(FP+TN)]-1类别PNTPFPTNFNTPRFPRYCommand Injection (cmdi)126125126458001.00.360.64Weak Cryptography (crypto)130116130011601.00.01.0Weak Randomness (hash)129107129010701.00.01.0LDAP Injection (ldapi)273227131901.00.410.59Path Traversal (pathtraver)133135133369901.00.270.73Secure Cookie Flag securecookie)36313603101.00.01.0SQL Injection (sqli)2722322728714501.00.3750.63Trust Boundary Violation (trustbound)834383241901.00.560.44Weak Randomization (weakrand)218275218027501.00.01.0XPATH Injection (xpathi)15201571301.00.350.65Cross Site Scripting (xss)2462092464816101.00.230.77Average All141513251415290103501.00.230.772. 测试结果 选取市场上主流的SAST工具进行测试,本次选取的测试工具涵盖较广,包含国外商业工具、开源工具以及国内自研工具。如SonarQube[1]代码自动审查工具,该工具是开源工具中使用最多的工具,因为开源免费尤其受很多金融企业喜爱;以色列的Checkmarx CxSAST[2],Micro Focus Fortify[3],目前在电力、金融等行业推广较多,是中国市场Java应用最多的工具之一;还有在互联网领域应用的比较广泛的新思科技的Coverity[4]、IBM Appscan[5]。军工领域应用比较广泛的Parasoft的JTest[6]、VeraCode[7]等。国产的我们采用的是北京鸿渐科技的SAST工具[8],其研发团队来自北京大学,是目前国内较少拥有自主可控技术的工具之一。下图是10款静态分析工具的OWASP基准测试结果。商业SAST工具01-06包括:Checkmarx CxSAST、Micro Focus Fortify、IBM AppScan Source、Coverity Code Advisor、Parasoft Jtest、SourceMeter[9]和Veracode工具。分析工具OWASP版本TPRFPRYFBwfindSecBugs[10]1.20.970.580.39SonarQube1.20.50.170.33鸿渐SAST1.21.00.120.88SAST-041.10.610.290.33SAST-061.10.850.520.33SAST-021.10.560.260.31SAST-031.10.460.2140.25SAST-051.10.480.290.19SAST-011.10.290.120.17PMD1.20.000.000.00从上图可知,覆盖率指数最大为1(即100%覆盖,不存在漏报);而误报率最低的指数为0.12,最高为0.58,尚无。三 技术分析静态代码分析基本原理:首先将源代码解析为抽象语法树;采用控制流分析、多态分析、指向分析、函数调用分析等多种分析算法对基本分析模型;考虑路径敏感等多种情况,建立符号执行、抽象解释、图可达性等程序模型;根据缺陷模式在程序模型的基础上生成一阶逻辑表达式并采用SMT进行可满足性约束求解,生成最终结果。目前很多工具只做基本分析层面,尤其是开源工具,针对全模式的敏感分析很多工具并不支持,或支持的不好,因此可能产生大量的误漏报,下面分析了几种典型的问题:基于以上要点,分析误报原因,了解工具的局限性。通过分析,误报基本由以下几种情况导致。1. 集合覆盖问题。在集合中,部分集合数据存在污染数据,当检索集合中未污染部分时,导致整个集合覆盖污染,误报产生。如:以下代码中,map中填充带有一个污点(param)和一个未污点的值(a_value),并且从映射中检索参数赋值给bar。如果一个集合的一部分被污染了,假设整个collection都被污染,那么在本例中,当我们检索集合的未污染部分时,导致误报。 private class Test { public String doSomething(String param) throws ServletException, IOException {       String bar = "safe!";       java.util.HashMap<String,Object> map831 = new java.util.HashMap<String,Object>();       map831.put("keyA-831", "a_Value"); // put some stuff in the collection       map831.put("keyB-831", param); // put it in a collection       map831.put("keyC", "another_Value"); // put some stuff in the collection       bar = (String)map831.get("keyB-831"); // get it back out       bar = (String)map831.get("keyA-831"); // get safe value back out       return bar;    } } // end innerclass Test2. 集合过度污染问题。在一个集合中,部分集合数据存在污染数据,当对集成做一些操作后,工具无法识别出受污染的数据,导致其他正常数据收到影响,产生误报。如:在以下代码中,存在一个未受污染的值(safe),一个受污染的值(param) 和另一个未受污染的值 (moresafe) 被添加到列表中。 当第一个值“safe”被删除后,从列表的开头,检索索引为 1 的列表元素,即读取未受污染的值“moresafe”。同样导致误报。 public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {  response.setContentType("text/html");  String param = "";  boolean flag = true;  java.util.Enumeration<String> names = request.getParameterNames();  while (names.hasMoreElements() && flag) {  String name = (String) names.nextElement();     String[] values = request.getParameterValues(name);  if (values != null) {  for(int i=0;i<values.length && flag; i++){  String value = values[i];  if (value.equals("vector")) {  param = name;     flag = false;  }  }  }  }   String bar = "alsosafe";  if (param != null) {  java.util.List<String> valuesList = new java.util.ArrayList<String>( );  valuesList.add("safe");  valuesList.add( param );  valuesList.add( "moresafe" );   valuesList.remove(0); // remove the 1st safe value   bar = valuesList.get(1); // get the last 'safe' value  }   String cmd = org.owasp.benchmark.helpers.Utils.getInsecureOSCommandString(this.getClass().getClassLoader());  String[] args = {cmd};         String[] argsEnv = { bar };         Runtime r = Runtime.getRuntime();  try {  Process p = r.exec(args, argsEnv, new java.io.File(System.getProperty("user.dir")));  org.owasp.benchmark.helpers.Utils.printOSCommandResults(p, response);  } catch (IOException e) {  System.out.println("Problem executing cmdi - TestCase");             throw new ServletException(e);  }  }3. 分支问题。在条件分支中,由于条件设置问题,导致某些分支可能永远无法执行,若工具无法判定某些无法执行的分支,可能导致误报的产生。如:在以下代码中,因为num为常量106,(7*18)+num的值永远大于200,导致bar的值始终都为常量字符串:“This_should_always_happen”。另外一个包含污染数据的分支“param”永远无法执行。导致工具产生误报。 private class Test { public String doSomething(String param) throws ServletException, IOException {    String bar;// Simple ? condition that assigns constant to bar on true condition    int num = 106;    bar = (7*18) + num > 200 ? "This_should_always_happen" : param;    return bar;  } }四 结论全面、高效地静态识别漏洞,减少工具的误报是静态分析中至关重要的技术,目前在该领域中,仍然有很大的进步空间。针对本次OWASP的基准测试,在选取的工具中,目前结果最好的工具覆盖率可以达到100%,且同时误报率为12%,也说明了工具正不断趋于成熟,但该结果仅针对OWASP测试用例。在后续的静态代码分析技术中,需要不断对静态数据流跟踪器进行持续优化,以此提高检测精度。为了更好地对代码分析工具进行评价,笔者提出了几个评价维度,并给出评价等级评价指标描述Level 1Level 2Level 3约登指数查全率-误报0.9-1.00.7-0.90.7-吞吐量最大检测代码规模1000W+100W+10W+检测效率每小时代码检测代码行数100W+50W+10W+片段代码检测能力能否在编译不通过情况下检测支持所有语言C/C++,Java不支持并发检测能力支持单CPU的多并发测试硬件允许的最大值单进程单进程跨语言及框架分析能力支持最新的框架及兼容语言间调用支持70种以上框架支持10种以下不支持支持语言支持检测的语言种类20种+10种+3种+与Devops集成能力是否与DevOps主要工具集成支持持续集成工具、版本管理及测试工具,三个方面仅支持版本管理不支持CWE模式覆盖数覆盖的缺陷模式个数200+100+50+

2021-04-27

软件质量指标自动度量方法

通过设定衡量代码质量的八个度量项来对软件的质量进行量化打分,其设定度量项的标准参考了定义软件质量的ISO25010标准。这篇文章结合我们多年的实践,将给大家介绍一下如何通过ISO25010标准来制定以下的质量指标。质量指标    30年多年前,软件工程师Barry Boehm已经发现,如果在软件发布后发现缺陷,修复缺陷的成本会成倍增加。因此,如果能够在软件发布前有一种方法来衡量软件的代码质量,它将潜在地节约大量的成本。一个定义软件代码质量的ISO25010应运而生,这个标准定义了八个主要质量指标和许多子指标。八个主要质量指标为:功能适用性 (Functional suitability):软件所实现的功能达到其设计规范和满足用户需求的程度,强调正确性、完备性、适合性等。可靠性 (Reliability):在规定的时间和条件下,软件所能维持其正常的功能操作、性能水平的程度/概率,如成熟性越高,可靠性就越高;用MTTF (mean time to failure,平均失效前时间) 或MTBF(mean time Between failures,平均故障间隔时间)来衡量可靠性。效率 (Performance efficiency):在指定条件下,软件对操作所表现出的时间特性(如响应速度)以及实现某种功能有效利用计算机资源(包括内存大小、CPU占用时间等)的程度,局部资源占用高通常是性能瓶颈存在;系统可承受的并发用户数、连接数量等,需要考虑系统的可伸缩性。可操作性 (Operability):对于一个软件,用户学习、操作、准备输入和理解输出所作努力的程度,如安装简单方便、容易使用、界面友好,并能适用于不同特点的用户,包括对残疾人、有缺陷的人能提供产品使用的有效途径或手段(即可达性)。安全性 (Security):要求其数据传输和存储等方面能确保其安全,包括对用户身份的认证、对数据进行加密和完整性校验,所有关键性的操作都有记录(log),能够审查不同用户角色所做的操作。它涉及保密性、完整性、抗抵赖性、可核查性、真实性。兼容性 (Compatibility):涉及共存和互操作性,共存要求软件能给与系统平台、子系统、第三方软件等兼容,同时针对国际化和本地化进行了合适的处理。可维护性 (Maintainability):当一个软件投入运行应用后,需求发生变化、环境改变或软件发生错误时,进行相应修改所做努力的程度。它涉及模块化、复用性、易分析性、易修改性、易测试性等。可移植性 (Transferability):软件从一个计算机系统或环境移植到另一个系统或环境的容易程度,或者是一个系统和外部条件共同工作的容易程度。它涉及适应性、易安装性、易替换性。ISO25010标准有助于在软件初期阶段评估质量。然而,它有两个主要缺点: 标准没有规定如何测量质量属性。一些质量属性甚至似乎不适合客观测量。以“可操作性”为例, 其子属性如“界面友好”和“易用性”。如何测量这个,测量单位是什么?大多数定义的质量属性在不同的环境中具有不同的含义。因此,即使可以测量质量属性,也很难找到判断是好或坏的明确客观标准。“效率”就是这种情况的一个很好的例子。一些软件系统在1秒内做出响应就足够了,而另一些软件系统则要求在1毫秒内做出响应。 为了对软件质量进行系统的评估,经过多年的行业经验积累,制定出可以进行量化处理的八个度量项,它们分别是: 1.代码覆盖率2.抽象解释 3.圈复杂度4.编译器警告5.编码标准 6.重复代码7.扇出 8.安全这八个度量项基于ISO25010制定,其量化数值和软件质量属性有一定的映射关系,具体如下。1. 代码覆盖率在软件工程师将他们的代码移交到软件开发周期的下一个阶段之前,他们通常做一些单元测试。这些是小规模的自动化测试,可以检查程序的特定部分,例如单个函数,然后将这些自动化测试的实际结果与预期结果进行比较。单元测试是用来检查程序能否实现设计想达到的目的最低标准的一种有效的测试方法。代码覆盖率表示在单元测试运行期间,代码中有多少行代码或可执行分支被测试。覆盖率越低,所执行的单元测试的质量就越低。代码覆盖率是“功能适用性”和“可靠性”的一个度量指标。下面的C#代码展示了用代码覆盖率检测工具输出的一个简单示例。每一行颜色为“绿色”的代码都经过至少一次测试,而“红色”行的代码没用经过任何测试。      代码覆盖率测试工具的输出显示,除第37行外,此代码示例中的所有行都由(单元)测试覆盖。2. 抽象解释 现在有一种通过运行抽象解释工具(也称为深流分析工具)来检测软件程序中可能存在的“可靠性”问题的新技术。这些工具能够自动检测与程序控制流程相关的各种编程错误。例如空指针解引用、除零和未关闭的数据库连接。这些工具的优点是它们在不实际运行程序的情况下就能产生结果,这是通过以计算程序所有可能的路径来完成的。抽象解释发现的错误是严重的编程错误,可能导致崩溃。这个度量项和程序“可靠性”属性息息相关。关于抽象解释问题的一个简单示例展示在下面的Java代码中。 抽象解释工具将在第228行标记一个可能出现的空指针解引用缺陷,因为函数“get Order”会在订单没有有效日期的情况下返回NULL。如果发生这种情况,将抛出异常,可能导致程序崩溃。3. 圈复杂度圈复杂度是最经典的软件度量项之一。圈复杂度在数量上表现为独立现行路径条数。例如,每个“if”语句就会添加了一条额外的代码路径。圈复杂度越高,程序代码的判断逻辑就越复杂。此外,路径越多,就需要编写更多的测试用例来实现更高的代码覆盖率。每个函数的平均圈复杂度是一个指标,可以比较程序之间的复杂性。圈复杂度在一定程度上展示了程序代码的“可维护性”。下面以一段C#代码为例展示如何计算圈复杂度。  函数“get Value”在第123行的圈复杂度为2(因为包含一条“then”路径和一条“else”路径”)。4. 编译器警告为了在计算机上执行软件程序,首先需要经过编译或解释。编译器或解释器会生成错误和警告而且错误必须修复,否则程序无法运行。警告虽然不一定需要解决,但是一些编译器警告表明程序存在严重缺陷。留下这些未解决的问题可能会影响代码的“可靠性”。除此之外,大多数编译器警告还体现了“可移植性”问题。因此,这个度量项和软件程序的“可移植性”也有很强的关联。下面是关于编译器警告在C语言代码片段的一个简单示例。 大多数编译器会在第32行的if条件下发出警告(可能是为了进行比较的原因)。5. 编码标准软件维护是软件工程师最耗时的任务之一。其原因之一是经过多次更新后,软件工程师很难理解程序代码编写原本的意图。降低软件维护成本的一种方法是引入编码标准。编码标准是代码工程师应该遵循的规则。这些编码规则涉及已知的语言缺陷、要避免的代码构造,还涉及命名约定和程序布局。由于编码标准通常包含许多不同的规则,所以它们可以反应大多数代码质量属性问题。大多数规则涉及“可维护性”和“可靠性”,但也有可用于“可移植性”和“效率”的规则。下面是一个违反编码标准的示例。任何C编码标准都不推荐第36行使用的goto语句。6. 重复代码有些时候软件工程师会复制大量现成代码并对其进行一些小的修改而不是重新编写。大量重复代码的缺点是,如果出于某些原因(修复bug或添加丢失的功能)必须更改代码的一部分,那么其他重复的代码也很可能需要更改。一旦有所疏忽,重复的大量代码将产生巨大的工作量。这非常影响程序的“可维护性”。 7. 扇出软件程序通常是由模块或组件构造的。这些模块和组件存在层次调用的情况。扇出表示某个模块使用的下级模块的个数。如果模块需要许多其他模块才能正确运行(高扇出),那么模块之间就有很高的相互依赖性,这使得代码更难修改。因此,扇出在一定程度上反映了软件程序的“可维护性”。下面的Java代码显示了一个高扇出的示例。 在这段代码中,我们采用了扇出的简单定义来度量import语句。因此,上面Java文件的扇出数量是16。 8. 安全软件的安全性反应了在未获得授权的数据访问时软件程序有多容易被攻击,以及利用安全漏洞对软件进行更改的难易程度。这种安全漏洞的例子有缓冲区溢出(让程序崩溃)和敏感数据的暴露(从而给用户提供信息以获得未经授权的访问)。下面的C代码给出了一个安全泄漏的示例。  在第319行,一个非常长的字符串被写入一个名为“buf”的数组,该数组只能容纳8个字符。不适合“buf”的字符被保存在其他地方,可能会覆盖应该执行程序的代码。通过利用这个漏洞,攻击者可以运行另一个程序,而不是运行的本来的程序。修正后的例子是下图。   通过使用“snprintf”而不是“sprintf”,写入缓冲区的字符数受到第二个参数的限制。以上就是给出的八个度量项,从上文可以发现一些度量项可以很容易地映射某些质量属性。例如,如果一个文件的代码重复率为0%,那么这被认为是质量较高的一段代码,而如果重复率是50%,那会被认为是糟糕的编程。然而,对于八个度量项中的四个,“抽象解释”、“编译器警告”、“编码标准”和“安全”并没有和质量属性间存在非常明确的对应关系。例如,如果代码中有3000个编码标准问题,那么这段编码的质量高低还取决于以下3个附加因素: 1. 测量了多少编码规则?如果一个编码标准比另一个编码标准有更多的规则,那么违规的可能性就会更高。但这并不意味着该代码的代码质量较低。2. 违反的规则的严重程度是多少?如果只违反了不重要的规则,那么代码质量就会比同样违规数量的其他代码更好。3. 代码的数量级是多少?如果在一个由1000万行代码组成的系统中有3000起违反代码规则事件,那么与一个只有1000行代码的系统相比,情况就显得不那么严重了。 为了解决这一问题,引入了“加权因子” (compliance factor) 的概念。加权因子表示软件代码在多大程度上符合某一组规则。例如,这可能是一组编译器警告或一组安全规则。具体的计算公式如下:对此公式的详细解释大家可以参看文末相关文献链接。许多项目中使用这一定义已有20多年,在实践中效果显著。通过行业经验确定了度量项在软件质量属性中所占权重大小,然后分别计算每个度量项分数后进行加权汇总,得到反应软件质量等级和评分的一个检测报告。质量指标是一种非常实用的方法,可以在软件程序发布前甚至在系统测试之前对软件代码的质量进行量化概述。该指标结合了最著名的代码质量度量项,通过公司现有的代码检测工具定义了它们是如何测量的,以及如何判断质量的高低。按照得到的分数,将软件系统依次标记为A(优秀质量)到F(质量差)多个不同的质量等级。鸿渐科技的现有的“源代码检测系统”可以对代码的圈复杂度,扇入扇出和重复代码比例做量化分析,同时,参考众多国内外顶会文章的相关指标量化的设计也在积极努力的开发中,造烛求明,学他求理,鸿渐科技必将在代码质量量化道路上继续披荆斩棘,奋勇向前。参考[1] Boehm, Barry W.; Philip N. Papaccio, “Understanding and Controlling Software Costs”, IEEE Transactions on Software Engineering, v. 14, no. 10, October 1988, pp.1462-1477.[2] ISO, “Systems and software engineering – Systems and software Quality Requirements and Evaluation (SquaRE) – System and software quality models”, ISO/IEC 25010:2011, 2011, obtainable from http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=35733.[3] Wikipedia, “Cyclomatic Complexity”, extracted July 2012, obtainable from http://en.wikipedia.org/wiki/Cyclomatic_complexity.[4] Wikipedia, “Duplicated Code”, extracted July 2012, obtainable from http://en.wikipedia.org/wiki/Duplicate_code.[5] Wikipedia, “Code Coverage”, extracted July 2012, obtainable from http://en.wikipedia.org/wiki/Code_coverage.[6] Wikipedia, “Abstract Interpretation”, extracted July 2012, obtainable from http://en.wikipedia.org/wiki/Abstract_interpretation.[7] Wikipedia, “Coding Conventions”, extracted July 2012, obtainable from http://en.wikipedia.org/wiki/Coding_standard.[8] Henry, S.; Kafura, D., “Software Structure Metrics Based on Information Flow”, IEEE Transactions on Software Engineering Volume SE-7, Issue 5, September 1981, pp. 510–518.[9] OWASP, “OWASP top 10 - 2013, The ten most critical web application security risks”, extracted December 2016, obtainable from https://www.owasp.org/index.php/Top_10_2013.[10] CERT, “CERT Secure Coding”, extracted December 2016, obtainable from https://www.cert.org/secure coding/.[11] Jansen, Paul; Krikhaar, Rene; Dijkstra, Fons, “Towards a Single Software Quality Metric – The Static Confidence Factor”, 2006, obtainable from http://www.tiobe.com/content/paperinfo/DefinitionOfConfidenceFactor.html.[12] Wikipedia, “European Union energy label”, extracted July 2012, obtainable from http://en.wikipedia.org/wiki/European_Union_energy_labe

2020-12-20

白盒代码未知漏洞挖掘工具

一、必要性软件最核心的资源就是代码资源,也是软件的“基因”。据统计,解决了代码中的安全风险问题可以减少80%以上软件的安全性问 题,降低软件风险。作为软件安全的共性技术,代码分析是针对软件最基本的元素进行分析,在很多场景都有重要的应用。场景一:静态代码分析技术能够用于网络攻击。美军早已将软件漏洞作为一种战略资源,每年斥资上亿美元采购软件“零日漏洞”, 而软件代码分析技术正是发现零日漏洞最有效的手段之一。微软公司在2019年斥巨资收购英国的Semmle公司,正是因为该公司的 工具能够通过代码分析技术持续发现零日漏洞,这是其他类型安全工具不具备的功能。场景二:静态代码分析能够发现软件的后门。华为的通信设备软件在英国进行全部的代码重构,正是因为英国采用代码分析手段怀 疑华为代码可能存在安全隐患,而软件后门的最有效检测手段就是代码分析技术。场景三:企业或行业内标准的定制难以事项。大部分企业采用国外商业工具,国内代理商很难具备二次开发的能力,国外工具也不 暴露接口,尤其针对领域内缺陷模式,企业或行业内部往往有自己的编码标准,很难针对性开发。根据以上各种软件代码分析工具的应用场景,需要自主可控的静态代码分析工具,结合漏洞挖掘相关知识进行二次开发分析。但这 类工具的研制由于技术难度高,属于“卡脖子”关键技术,工具基本属于国外垄断甚至禁运的状态。二、可行性从静态分析工具的趋势上看,直接代码分析的引擎分析结果,根据实际需求进行二次开发,成为了未来发展的主要趋势。目前微软 Code QL工具就采用数据库存储方式在Github上对所有的项目进行持久化分析,使用者可采用QL语言查询程序的各种性质,但目 前支持的查询接口和分析能力还有提高的余地。CheckMarx CxAudit采用内存存储的方式开发部分开发接口,但存在状态爆炸的问 题,检测效率和检测代码量级相对较差。也有很多静态分析工具厂商向这个方向进行研发,但目前效果并不好。目前国内自主、可控的检测工具中,本团队的检测引擎具有自主专利技术,且获得CWE认证,且已经实现基础的二次开发工具包。 本科研团队已在代码分析领域进行了多年的研究工作,在代码静态分析方面处于领先水平。且相关分析算法已经过大量的实际 检验,具有良好的检测效果,这为后续工作的推展奠定了坚实的基础。三、建设方案基于静态分析的代码漏洞挖掘工具设计为类IDE应用模式,在Java开发环境下直接打开人机交互界面,上传代码即可使用。总体设 计方案如下图。四、建设目标定制软件代码漏洞挖掘工具,支持C\C++\Java语言高精度函数调用分析、控制流分析、数据流分析、值依赖分析等多种常见静态 代码分析模式的开放接口,提供常见CWE漏洞模式检测模板代码,完善的工具使用文档、培训文档等文档支持,确保工具易于学习 使用。支持函数调用图、控制流图、值依赖图、代码切片等辅助设计图在二次开发过程中的实时更新功能,大内存下支持百万级代 码实时检测。五、系统组成根据建设方案流程,系统分为数据模型模块。检测器编写模块、人机交互模块三大部分。数据模型模块根据被测源码,通过静态代 码分析引擎生成模型化的、不同层级的分析数据源;检测器编写模块将数据源分析整合,通过特定的数据流、控制流分析挖掘代码 漏洞情况。人机交互模块通过高实时性的图形化展示、代码跳转等方式辅助开发人员完成快速开发。六、详细设计标准数据模型模块: 包括静态代码分析引擎的全套通用模型,能够实现各个维度的分析,包括抽象语法树解析,控制流模型分析,值依赖(数据流)模 型分析等。能够满足检测器编写的各项需求。检测器编写模块:分析接口封装部分:对分析模型进行封装,增强模型的易用性。函数配置部分:根据工程需求配置通用的输入、输出节点,过滤函数等配置。通过变更配置能够对分析模型进行更新,实现更高精 度的分析。标准分析模型部分:针对CVE源码进行分析,提供SQL注入、反序列化漏洞、缓冲区溢出、命令行注入等20种常见漏洞的标准分析 模型。分析模型可在工程中直接检测出对应的CVE示例。实际漏铜挖掘过程中可在模型基础上进行微调。辅助分析技术:在标准数据模型基础上,对指针分析、可达性分析等有精度损失的静态分析技术,通过可选接口形式提供,最大程 度保证分析的精度和可控性。人机交互模块图形化展示:实现控制流图、函数调用图、值依赖图等分析模型的图形化展示与检测器分析结果切片展示,能够辅助开发人员快速 理解程序与检测器分析过程。代码跳转:实现代码定义/使用点高亮展示与跳转,能够辅助开发人员快速理解程序。工程实时检测结果可通过word、excel等格式导出 通过挖掘方式编写的检测器可实时导出,并直接导入静态代码分析工具中作为新的检测项。