![c8174f20bf0f8962b09cc002ddd86ecc.png](https://i-blog.csdnimg.cn/blog_migrate/0a34dd9e7ce6e7aee9e89944c934d491.jpeg)
预防重于补救!通过编码标准进行软件安全保护
软件从台式机迁移到我们接触的几乎所有事物。从智能恒温器到输液泵再到汽车,软件无处不在且在不断发展。物联网(IoT)中的所谓“事物”越来越多地带有更多逻辑。有了它,更大的失败风险。这些设备中的许多设备都被用于医疗和汽车等对安全至关重要的领域,有可能造成人身伤害。
大多数构建设备的公司都正确地将当前的软件开发视为一群疯狂的牛仔和混乱者,但是有希望。可以并且必须将软件视为工程实践。编码标准是良好软件工程实践的组成部分,使我们从“构建、失败、修复”周期转变为具有高质量、安全性和安全性的“设计、构建、交付”周期。
事实证明,这些相同的标准还在网络安全领域提供了双重职责。这篇文章讨论:
- 这些标准如何帮助我们从发现缺陷转变为构建功能更强大的软件。
- 首先如何通过正确的编码来防止问题。
- 如何通过使用诸如MISRA之类的公认行业标准来利用他人的努力来实现此目标。
从软件开发到软件工程
软件对现实世界的影响通常是低估的。作为Parasoft的传播者,我不断讨论的主要主题之一是软件开发确实应该是工程设计。
我们经常由软件工程师来称呼软件开发人员,但这不一定是他们今天工作方式的恰当术语。演变为良好的软件工程实践会导致成本下降和质量上升。其中的关键部分是采用标准,尤其是编码标准。
互联汽车、物联网和永久互联设备的时代在这里。软件正在渗透到我们从未想到的产品、设备和其他地方。现在,我们必须认真考虑这些产品中的软件及其后果。
质量差的代价
我尝试解释的有趣的事情之一是,构建良好的软件与构建汽车之类的东西不同。如果我要制造高质量的汽车,我必须花更多的材料和更多的时间来制造它。事实证明,在软件中,您无需花费更多的时间来构建高质量的软件。您花更多的钱来构建质量差的软件。
我们必须了解,在软件中,大多数缺陷来自程序员,后者将它们放入产品中。如果我们在开发软件时能够停止引入缺陷,那么我们可以以更低的价格获得更好的软件。
这句话引自Edsger W Dijkstra在1972年的一次演讲,名为“谦虚的程序员”。今天仍然非常重要。
![6e604e8c5cae0ee9e2fb4bd163474da7.png](https://i-blog.csdnimg.cn/blog_migrate/c8154cda85357dc13cf89ebb3a12c414.jpeg)
预防重于补救!通过编码标准进行软件安全保护
重要的是要意识到质量如何影响软件开发成本。研究人员Capers Jones已经关注了数十年,并每年进行一次软件成本调查。这些数字每年变化不大。数据显示,从需求到编码再到维护的每个阶段,软件的典型成本都会增加。但是,团队对待质量的方式决定了他们的过程是健康的还是“病态的”。
![8ed2027889a46d3679bafdb114bfe60a.png](https://i-blog.csdnimg.cn/blog_migrate/cb21e21f9727d0a3056d0659943037c8.jpeg)
预防重于补救!通过编码标准进行软件安全保护
为什么我们需要及早修复缺陷
有道理的是,如果我们在编写代码时就发现缺陷,那么成本就相对便宜了——例如,开发人员只需几分钟的时间。如果可以在开发阶段消除85%的缺陷,那么对成本的影响就很大。考虑一下现在著名的Capers Jones图表,它显示了在每个开发阶段修复缺陷的平均成本:
![387308f4a7db2d9c03dcb14941d12fd1.png](https://i-blog.csdnimg.cn/blog_migrate/6d08c8459414b7a5cb711c7bf2d37304.jpeg)
预防重于补救!通过编码标准进行软件安全保护
根据对使用真实软件而不是理论模型的真实公司的研究,修复发布后的缺陷大约需要16000美元(可能更多)。如果我们查看周期后期的质量和安全性工作(例如渗透测试),则此处发现的安全性问题处于周期的昂贵末端。通过测试与早期安全审核相比,查找漏洞的成本可能高出15倍。
一种过时且可证明是错误的方法是通过在生命周期的结尾(即发行前)进行测试来提高软件的质量。在制造业中,他们知道这是不可能的,但是出于某些原因,我们认为我们可以测试“进入”软件的质量(和安全性)。
我之所以说软件开发几乎绝不是工程学,是因为当前软件开发具有以下共同特征:
- 大多数开发人员正在做的事情是不可重复的。也就是说,如果我将相同的任务分配给两个不同的人,结果将是不同的。
- 缺乏良好执行的最佳实践。软件开发人员将编码标准视为一个毫无意义的词。标准被认为是团队领导坚持要求我遵循的一组规则,而不是理解编码标准是知识,实践和经验的体现。电气工程师知道,标准是首次制造安全产品的方法。软件开发人员认为标准是一种限制因素,正在减慢它们的速度……“误报”。
- 开发人员培训是未知且不一致的。软件开发教育没有像工程学科那样标准化。标准和既定做法通常不是课程的一部分,而是重点放在编程语言上。
编码标准提高了安全性
软件编码标准的目标是灌输经过验证的编程实践,以产生安全,可靠,可测试和可维护的代码。通常,这意味着避免使用已知的不安全编码做法或可能导致不可预测行为的代码。这对于像C和C++这样的编程语言至关重要,因为在这些语言中,编写不安全或不安全代码的可能性很高。
但是,我认为行业在使用这些编程标准时已迷失了方向。在过去的十年中,这些工具(例如静态分析工具)已经从检测不安全的潜在问题代码或已知的语言弱点转变为以早期测试的形式寻找缺陷,也称为左移。
尽管寻找缺陷很重要,但是开发完善的软件是一项更具生产力的活动。我们应该做的是建立和执行标准,以避免出现缺陷首先出现的情况,即向左移动更远。
作为支持,请考虑软件工程研究所(SEI)所做的研究,他们毫不奇怪地发现,安全性和可靠性是紧密相连的,并且可以通过发现的质量缺陷的数量和类型来预测软件的安全性。此外,关键缺陷通常是编码错误,可以通过检查和工具(例如静态分析)来避免。
行业标准
这篇文章没有详细介绍每种编码标准,但是在以下行业标准中有大量工作要做。尽管它们的应用可能特定于特定类型,但这些标准已在许多行业中得到采用。以下是一些已建立的安全性编码标准示例。
- MISRA C/C++:由汽车工业软件可靠性协会开发,它描述了C或C++语言的子集以及使用它们的准则,以提高应用程序的安全性。尽管最初是针对汽车应用,但在其他对安全要求严格的应用中,它的使用却有所增加。
- SEI/SANS CERT:软件工程学院(SEI)的计算机紧急响应小组(CERT)具有一组准则,可以帮助开发人员创建更安全和更可靠的软件。这些准则被“规则”和“建议”分组划分为重要的内容,并且非常详尽和广泛,并包括风险元数据。
- OWASP Top 10:顾名思义,开放Web应用程序安全项目(OWASP)是致力于改善Web应用程序安全性的组织。因此,他们的OWASP Top 10项目提供了最常见和影响最大的Web应用程序安全漏洞的列表。OWASP Top 10的最新版本与特定的CWE ID直接相关,并且包含风险元数据。
- Joint Strike Fighter Air Vehicle C++ Coding Standard (JSF AV):一种基于MISRA C子集的标准,专门针对JSF计划。
- CWE - Common Weakness Enumeration Top 25:CWE是基于对报告的漏洞(CVE)的分析发现的软件弱点的列表。前25名列出了从较大的CWE列表中选择的最常见和最危险的安全漏洞,这些漏洞都是极有可能发生的漏洞,利用漏洞的影响很大。CWE还以技术影响的形式包括风险信息,有助于了解哪些问题对您的组织最重要。
让我们考虑一下MISRA C,我提到的它不仅是用于汽车应用。但是,该标准自1998年以来一直在使用,并且定义明确。他们每两年进行一次更新。随着C和C++语言的发展,它们围绕着它发展了标准。这是一个非常灵活的标准,其中考虑了不同的严重性级别,并且有成文的策略来处理和记录偏差。
作为可以检测违反编码标准准则的技术(例如静态分析),MISRA的最新版本考虑了哪些准则是可以确定的(可以用工具高精度地检测到),而哪些不是。这使我们想到了采用和强制执行以及静态分析工具在编码标准中的重要性。
静态分析的作用
研究表明,缺陷清除不足是软件质量低下的主要原因。程序员发现自己软件中的缺陷的效率约为35%。在开发周期的后期,在所有设计评审、同行评审、单元测试和功能测试之后,我们希望消除的大多数缺陷约为75%。
如果在预防模式下正确使用静态分析,则可以将缺陷清除率提高到大约85%。但是,当今大多数组织使用静态分析的重点是检测和快速修复。
首先使用静态分析工具来防止已知的不良编程习惯和语言功能,可能会带来进一步的好处。在这里,编码标准将作为指导原则和编程语言子集发挥作用,以防止将诸如缓冲区溢出或缺少初始化之类的常见缺陷写入代码中。
只需一点预防
考虑一个示例,在该示例中,可能使用动态应用程序安全工具(DAST)检测到一个相当复杂的缓冲区溢出错误。运气不好,因为您的测试刚好执行了包含错误的代码路径。一旦被检测和调试,就需要重新测试等等。使用流分析的静态分析可能也发现了此错误,但这取决于应用程序的复杂性。
运行时错误检测非常精确,但是它仅检查您执行的代码行。因此,它仅与测试代码覆盖率一样好。考虑一下编码标准是否首先禁止了导致此错误的代码。
像MISRA C这样的编码标准并没有描述例如如何检测未初始化的内存,而是指导程序员编写首先不会导致这种错误的代码。我相信这更多是一种工程方法:根据众所周知的公认标准进行编程。以土木工程和建筑桥梁为例。
我们不会采取建造桥梁的方法,而是先通过越来越大的卡车来测试它,直到它倒塌,再测量最后一辆成功使用的卡车的重量,然后再次建造以承受新的重量。这种方法还是很愚蠢的,与我们进行软件开发的方法没有什么不同。
一旦软件团队采用编码标准并正确应用了静态分析,他们就可以及早发现错误并加以预防。换句话说,团队正在改变编写代码的方式,这更好,而不是尽早发现缺陷,这是好的!
考虑Heartbleed漏洞。现在有针对此特定漏洞实例的检测器,但有一种方法可以编写代码,从而使Heartbleed永远不会发生。预防是一种更好、更安全的方法。
总结
Dykstra说:“那些想要真正可靠软件的人会发现,他们必须找到避免大多数bug的方法。”拥有可靠的预防方法比修复这些错误的成本要少。
编码标准体现了以其相应语言进行编程的合理的工程原理,并构成了任何预防方法的基础。好的软件的成本小于劣质的软件的成本。如果您今天不使用静态分析,或者仅将其用于早期检测,请查看Parasoft的C和C++,Java,C#和VB.NET静态分析工具,其中包含丰富的检查程序库内置了流行的安全标准。
![5534af8a9fe29a344e411ec692330aed.png](https://i-blog.csdnimg.cn/blog_migrate/54f952ef1f7b8450f021435a18f705d8.jpeg)
预防重于补救!通过编码标准进行软件安全保护
点击“了解更多”申请免费试用