[实用指南]如何使您的旧代码库(遗留代码)符合MISRA C 2012编码规范？

重用旧代码是现实，但是在安全关键型软件项目中重用旧代码并实现MISRA C 2012的完全合规性是艰巨的任务。

最初的MISRA原则是为了在开发代码时应用而创建的，即使文档本身也有警告：

“……在项目周期的后期检查MISRA C符合性的项目可能会花费大量时间进行重新编码、重新审查和重新测试。因此，预计软件开发过程将需要尽早应用MISRA C原则。”

由于出于业务原因，许多组织确实需要重用其旧版代码库，因此针对这些挑战创建了MISRA 2016合规指南文件。其中，在当前项目范围内开发的新的本机代码与在项目范围之外开发的“已采用”代码之间有明显的区别。在这篇文章中，我解释了一种处理遗留代码和MISRA C合规性的实用方法。

遵循MISRA准则的灰色阴影

尽管似乎很容易理解要处理的代码类型，但在很多情况下情况并非如此。例如，将不遵循MISRA准则开发的初始原型产品化，然后管理层意识到合规性是预期市场的要求。通常，遗留代码库的开发从来没有考虑任何编码准则。因此，如果在新项目的上下文中需要更新，则无法将代码库自动分类为“采用的代码”。这会变得很复杂。

通常，通过启用了所有MISRA C 2012规则（包括修订1）的静态分析工具对大型代码库进行的初始扫描会产生数以万计的违规行为。在最初的震惊之后，团队开始寻找解决冲突的“创造性”方法。重要的是，不要阻止开发团队——隧道尽头有阳光。

随着时间的流逝，我已经收集并确定了开发团队用来使代码合规而又不影响正在进行的开发速度的最佳实践和方法。在本文中，我将分享一些实用且平衡的方法，以使现有代码库符合MISRA。

使用MISRA Compliance: 2016框架

MISRA C 2012是用于C编程语言的一组编码准则。该标准的重点是通过避免C语言中的已知问题构造，通过防止编程人员犯错误而导致运行时失败（以及可能的安全问题），从而提高软件的安全性。多年来，许多嵌入式系统开发人员一直（并且仍然）抱怨MISRA C对标准过于严格，并且编写完全兼容的代码的成本难以证明。实际上，鉴于MISRA C已应用在安全关键软件中，因此将该标准应用于项目的价值取决于以下因素：

由于软件故障而导致系统故障的风险
系统故障给企业造成的损失
开发工具和目标平台
开发人员的专业知识水平

因此，程序员必须找到一种符合标准精神的实用中间立场，并且仍要声称自己符合MISRA，而不会浪费精力在非增值活动上。

在MISRA Compliance: 2016文件中，MISRA联盟提供了社区所需的响应，并提供了一个合理定义良好的框架，说明“符合MISRA”一词的真正含义。该文档通过定义以下工件来帮助组织使用表达合规性要求的通用语言：

准则执行计划——演示如何验证每个MISRA准则。
准则重新分类计划——在准则中传达商定的各个规则的严重性，作为供应商/客户关系的一部分。
偏差报告——以合理的理由记录违反准则的情况。
准则合规摘要——是总体项目合规性的主要记录。

为了专注于处理遗留代码库，关键文档是指南重新分类计划。本文档包含所有指令和规则，并确定已重新分类了哪些类别。例如，下图显示了重新分类计划的一部分：

首先，对于“采用的”旧代码，《MISRA 2016: Compliance》文档建议不要从不太严格的分类到更严格的分类进行重新分类。此外，在与小组一起审查违规类型之后，也可以一起取消应用咨询规则。

仅对于所有必需规则才需要记录偏差。应该对所采用的规范中的任何违规行为进行审查，并且偏差必须清楚地表明违规行为不会损害安全性。不管重新分类如何，如果发现有损害系统安全性的问题，则必须解决此问题。同样，对遗留代码的修改可能会引入其他问题，这些问题是开发人员无法清楚看到的。

以终为始

安全关键软件开发人员遇到的关键问题是如何在项目结束时演示和证明合规性。如果评估标准基于各个利益相关者的主观意见，那么这可能是一个有争议的问题，导致浪费时间和精力。在这种情况下，MISRA Compliance: 2016文档得以解决。

建议的改进对合规性准备情况评估的方法是将现有模板用于最终合规性和工具合格性报告。还有一种趋势是向报告中添加比所需更多的信息。如果标准不要求提供该信息，请避免点缀。添加额外的信息不仅浪费时间，而且存在延迟审核过程的风险。

MISRA Compliance 2016提供了包含在最终报告中的必需信息：

准则执行计划
准则合规性摘要
所有批准的偏差许可证的详细信息
偏差记录涵盖了所有违反准则的情况，已按要求重新分类。

以下来自Parasoft工具的示例显示了HTML格式，并带有指向相应部分的链接：

尽早建立最终目标

除上述建议外，还需要考虑其他一些重要点：

