自动化检测工具助力GJB 8114-2013 C/C++语言编程安全子集标准落地应用

        2013年7月10日,中国人民解放军总装备部发布了中华人民共和国国家军用标准GJB 8114,全称为GJB 8114-2013《C/C++语言编程安全子集》,提出软件编程标准,以提高国家军用软件的安全性,并作为静态规则检查的依据。GJB 8114的提出源于2005年发布的GJB 5369,全称为GJB 5359-2005《航天型号软件C语言安全子集》是航天领域嵌入式C语言的编程标准,GJB 8114对原有的规则进行了升级和扩充,扩展了应用场景,适用于所有军用软件开发,同时明确的提出了C语言的编程规范和C++语言的编程规范内容,即标准中的第五章规定C和C++语言编程时应该遵守的共同准则,第六章规定C++语言编程时应遵守的专用准则,其中C 和 C++共用的强制准则共124条,C++专用的强制准则28条,C 和 C++共用的建议准则41条,C++专用的建议准则11条。标准总计204条。标准中每条准则采取固定格式描述,并给出违背和遵循正反两个示例,以供开发人员和评测中心参照。

      大量数据表明,软件存在的问题或隐患很大部分根源在于没有遵守编程规范或标准,所以很多科院院所和企业大多制定了自己企业的编程规范。编程规范或标准的落实,一方面可以使代码开发人员在编程过程中遵守规则,从而保证代码的可理解性和可维护性;另一方面也可以让测试人员按照规则来检查代码,及时发现代码问题。航空、航天、电子、船舶等软件测评中心作为第三方评测机构,在测试过程中会严格按照GJB8114的规则进行检测,不但可以在评测体系内保证代码规则的一致性,还可以在全军体系内实施推动软件标准化,落实提高软件的可维护性和可靠性,增强我国军用软件质量。

       鉴于传统的代码规则检查需要靠评测中心人工阅读和审查代码,如果开发方提交的代码本身没有遵守标准,导致评测中心消耗很多时间和资源在静态代码审查上,所以需要自动化的检查工具来实现对代码进行快速有效的规则检查。很多企事业单位自己编制了自动化测试规则检查工具,但是由于资源有限,以及标准的理解等限制,导致很多自研工具没有普适性,甚至对一些提交的代码无法检测。

      另外,由于GJB 8114中只是C/C++代码安全的一个子集,只是满足了该标准,也不等于软件就消除了安全隐患。毕竟,C和C++由于其语法灵活的特性,决定了代码质量需要通过更多的角度去度量和评测。国外工具很少能够支持国标,国内做标准检测的厂家凤毛麟角,还有最近两年一款工具在市场上比较活跃,是由北京大学软件工程国家工程研究中心和北大软件合作研发的CoBOT工具。能够很好的支持GJB 8114,全部204从规则都能进行检测,运行完成给出中文的检测报告,非常便于阅读和整合到出具的评测报告中。另外,也支持GJB 5369。如果评测的目的不仅仅是满足GJB 8114标准,则可以借助CoBOT中超过1000个C和C++检测器,包括MISRA 2004、MISRA 2008、MISRA 2012、ISO 17961、CWE、OWASP等标准和公开缺陷和安全漏洞模型,能够全面检测出超过100种缺陷和安全漏洞,为软件质量提供最大限度的保障。毕竟,不管是作为军工研发单位,还是作为评测单位,防微杜渐上的付出总比联合实验中缺陷归零时责任要小很多。

       根据实际经验,代码静态分析比动态测试更有效率,能够自动快速发现缺陷,尤其是逻辑设计和编码缺陷。笔者认为代码静态分析和动态测试可以相互补充,动态测试发现功能、时序、性能等方面的缺陷。动态测试往往由于难于构造动态测试执行的平台环境而往往采用在全数字仿真或半数字半实物仿真上执行测试,此类测试更容易发现功能上的缺陷。根据CoBOT工具从军工客户落地使用的效果反馈来看,能够全面满足对于GJB 8114标准的检测,更多的价值是帮助客户发现了该标准之外的大量代码上的缺陷。另外,通过工具给出的超过30种静态度量数据,能够对被检测代码进行各种维度的度量,例如圈复杂度、扇入、扇出、注释率、循环嵌套深度等等。

       下面我们给出两个例子,分别是通过GJB 8114标准检测出的缺陷、GJB 8114标准未发现的缺陷作为参考。

       案例1:下面代码违反了数组下标必须大于等于零的正整数规则。为GJB 8114中的GJB_R_01_06_09 数组下标必须是大于等于零的整型数

 

       案例2:下面代码违反了给变量赋值与其类型不一致的规则。经过作者核实,该违反了GJB5369中的6_1_9,虽然GJB 8114没有明确该条标准,很明显,GJB 5369这一条还是需要遵守的,否则导致数据溢出或丢失。

下面是该缺陷的工具报出的提示。

所属缺陷:给变量赋的值与其类型不一致
缺陷发生位置:在gd.c中zif_imagecopymergegray函数的第3703行。
缺陷说明:在(gd.c)文件第(3688)行声明了[int]类型变量[pct],在第(3703)行将[long int]类型变量[PCT]赋值给[int]类型变量[pct],两者类型不一致,可能导致数据丢失。

通过上面两个案例可以看出,代码中违反了GJB 8114或GJB 5369中的规则,给程序运行带来了故障隐患。同时在遵守GJB 8114标准的同时,也不能丢掉GJB 5369,有人说GJB 8114代替了5369,其实很多规则并没有完全替代。通过支持两个GJB的检测工具进行检测,发现代码中违反标准的地方,进行修复才是最安全的编程。

(完)

发布了309 篇原创文章 · 获赞 31 · 访问量 6万+

猜你喜欢

转载自blog.csdn.net/manok/article/details/92377949