标签: 静态分析

静态分析可帮助面临压力的开发团队。高质量的版本需要按时交付。需要满足编码和合规性标准。错误不是一种选择。 这就是开发团队使用静态分析工具/源代码分析工具的原因。在这里，我们将讨论静态分析和使用静态代码分析器的好处，以及静态分析的局限性。 什么是静态分析？ 静态分析是一种调试方法，通过自动检查源代码来完成，而无需执行程序。这使开发人员能够了解他们的代码库，并有助于确保其合规性和安全可靠性。 什么是静态代码分析？ 静态代码分析是指静态分析工具执行的操作，即根据一组（或多组）编码规则分析一组代码。 静态代码分析和静态分析通常与源代码分析一起互换使用。 静态代码分析解决了源代码中可能导致漏洞的弱点。当然，这也可以通过手动源代码审查来实现。但是使用自动化工具要有效得多。 静态分析通常用于遵守编码准则，例如 MISRA。 它通常用于遵守行业标准，例如 ISO 26262 。 什么时候使用静态代码分析器/源代码分析工具执行静态分析？ 静态代码分析是在软件测试开始之前的开发早期进行的。对于实践DevOps的组织来说，静态代码分析发生在“创建”阶段。 静态代码分析还通过创建自动反馈循环来支持 DevOps。开发人员会很早就知道他们的代码中是否存在任何问题，解决这些问题会更容易。 静态分析与动态分析 那么， 静态分析和动态分析有什么区别 呢？ 这两种类型的代码分析都可以检测缺陷。最大的区别在于 他们在开发生命周期中发现缺陷的地方。 静态分析在运行程序之前（例如，在编码和单元测试之间）识别缺陷。 动态代码分析在运行程序后（例如，在单元测试期间）识别缺陷。然而，一些编码错误可能不会在单元测试期间出现。因此，动态测试可能会遗漏一些静态代码分析所能发现的缺陷。 静态代码分析器/静态分析工具的局限性是什么？ 静态代码分析用于开发特定阶段的特定目的。但是静态代码分析工具存在一些局限性。 不了解开发人员的意图 静态分析工具可以在该计算中检测到可能的溢出。但它不能确定功能根本不起预期的作用！ 不可静态执行的规则 一些编码规则依赖于外部文档。或者它们可以接受主观解释。 例如： CERT-C MSC04：以可读的方式始终如一地使用注释。 可能的缺陷会导致假阳性和假阴性 在某些情况下，工具只能报告可能存在缺陷。 如果我们对 foo（） 一无所知，我们就不知道x的值是多少。 结果是不可判定的。这意味着工具可能会报告实际上不存在的缺陷（假阳性）。或者他们可能无法报告真正的缺陷（假阴性）。 静态代码分析器有哪些优势？ 静态分析工具有几个好处，尤其是当您需要遵守行业标准时。 最好的静态代码分析工具提供了速度、深度和准确性。 速度 开发人员进行手动代码审查需要时间。自动化工具要快得多。 静态代码检查解决了早期的问题，并准确地指出了代码中的错误所在。因此，您将能够更快地修复这些错误。此外，早期发现的编码错误修复成本更低。 深度 测试不能覆盖所有可能的代码执行路径。但是静态 代码分析器 可以。 在构建过程中，静态代码分析器会检查代码。您将根据所应用的规则深入分析代码中可能存在的潜在问题。 下面是 Helix QAC中深入代码分析的示例 。 Helix QAC 中的代码分析示例 准确性 手动源代码审查容易出现人为错误。自动化工具不是。 他们扫描每一行代码以识别潜在问题。这有助于您确保在测试开始之前就有最高质量的代码。毕竟，当您遵守编码标准时，质量是至关重要的。 静态分析和静态代码分析器如何帮助开发人员左移？ 静态分析是确保软件应用程序可靠性、安全性和可维护性的重要技术。它帮助开发人员及早发现和解决问题，提高代码质量，增强安全性，确保法规遵从性，并提高效率。使用静态分析工具，开发人员可以构建质量更好的软件，降低安全漏洞的风险，并最大限度地减少调试和修复问题所花费的时间和精力。 术语“左移”是指在软件开发生命周期（SDLC）的早期集成自动化软件测试和分析工具的做法。传统上，测试和分析通常是在编写代码后进行的，这导致了解决问题的被动方法。通过左移，开发人员可以在问题变成问题之前发现问题，从而减少调试和维护所需的时间和精力。这在敏捷开发中尤其重要，因为频繁的代码更改和更新可能会导致许多需要解决的问题。 静态分析的一个关键好处是，它可以节省调试和测试的时间和精力。通过在开发过程的早期识别潜在问题，您可以在任何问题变得更加难以修复（且成本高昂）之前解决它们。随着时间的推移，您还将获得更高质量的应用程序，这些应用程序更可靠、更容易维护，并防止问题在整个代码库中传播，从而使以后更难识别和修复。 使用静态分析左移的好处包括： 及早发现问题。 通过将静态分析集成到开发过程中，开发人员可以尽早发现问题，使其在成为更大的问题之前得到解决。这减少了调试和维护所需的时间和精力，并有助于确保代码的可靠性和安全性。 降低成本。 在SDLC中较早地解决问题可以降低后期修复bug和其他问题的成本。这可以节省时间和资源，并降低可能影响项目时间表的延误或其他问题的风险。 提高代码质量。 静态分析有助于识别编码标准违规和其他可能影响代码质量的问题。通过尽早解决这些问题，开发人员可以确保代码编写良好、可维护且易于调试。 增强的安全性。 静态分析工具可以识别代码中的安全漏洞，允许开发人员在代码发布到生产环境之前解决这些问题。这可以降低安全漏洞和其他可能影响应用程序安全性的问题的风险。 使用静态分析左移如何帮助提高利润 通过静态分析左移还可以提高组织的估计投资回报率 （ROI） 和成本节约。 静态分析的主要优点之一是它能够在SDLC早期发现缺陷和漏洞。从长远来看，早期检测可以节省您的公司时间和金钱。根据 美国国家标准与技术研究院（NIST） 的一项研究，修复缺陷的成本随着开发周期的进展而显着增加。在需求阶段检测到的缺陷修复成本可能约为 60 美元，而在生产中检测到的缺陷可能高达 10000 美元！通过采用静态分析，组织可以减少进入生产阶段的缺陷数量，并显著降低修复缺陷的总体成本。 除了降低修复缺陷的成本外，静态分析还可以提高代码质量，从而进一步节省成本。改进的代码质量可以减少测试、调试和维护所需的时间和精力。 IBM 的一项研究发现 ，通过提高代码质量，修复缺陷的成本最多可降低 75%。 安全性是静态分析可以帮助降低成本的另一个领域，尤其是与安全漏洞和负面品牌状态相关的成本。 IBM的一项研究发现，数据泄露的成本可能在125万至819万美元之间。静态分析可以在SDLC的早期发现安全漏洞，使组织能够在部署软件之前修复这些漏洞。通过这样做，组织可以显著降低安全漏洞的风险和成本，并保护其声誉。 除了节省成本外，静态分析还可以提高生产力。通过在开发周期的早期发现缺陷，开发人员可以减少日后调试和修复缺陷所需的时间和精力。这可以为其他开发活动（如功能开发或测试）腾出时间。通过提高生产力，组织可以减少软件开发的时间和成本，并提高更快地交付软件的能力。 在软件开发中采用左移方法可以为组织带来显着的成本节约和投资回报率。通过及早发现缺陷和漏洞，公司可以显著降低修复缺陷的成本，提高代码质量和安全性，并提高生产力。这些好处可以提高客户满意度、提高软件质量并降低开发成本。 如何选择静态代码分析器？ 在决定哪种工具适合您时，需要考虑以下几点。 程序设计语言 分析器是为许多不同的编程语言设计的。因此，选择一个支持你的语言的工具是很重要的。 标准 静态分析器的主要用途之一是符合标准。因此，如果你所在的行业需要编码标准，你需要确保你的工具支持该标准。 为什么选择 Perforce 静态代码分析器工具进行静态分析？ 30多年来，Perforce静态分析解决方案一直备受信赖，能够为各行各业的关键任务项目团队提供最准确的结果。 Helix QAC 和 Klocwork 经过认证，符合编码标准和合规要求。而且它们提供的假阳性和假阴性更少。 亲身体验 Perforce 静态代码分析工具对软件质量的影响。立即注册免费试用。

