法律法规与标准是实验室规范开展代码测试的依据,也是拉动代码测试业务发展,使代码测试成为刚性需求的重要基础。随着软件行业的不断发展,各个行业对代码安全层面的要求越来越重视,像电力、金融等行业都已经发展出了自己的行业标准。本文我们一起梳理代码测试相关的标准以及法律法规都有哪些。我们先看一下国际上都有哪些法律法规与标准。
1、《欧盟通用数据保护条例(GDPR)》
GDPR要求数据处理的透明性和安全性,对开发涉及处理个人数据的软件产品的公司有明确的安全义务,包括在开发过程中实施数据保护的技术和组织措施。
2、《美国健康保险流通与责任法案(HIPAA)》
HIPAA涉及医疗行业,要求保护个人健康信息的安全和隐私。软件开发商如果处理医疗信息,必须确保源代码的安全性,防止数据泄露。
3、《NIST SP 800-53》
由美国国家标准与技术研究院发布,这个安全控制和风险管理框架涵盖了包括软件开发生命周期中的安全控制,推荐进行源代码分析以识别安全缺陷。
4、《PCIDSS(支付卡行业数据安全标准)》
PCIDSS 中6.3.7“在发布生产以前检查自定义代码,以识别所有潜在的编码漏洞”及 6.6“对于面向公众的 Web 应用程序,经常解决新的威胁和漏洞,并确保保护这些应用程序不受到以下任一方法的攻击",此项要求中明确提出了由独立于开发团队的内部组织或第三方专业机构进行代码安全申查。对于银行业及金融业来说,此项业务需求将比较大。
5、《ISO IEC 27001》
根据《信息安全管理系统要求》中控制目标“防范恶意代码和移动代码”,“应用中正确处理”,“技术脆弱性管理”的要求,应用系统必须以相应的控制措施提供相应的功能。为验证安全功能的实现,在IT 审计工程中,必然需要相应的测试结论提供相应的支持。其中“防范恶意代码和移动代码”,“应用中正确处理”,“技术脆弱性管理”等要求均可以利用代码审查进行控制目标的验证。
在我国内的法律法规中,从2017年实施的网络安全法,到后面出台的一些对网络安全等级保护的一些标准,很多环节中都提到了,要有源代码审计。国内代码测试相关法律法规与标准主要有:
1、《中华人民共和国网络安全法》
2、《信息安全技术 网络安全等级保护基本要求》GB/T22239-2019
3、《C/C++语言源代码漏洞测试规范》GB/T 34943-2017
4、《Java语言源代码漏洞测试规范》GB/T 34944-2017
5、《C#语言源代码漏洞测试规范》GB/T 34946-2017
6、《网上银行系统信息安全通用规范》JR/T0068-2020
7、《Java语言 源代码缺陷控制与测试指南》SJ/T 11683-2017
8、《C/C++语言 源代码缺陷控制与测试指南》SJ/T 11682-2017
网络安全法中主要强调要实现各种等级保护、数据安全保护的制度。GBTT22239-2019这个标准是作为软件建设方需要做到的合规要求。标准中明确提出,开发单位要提供软件源代码,并审查软件当中可能会存在的后门,通过源代码检测去做一些已知漏洞的覆盖。
GB/T 34943-2017和GB/T 34946这两部源代码漏洞测试规范,出自2017年,把国际上的信息安全相关的标准在国内做了细化的落地,给出了最基本的应该排除的漏洞的范围。
安全性对金融行业来说是至关重要的,因此在金融行业,源代码安全测试的需求也是非常刚性的,《网上银行系统信息安全通用规范》JR/T0068-2020中也明确提到,客户端程序要进行源代码审计,排除最基础的漏洞之后,才能上线。
《C/C++语言源代码漏洞测试规范》GB/T 34943-2017、《Java语言源代码漏洞测试规范》GB/T 34944-2017和《C#语言源代码漏洞测试规范》GB/T 34946-2017这三个标准有很多漏洞类型的交集。
GB/T 34944-2017 《Java语言源代码漏洞测试规范》作为Java语言的测试规范,应用范围非常广泛。它当中的有44个类型的漏洞。区别于其他几个的方面主要有可序列化的类、包含敏感数据、会话永不过期、关键参数篡改。
GB/T 34943-2017《C/C++语言源代码洞测试规范》是第二个用得相对比较多的规范。C/C++语言在客户端的开发、嵌入式的软件开发过程中经常用到。整个标准中一共有32个类型的漏洞。它特有的主要有:
堆检查、缓冲区溢出、使用外部控制的格式化字符串、敏感信息存储于上锁不正确的内存空间、公有函数返回私有数组和整数溢出。
第三类是G8/T 34946-2017 《C#语言源代码漏试规范》。漏洞类别上来看基本上是被《C/C++语言源代码洞测试规范》覆盖掉的,一共有40个类型。
1)手动代码审查:由经验丰富的开发人员或安全专家手动检查源代码。
2)自动化代码分析:使用专门的工具自动扫描源代码,快速识别已知的漏洞模式和不安全的编程习惯。
对大的工程的原代码来讲,通过手工的方式,去一行行排查是不现实的,效率也非常低。会有一些自动化代码分析工具帮助人工去梳理,梳理完之后,在此基础上去做人工分析。合适的工具是提高效率的一种手段,但也确实会存在误报和漏报,这时候就需要需要联合开发的企业和单位去分析,找负责的开发工程师一起坐下来去对一下这个问题到底是什么。
在实验室参加代码测试能力验证的过程中,有一个类似交流式的答辩,针对有疑问的问题点进行答辩,考核参与的实验室对问题的熟悉程度如何,以及是不是真正理解该语言的此类问题,同时考察实验室对工具所报告问题的处理能力。
因此在进行代码测试能力验证的过程中,不能“工具这么报了,我就这样往上写”。目前我们市面上用到的代码检测工具大多都没有做到与国家标准完全一致,很多时候不同工具对同一个漏洞的叫法也不一样。因此需要真正了解和掌握不同类别的漏洞的原理。
1)静态应用程序安全测试(SAST):一种自动化工具,可以在不运行代码的情况下分析源代码或编译后的版本。
2)动态应用程序安全测试(DAST):在应用程序运行时分析其行为,寻找安全漏洞。
3)交互式应用程序安全测试(IAST):结合SAST和DAST的技术,通过监控应用程序运行时的行为来检测安全漏洞。
实验室在申请代码测试领域的CNAS/CMA等相关资质时,应该重点考虑工具的报率和误报率,测试前做好对工具的漏洞规则库进行升级和维护工作。
标准中明确了源代码测试过程分为测试策划、测试设计、测试执行和测试总结四个阶段。这个四个阶段也是软件测试通常用的步骤。
先做策划,要知道测试的目标,要测哪些语言,依据的标准,用什么工具,搭建什么样的环境,还涉及到一些人员分工分工和各阶段的交付成果。要按照GB/T15532-2008 这个规范来产生测试各个阶段相应的一些文档。
设计阶段的主要是根据测试的的目标结合被测软件源代码的业务和技术特点,明确环境和工具。比如说要测一段java源代码,就要搭建相应的gdk,选择能够支持测试的工具。
再有就是明确测试需求、测试方法和内容,以及测试准入条件和测试的准出条件。也就是说测到什么时候为止。这个也是有一定的行业最佳实践的。一般来讲,把软件当中工具发现的、人工挖掘到的高危的、中危的漏洞能够测试出来,并且回归完毕,作为一个关闭的节点,不可能无休止地测下去。
在能力验证的过程中,对低风险的漏洞以及软件源代码质量方面的问题是不太关注的,这些不太可能产生安全问题。像变量的命名方式等这些都不太关注。
在设计阶段,采用自动化分析工具和人工分析相结合的方法是非常必要的,不应该只拿工具去做结果的输出。
测试执行阶段主要是按照漏洞类型和风险等级来分析扫描到的所有源代码漏洞,结合源代码的上下文内容和业务需求去做分析,这也是标准中提到的。
作业指导书中也应该有这方面的内容,标准无法解决业务的问题,国标只是一个普适性的标准,但是具体到了某一个应用当中,加密强度是多少?或者业务流程上的一些限制,比如说一些限制不能让这个接口去被任意遍历,都需要去结合具体的业务。
同时还要去删除误报的源代码问题,和开发人员沟通源代码测试的结果,没有开发人员的配合是不现实的。通常要把需要沟通的内容写到作业指导书里,让大家去遵循。
最后是测试总结,我们要核查环境、工具以及各个环节的方法和结果的针对性,确认是否达到测试目标。最后形成测试报告,这就是整个完整的测试环节的概述。
以上就是针对软件代码测试标准和法律法规的分类梳理和介绍,如需软件代码测试工具参数比对清单或代码测试用例,可私信我交流探讨。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。