在项目开始时是否制定了GRP（指南重新分类计划）？根据MISRA标准，可以与收购方进行协商，也可以为所采用的代码创建多个GRP，这些代码无需进行任何修改就可以使用，而本机代码则是项目期间主动修改的。
对于每个增量更改，是否都存在要完全遵守法规的剩余工作量？这有助于相应地计划工作并与管理层建立正确的期望。
在项目开始时，是否已与采购方一起审查了GPS（指南符合性摘要）报告模板，这些模板是否被接受并完整？

商业静态分析工具供应商（包括Parasoft）提供了这些文档的模板，以帮助组织满足MISRA 2016合规性框架。

分阶段实施：分而治之

尽管通过静态分析工具对现有代码进行的初始扫描往往会产生数千个违规行为（尤其是在使用默认规则集时），但停止新的开发工作来集中精力解决所有这些违规行为是不切实际的。实际上，我已经看到在对代码库进行重大更改以修复静态分析违规时引入了回归的情况。因此，重要的是建立一个工作流来解决随时间推移的违规问题，而又不影响开发流程和软件质量。

下面列出了在项目中首次使用静态分析工具时的一些关键建议：

基线。在对代码进行初始扫描之后，将所有初始违规标记为“稍后处理”，并设置为基准。从那时起，在更新现有代码和/或开发新代码时，应保持“不允许出现新的违规”政策。可以通过代码检查过程或Jenkins或Bamboo等持续集成（CI）工具来实施此策略。当开发人员有几个小时或几天的空闲时间时，他们可以解决从基线标记的其余违规情况。组织可以根据当前正在开发的代码，代码审查结果或依靠度量标准（例如复杂性）来建议下一个要解决的违规问题，从而优先考虑此方法。
线在“沙子”里。开发确定了一个日期，即“界线”。在此日期之后，修改的每个翻译单元（单个源文件）都必须解决所有违规问题。所有未修改的翻译单元都会自动归入MISRA合规性文档中真实的“采用”代码定义之内。
基于严重性的优先级。开发人员会修复分配给他们的模块的所有强制性发现。随着时间的推移，他们会根据团队负责人选择的优先级，在时间允许的情况下解决所有要求的违规行为。

对于上述任何一种方法，对于技术负责人和管理人员而言，通过集中式仪表板不断监视进度和项目合规性状态至关重要。例如，Parasoft的报告中心提供了以下预配置的合规性状态仪表板：

工具资格

MISRA合规性的一个不太明显的组成部分（通常留到项目结束时）是认识到产品中使用的开发工具需要针对预期用途进行资格验证（已证明适合目的）。如果工具需要鉴定，则需要执行什么级别的鉴定？

尽管在许多情况下需要工具鉴定，但用于进行工具鉴定的方法因与工具故障和软件关键性等级相关的风险而异。Parasoft提供了针对特定安全标准及其要求的认证套件和认证。在缺少此高效工具包的情况下，软件团队在评估商业，免费和开源工具时必须考虑工具认证成本。

一些标准（例如ISO 26262和DO-178B/C）提供了有关工具鉴定要求的合理指导。无论采用哪种方法，工具鉴定过程的目标都是声明“工具对预期用途有效”，并提供团队如何得出此结论的证据和理由。

以下是一些建议的步骤，用于工具鉴定过程：

指定预期用途的工具要求
标识产品中使用的功能的子集。将认证过程简化为仅使用的功能
概述资格计划
概述验证工具是否符合要求的一组资格验证步骤（可能包括团队执行的测试）
自动执行可以自动化的测试用例
提供一个框架来输入手动测试步骤的结果
报告模板以减少开发人员需要输入的文本量。
与利益相关者一起审查报告并签字。

从一开始就忽视工具资格可能会导致项目周期延迟。

员工能力和培训

开发人员的专业知识和培训是软件组织忽视的另一个关键因素，在评估产品的就绪状态时，审计人员经常将其视为首要问题。

根据《MISRA指南》，员工能力是MISRA合规性的重要组成部分。最好在项目开始时进行培训，并记录培训日期，所有开发人员都应签字同意接受培训。在项目结束时，开发团队应该能够证明：

批准偏差的工作人员了解并接受过培训，可以认识到与违规有关的风险
人员经过培训，可以在使用前正确配置和使用静态分析和开发工具。

实际上，对经验丰富的团队的培训相对较短，但是在错过项目截止日期之后，在项目开始时投入几天的时间就可以节省数周的返工。

总结

没有任何捷径可以使对安全至关重要的项目轻松实现对遗留代码的MISRA合规性。但是，正如本文所概述的那样，随着引入MISRA Compliance 2016框架，使用实用的分阶段方法以及明确定义的终点（如本文所述），软件开发团队可以在不严重破坏其开发流程的情况下实现合规性。最重要的是，要实现合规性还需要进行大量工作，但是通过智能计划和正确的方法，可以建立起最小和平衡的任务集，以确保旧代码和新开发代码的安全。