在软件开发中， Shift-Left 是一种帮助开发人员在软件开发过程早期发现漏洞和编码错误的做法。 Shift-Left Security 是一种有效的方法，它专注于安全性，并有助于在软件发布之前很久就解决代码中的任何安全问题。 在这里，我们概述了什么是 Shift-Left Security ，并提供了有关静态分析 器如何 帮助您在 SDLC 中及早发现安全漏洞的指导。 什么是 Shift-Left Security ？ Shift-Left Security ，或对安全采取 “Shift-Left 方法 ” ，是在软件开发生命周期 （ SDLC ） 的早期执行安全检查或与安全相关的任务的想法。 Shift-Left 通常应用于测试，目的是根据执行时间提高这些任务的效率，并确保这些必要的任务不会留到开发周期结束，并且在最坏的情况下，完全省略。 与更传统的方法不同，即等到部署的最后阶段才测试应用程序并扫描安全漏洞，在 SDLC 中向左转移有助于避免下游的长时间延迟，因为它允许您在集成、测试、记录甚至发布代码之前发现代码中的潜在安全风险！ 作为更大的 Shift-Left 运动的一部分， Shift-Left Security 意味着在开发过程的早期（或线性开发时间线的左侧）检查安全问题，以便您可以识别编码问题并更快地修复缺陷，以免它们变得过于昂贵或难以管理。 Shift-Left 测试 是一种通过避免在周期后期对代码和测试进行返工来提高代码质量和减少测试工作量的方法。这种类型的测试已经是一个既定的原则。 因此， Shift-Left Security 建立在相同的基本过程和概念之上，在开发周期的早期优先考虑漏洞检测和预防，构成了更广泛的 DevOps 和 DevSecOps 自动化的一部分。 为什么 Shift-Left Security 性对 DevOps 有益？ 将安全性向 Shift-Left 动旨在提高最终产品的安全性，鼓励合作低成本，并加快上市时间。 等到开发过程结束可能会导致成本的修复，尤其是在需要重大架构更改的情况下。另一方面，尽早发现和修复错误可能意味着在代码缺陷上花费的时间和金 钱更少。现代 DevOps 团队通过为项目使用 CI/CD pipeline 的开发人员自动化安全门控和反馈系统，为开发人员提供 Shift-Left Security 流程支持。 许多开发人员也更喜欢这种早期方法的效率，因为他们不会因为经常切换任务而中断。签入代码后获得静态分析、动态分析或测试结果所需的时间越短，开发人员就越有可能对最近编写的代码记忆犹新。您甚至可以使用节省时间的解决方案，例如 IDE 和 Klocwork 或 Helix QAC 插件，甚至在签入代码之前即可获得结果，从而进一步简化流程。在停止处理任务之前获取结果比等到签入代码和持续集成 （ CI ） 运行分析要快得多。 随着越来越多的组织意识到 Shift-Left Security 的好处， Shift-Left 的应用领域也在不断增长。例如，据 《福布斯》 报道 ，将安全性考虑纳入到 云计算 中已成为一个重要趋势。 Shift-Left Security 最佳实践 如果已准备好开始在 pipeline 中将安全性向 Shift-Left 动，则可以开始实施以下一些最佳做法： 1. 评估您当前 的软件开发流程。 您当前 在开发 pipeline 中的哪个位置测试安全漏洞？它会在这个过程的早期发生吗？是否有任何瀑布式方法变得更加敏捷（例如，不是迭代测试缺陷，而是集成可以持续监控代码和识别安全漏洞的安全工具）？ 评估开发 pipeline 的工作原理以及代码如何从开发转移到生产。恶意行为者可能会找到机会在这些阶段中的任何一个阶段更改代码，因此早期检查可以经常内置到您的整个 pipeline 中，并实现版本控制和以 IP 为中心的设计等技术，以确保开发安全。一个好的开始是检查现有的文档，如果存在差距，与 DevOps 和 SecOps 成员交谈，以识别和记录缺失的组件。 2. 建立新的 Shift-Left Security 策略。 一旦您对当前方法的位置有了很好的了解， 请创建 一个文档来 定义您 的新 Shift-Left 策略。此策略可能包括将安全性向左转移的总体目标、组织将如何定义 Shift-Left 以及所涉及的流程和工具、如何衡量成功，以及个人和团队责任。 3. 对开发团队进行安全编码最佳实践方面的培训。 Shift-Left Security 培训 是一个持续的过程，不仅针对开发人员 —— 组织需要为能够支持和优化 Shift-Left 安全性的合适团队（如产品、开发和 QA ）提供培训。随着对代码的更多关注，以及不同的团队成员知道要寻找什么和使用哪些工具，安全测试将成为 您整体 开发战略的重要早期步骤。 安全 编码标准 提供了由具有多年知识的安全专家编制的规则和指南，有助于预防、检测和消除可能危及软件安全的错误。主要安全标准包括 CERT CWE ， OWASP ， DISA STIG ， IEC 62443 等。对团队进行此类标准方面的培训并实施静态分析工具以在整个代码库中强制实施编码标准，将保护您的代码在流程的早期免受编码漏洞的影响。 4. 自动化安全流程。 作为 CI/CD 流程的一部分，自动化有助于支持整个过程中所需的持续测试。您可以使用多种方法来自动化安全性，包括静态应用程序系统测试 （ SAST ）、动态应用程序安全测试 （ DAST ）、交互式应用程序安全测试 （ IAST ） 和运行时应用程序自我保护（ RASP ）。这些方法在自动化安全性方面都很重要，但对于 Shift-Left ， SAST 是最适用的。借助 SAST ，您将能够在开发 pipeline 的早期检测漏洞。 Perforce 静态分析工具如何帮助实现 Shift-Left Security 静态分析可以在开发过程的早期，在软件测试开始之前执行。这种类型的分析通过查找国际公认的安全编码标准的已知漏洞模式来发现问题，并检测代码中的早期缺陷。它还提供快速反馈以及漏洞及其原因的确切位置。 Helix QAC 是一种静态分析和 SAST 工具，可根据风险的严重程度确定编码问题的优先级，针对 最 关键的缺陷，并提供准确的诊断和可操作的结果，从而帮助您立即修复最重要的问题，从而帮助在 SDLC 的早期发现安全漏洞。 Klocwork 是一种静态分析和 SAST 工具 ，可在引入安全漏洞时发现这些漏洞，帮助您尽早修复漏洞，并提供符合行业安全标准以及您自己的组织要求的合 规 性。 亲眼看看值得信赖的工具 Helix QAC 和 Klocwork 如何帮助您的组织将安全性向左转移。

大多数原始设备制造商不会从电动汽车（ EV ）的销售中获利，但计划快速进入市场的电动汽车初创公司不必遭受同样的损失。 随着电池价格飙升、零部件成本高昂和销量低迷，电动汽车初创公司的盈利能力逐渐下降，必须将软件开发视为提高预算、进度和工作水平的一种方式。了解电动汽车软件开发面临的主要挑战有助于初创公司领导者找到解决这些问题的途径。 正如我们在 这篇博客中 所解释的那样，收回成本并不一定意味着提高车辆价格或裁员 —— 相反，它是关于在高度复杂和受监管的软件环境中寻找更智能地工作的选择。 电动汽车软件开发的范围 每辆电动汽车都是车轮上的软件平台，因此设计、编写和验证代码是寻求开发效率的第一步也就不足为奇了。车辆组件可以分解为不同的软件域，以帮助您了解对工作量、预算和进度的影响。 对于电动汽车初创公司来说，这些领域在很大程度上倾向于具有重要功能安全和安保要求的新型前沿软件组件。与传统的原始设备制造商不同，初创公司必须从头开始建立这些能力，同时还要管理投资者信心、开发人员招募和监管合 规 等业务现实。 电动汽车初创公司应关注的 3 个 挑战 除了上市时间和供应链问题外，以下是影响电动汽车软件开发的三个最大挑战，以及开发团队如何解决这些问题。 1. 通过遵守标准来保护消费者和企业 开发人员可能认为，遵守汽车安全和安保标准会降低创新和发布里程碑的速度。现实情况是，标准和准则提供了一个预定义的框架，用于保护业务免受现场代价高昂的故障的影响。 三种常见的汽车标准包括： ISO 26262 认证 ISO 26262 标准 规定了功能安全流程，以减少对车辆乘员的危害，并基于称为汽车安全完整性等级（ ASIL ）的风险分类系统和证明合 规 性的开发工件的验证。 MISRA MISRA 由制造商、组件供应商和工程咨询公司开发和维护，为 C 和 C++ 提供了编码指南，以帮助代码确保安全性、可靠性和可移植性。 CERT CERT 编码标准 是由软件开发和软件安全专业人员社区开发的 C 、 C++ 和 Java 准则，旨在帮助确定违反该特定规则或建议的可能后果。 电动汽车初创公司在标准合 规 性方面面临着艰巨的任务：规划、测试和报告必须从头开始纳入开发流程。如果被推迟或忽视，随着发布窗口的缩小和监管机构要求提供证据，缺乏合 规 框架将威胁到原型和消费者交付。 2. 尽量减少通货膨胀的影响 通胀压力正在破坏整个汽车供应链中已建立的定价模式，并限制消费者的购买力。电动汽车初创公司不能等待有利的市场条件，但它现在可以在软件团队中寻找机会，创造成本效益高、可持续的实践。 初创公司的好处是开发人员没有时间请求许可来测试和采用新工具来简化他们的工作。他们正在积极研究任何有助于他们专注于重要事情的事情：提供强大且符合要求的新功能。开发领导者可以通过了解以下内容来加速这种灵活性： • 当前处于开发过程中的所有应用程序和工具 • 新工具卸载手动工作和提高工作产出的机会 • 每种工具的所有权和责任 • 谁访问 它们以及访问频率 • 每个用户 / 团队的每个工具的成本 • 工具和流程中的冗余 • 许可条款和续订日期 3. 采用有效的自动化技术 鉴于对标准 和安全合 规 性 的严格要求 ，电动汽车初创公司可以在 这里利用 静态分析工具等自动化技术： • 编码标准合 规 性 — 识别违反安全和安保标准中规定的规则和准则的情况。 • 代码覆盖率合 规 性 — 满足 ISO 26262 代码覆盖率要求，如语句、分支和 MC/DC 。 • 问题优先级 — 根据风险对问题进行排名，以避免浪费时间或对开发人员造成 “ 问题疲劳 ” 。 通过静态分析将电动汽车初创公司的创新成本降至最低 现在是电动汽车初创公司明智地减少浪费的时候了。随着通货膨胀造成供应链波动，市场监管壁垒越来越高，电动汽车软件开发团队现在必须优化支出并培养 其工具 和流程的弹性。 Perforce 静态分析和 SAST 工具通过精确准确的静态代码分析工具，确保代码质量、可靠性、安全性和安全性的持续合 规 性，从而简化有效的电动汽车软件开发。从概念验证到移植到新车型， Helix QAC 和 Klocwork 保持了高开发速度并降低了市场风险。 欢迎联系北汇信息获取试用~

Helix QAC 2023.1 对 MISRA C:2012修订版4和MISRA C:2023的覆盖率为100%，对 AUTOSAR C++14的覆盖率为96%。它还更新了CWE最新版本v4.10的合规模块。 在这一版本中Helix QAC和Validate平台的集成也有重大改进，Validate平台提供了软件对跨工程以及Perforce静态分析产品的软件洞察力。 编码标准覆盖范围（ MISRA C:2012修订版4、MISRA C:2023、AUTOSAR 和 CWE） MISRA针对C程序设计语言的软件开发指南。这些指南的目的是促进嵌入式系统上下文中的代码安全性、安全性、可移植性和可靠性。 • 100%覆盖 MISRA C:2012 修订版4，包括新规则和 3 条指令以及对现有指南的更新。 • 新的指南涵盖了额外的C11/18特性，包括对Threads和Atomics标准库的使用，以及对现有特性的新规则。 Helix QAC也对MISRA C:2023有100%的覆盖度，该指南将以前的修订、修正和技术整合为一个单一的、全面的版本。MISRA C:2023将于今年晚些时候出版。 AUTOSAR AUTOSAR C++ 14 的覆盖率已提高到 96%。 CWE 更新了 CWE C 和 CWE C++ 合规模块，以与最新版本的 CWE 4.10 保持一致。 Perforce Validate 持续安全性和代码合规性平台为嵌入式和关键任务应用提供功能安全性、安全性、可靠性和质量保证。 Validate平台为整个组织的代码库提供分析数据、趋势和配置的集中存储，为所有Perforce Static Analysis产品提供独立平台。 2023.1 改进了 Helix QAC 和Validate平台之间的集成。 • 将问题抑制状态与Validate连接的项目同步 ￮ 桌面 GUI 和 Eclipse IDE 插件 • 最新版本的项目基线支持 • Streams 功能为单个代码库提供变体、分支和版本的管理和高效报告 • 改进了使用Helix QAC桌面工具和Validate之间的Validate和QAC GUI/CLI诊断一致性生成的MISRA合规报告 • 改进了使用 Validate 和 QAC GUI/CLI 生成的 MISRA 合规性报告 Helix QAC 桌面工具和验证之间的诊断一致性 • 上传性能改进 • WebAPI 功能，用于与 SDLC 中的其他工具和流程集成 提高生命质量 CLI • 最新版本工程的Validata基线支持（ qacli 基线） • Validate独立的检查器和忽略功能 （ qacli 上传） • 抑制同步 GUI • 验证依赖项检查和忽略能力 • 抑制同步到桌面 • MISRA 合规报告和标准合规报告的改进 Eclipse IDE 插件 在IDE插件中Validate的连接支持 RCMA • 分析存储器的使用和效率的提高 Helix QAC 2023.1中的重要改变 停止使用公告 CCT Generator在2023停止使用 Helix QAC 2023.1将不再支持传统的独立CCT生成工具。 Helix QA C2021.3中引入的’qainject’工具将取代当前的CCT发生器。因此，使用遗留工具生成的CCT将被弃用，不再受支持。 从 QAC软件包中移除不支持的静态CCT 通过使用带有’qainject’的自动CCT生成，改进了对各种编译器的构建监控, 到2023.1，以前包含在Helix QAC软件包中的大多数静态CCT将被删除。自动生成的与使用静态默认CCT相比，CCT有望提供更准确的分析结果。除了GCC、Visual Studio和通用编译器之外，所有的静态CCT都被移除了。 ➡️ 立即体验最新版Helix QAC，发送邮件至info@polelink.com

提到鸿蒙操作系统（Harmony OS），想必大家并不陌生。其底座OpenHarmony是由华为捐出的鸿蒙开源系统，并且由开放原子开源基金会孵化及运营, 目标是面向全场景、全连接、全智能时代, 搭建一个智能终端设备操作系统的框架和平台, 促进万物互联产业的繁荣发展 1 。数月前，华为再度突破新的领域——与国航签约，华为将助力国航在以OpenHarmony为底座的HarmonyOS框架上构建应用/服务。作为汽车行业的新势力，华为在汽车领域拥有卓越的表现，市面上很多汽车已将Harmony OS作为其车机系统。 本文对OpenHarmony主干源码1348版本的wifiiot_hispark_pegasus工程进行静态测试。 编译OpenHarmony 当前阶段，大部分的开发板源码还不支持在Windows环境下进行编译，如Hi3861、Hi3516系列开发板，因此需使用Ubuntu的编译环境对源码进行编译。 搭建Docker环境 在使用Docker环境前需要先完成以下操作： 1 、 安装Docker 。 2、 获取OpenHarmony源码 。 编译源码 完成Docker环境搭建并获取源码后，我们就可以对源码的 wifiiot_hispark_pegasus工程 进行编译了。具体步骤如下： 进入源码根目录，执行 h b set ，根据提示选择 wifiiot_hispark_pegasus工程。 执行 h b build -f 编译wifiiot_hispark_pegasus工程。显示build success说明编译成功。 编译的成功证明环境搭建成功，进而可以顺利进行Klocwork静态分析。 Klocwork 静态分析 Klocwork 是一款针对开发人员生产力、 SAST和DevOps/DevSecOps的最佳静态代码分析 工具，支持 C、C++、C#、Java、JavaScript、Python和Kotlin ，可以 与CI/CD工具、容器、云服务和机器配置集成，使自动化安全测试变得容易。 下面是Klocwork测试O penHarmony 代码的步骤。 执行如下命令创建Klocwork工程openharmony_test： kwadmin --url http://192.168.9.116:8089/ create-project openharmony_test Klocwork Validate平台是一个集中存储分析数据、趋势、度量和整个组织代码库配置的平台，可通过web浏览器访问。我们来到web端Validate中就可以看到刚才所创建的工程openharmony_test。 执行下面同步命令，将 wifiiot_hispark_pegasus工程源码同步到Klocwork的openharmony_test工程中来。 kwinject hb build -f 分析工程 执行分析前可在Validate中进行分析配置，勾选分析过程所需的规则。 配置完成后执行下面命令开始分析： kwbuildproject --url http://192.168.9.116:8089/openharmony_test ./kwinject.out --tables-directory ./Openharmony/my_tables 显示下面结果表示分析成功。 将分析结果上传到Validate kwadmin --url http://192.168.110.110:8089/ load openharmony_test my_tables/ 下面结果表示上传成功： 分析结果 来到Validate查看 K locwork分析结果。 工程配置的详细信息如下： wifiiot_hispark_pegasus工程工1652个文件，共分析了1557个.c文件、95个系统头文件，源码共180720行，注释共138844行。分析模块类别为：C和C++分析、CERT分析以及MISRA分析。 M ISRA 规则分析结果 Category Details列举了wifiiot_hispark_pegasus工程对MISRA规则违规情况的汇总： 违反Mandatory Rules规则数量排名前十的文件汇总： C ERT 规则分析结果 列举了wifiiot_hispark_pegasus工程对每条CERT规则违规情况的汇总： 违反每条CERT规则数量排名前十的文件汇总： Validate 合规报告 Validate可生成定制化合规报告。这里我选择生成pdf形式的Generic合规报告，列举出了违规情况详情、规则的分类与其对应的检查器、违反规则源码所在文件及行数。 下面我们选出部分违反的MISRA C 2012 with Amendment 2 (C11) certified与CERT规则进行简单介绍： MISRA C 2012规则分为三种不同类别：Mandatory（强制）、Required（要求）和Advisory（建议）。 Mandatory Rules: 1. FUNCRET.GEN: Non-void function does not return value . 规则说明：FUNCRET.GEN检查器用于查找没有return语句的非void函数。 违规源码： int32_t OH_HashMapCreate 函数是非空函数，但返回空值，所以此处违规。 2.UNINIT.STACK.MUST: Uninitialized Variable. 规则说明：UNINIT.STACK.MUST检查器查找变量未初始化的行为。 违规源码： 第28行的变量vargs未初始化，所以此处违规。 Required Rules： MISRA.LOGIC.SIDEEFF: Right operand in a logical 'and' or 'or' expression contains side effects . 规则说明：&&和||运算符的右侧操作数的求值取决于左侧操作数的值。如果右边的操作数包含副作用，那么这些副作用可能会发生，也可能不会发生，这可能与程序员的预期相反。 如果程序员依赖于发生的副作用，则对其中一个逻辑运算符的右手操作数的条件求值很容易导致问题。 违规源码： 在162行中，将第118行的FOR_EACH_HC_VECTOR函数定义为一个for循环，而在表达式index < (vec).size(&(vec)) && \ (iter = (vec).getp(&(vec), index))中，&&操作符的右操作数中发生了赋值运算，导致该表达式具有副作用，所以此处违规。 Ad visory Rules MISRA.GOTO: Goto statement is used 规则说明：不得使用goto语句，因为无限制地使用goto语句会导致程序的非结构化和极难理解。 违规源码： 第669行使用了goto语句，所以此处违规。 CERT C Recommendations: CERT MSC13-C: Detect and remove unused values VA_UNUSED.GEN: Value is Never Used after Assignment. 规则说明：VA_UNUSED.GEN检查器查找分配给局部变量的值，这些值在下一次赋值或函数结束之前从未使用过。 违规源码： 第141行对变量sessionKey赋值，但后面未使用该变量，所以此处违规。 CERT C Recommendations: CERT EXP00-C: Use parentheses for precedence of operation CERT.EXPR.PARENS: The precedence of operators within expressions should be made explicit. 规则说明：运算符在表达式中的优先级应该是显式的。 违规代码： 第395行的表达式if (altGroup != NULL && AddStringToJson(reqParam, FIELD_ALTERNATIVE, altGroup) != HC_SUCCESS)优先级不明确，所以此处违规。 总结 本文使用Klocwork 对OpenHarmony部分代码 进行 静态测试， 我们 了解了OpenHarmony对 于 汽车行业常用 编码 规范的合规情况 ，同时也对M ISRA 与C ERT 编码规范有了初步的认识。通过此次分析我们不难看出，与过去的版本相比，OpenHarmony的代码质量在不断提升。但对于想将OpenHarmony应用于汽车行业的开发者来说，还需要根据汽车行业的要求，对OpenHarmony代码进行调整，以符合汽车功能安全与信息安全编码规范。