tag 标签: 静态测试

相关帖子
相关博文
  • 热度 3
    2024-5-15 10:35
    366 次阅读|
    1 个评论
    带你走近MISRA C++:2023
    随着汽车工业迈入数字化转型的新纪元,软件的安全性与可靠性已跃升为设计和开发核心环节的重中之重。MISRA C++标准的诞生与演进,精准地回应了行业发展的需求。自MISRA C++标准首次面世以来,它便被奉为汽车软件工程师在开发实践中的圭臬。 MISRA C++的发展史 MISRA C++的起源可以追溯到MISRA C标准的成功制定和广泛应用。MISRA C是一套针对C语言的编码规范,首次发布于1998年,它迅速成为汽车行业中软件安全性和可靠性的标杆。(回顾MISRA C:2012介绍请见文章 《带你走近MISRA C:2012》 )随着C++在工业界的普及,尤其是在汽车电子控制系统中,对C++的类似规范的需求日益增长。基于MISRA C的成功经验和市场需求,MISRA组织随后发布了适用于C++03标准的编码规范MISRA C++:2008。这是首个针对C++语言的MISRA标准,包含一系列的规则和指导原则,这些规则覆盖了从编程实践到代码设计等多个方面,旨在帮助开发者编写出更加安全和可靠的代码。 MISRA C++:2008规范发布后,得到了业界的广泛认可和采纳。它不仅在汽车行业中得到了应用,还扩展到了航空、医疗设备和工业控制等多个领域,并对这些行业产生了深远的影响。随着C++语言标准的不断更新和新特性的引入,MISRA C++:2008也在经历不断的修订和更新,以保持与C++标准语言的同步,并覆盖新出现的语言特性。 MISRA C++:2008与AUTOSAR C++14 但随着后续新版本C++标准的发布,MISRA C++:2008并未将新的C++语言特性纳入,于是AUTOSAR组织发布了AUTOSAR C++14编码规范。 AUTOSAR C++14在制定时,大量借鉴了MISRA C++:2008的规则。MISRA C++:2008是基于C++03标准制定的,而AUTOSAR C++14则是基于更新的C++14标准。AUTOSAR C++14吸收了约91%的MISRA C++:2008规则,并对其进行了扩展和更新,引入了针对C++11/14特性的规范。 MISRA C++:2023 MISRA C++:2023发布于2023年10月,这是MISRA C++的最新版本。它为使用ISO/IEC 14882:2017定义的2017语言版本(C++:17) 开发的安全关键型软件的组织提供指导。 MISRA C++:2023规则分类 MISRA C++:2023整合了AUTOSAR C++14编码规范, 共179条准则。这些规则按照性质分为两类: Rule(规则)和Directive(指令),包含175条Rule和4条Directive。规则有三种不同类别:” Mandatory(强制)”、” Required(要求)”和“Advisory(建议)”, Mandatory类别的规则中包含5条Rule,Required规则中包含122条Rule和4条Directive,Advisory规则中包含48条Rule。 图1 MISRA C++:2023规则分类 图2 MISRA C++:2023规则类别 MISRA C++:2023还引入了MISRA C++的Rule可判定性分类。可判定性区分标准为是否能在任何情况下明确回答“该代码是否遵循了这条规则?”这个问题。 图3 Rule的可判定性分类 要注意的是,可判定性并不适用于Directive规则。 接下来让我们进一步了解MISRA C++:2023编码规范。 什么是 MISRA C++:2023 Rule 9.5.2,为什么它很重要? MISRA C++:2023 引入了 Rule 9.5.2:“ for 范围初始值设定项最多应包含一个函数调用” ,以避免在基于范围的 for 语句的 for 范围初始值设定项创建临时对象时可能发生的未定义行为。 为了理解为什么会发生这种情况,让我们仔细看看基于 C++ 范围的 for 循环。 什么是 C++ 中基于范围的 for 循环? 在编程中,循环用于重复代码块。当我们知道要在代码块中循环多少次时会使用for循环。C++ 基于范围的 for 循环是在 C++11 中引入的,作为容器迭代的简洁表示法。传统循环源自 C 语言,具有可选的循环初始化,然后是循环条件,最后是循环增量表达式。 传统for循环可用于迭代容器,如下所示: std::vector v = { "Example", "vector", "of", "strings" }; for ( auto &&i = v.begin(); i != v.end(); ++i ) { std::cout << *i << “ “; } std::cout << std::endl; 使用基于范围的for时,迭代器的使用是隐式的: for ( auto &&s: v ) { std::cout << s << “ “; } 对于同一循环,这是一个更简单的表示法。C++ 语言标准指出它是以下方面的缩写: { auto && __range = v; auto __begin = __range; auto __end = v.end(); for (; __begin != __end; ++__begin) { auto &&s = *__begin; std::cout << s << “ “; } } 但是,这种表示法存在一定的局限性。在上面的示例中, __range 是用 v 初始化的,这是一个更简单的变量,但也可以使用一个复杂的表达式,为其创建多个临时对象。 让我们考虑使用一个函数,该函数返回字符串的向量,并具有: 一个输出用空格分隔的字符串的循环,如上所述; 第二个循环,打印第一个字符串的字母,用空格分隔: std::vector createStrings() { return { "Example”, "vector", "of", "strings" }; } int main() { for ( auto w: createStrings() ) { std::cout << w << " "; } std::cout << std::endl; for ( auto c: createStrings() ) { std::cout << c << " "; } std::cout << std::endl; } 如果我们执行此操作,第一个循环将按预期运行,但第二个循环将调用未定义的行为 。 问题是 createStrings() 有两个函数调用。最里面的调用是 createStrings 的调用 ,最外面的调用是对索引运算符 的调用。 未定义行为的原因是 “ createStrings ”返回的临时对象 用作“ operator ”调用的参数,因此,根据 C++ 的规则,临时对象的生存期不会延长。 MISRA C++:2023 Rule 9.5.2 如何防范未定义的行为 MISRA C++:2023 Rule 9.5.2 旨在防止这种情况。 MISRA C++:2023 引入了规则 9.5.2,该规则要求for范围初始值设定项最多应包含一个函数调用。 它还建议通过在循环范围之前的单独声明中执行内部函数调用来解决此问题。例如: auto strings = createStrings(); for ( auto c: strings ) { std::cout << c << " "; } 现在,初始值设定项中只有一个函数调用,因此生存期扩展具有所需的效果,并且行为已完全定义。 请注意,此问题已在 C++23 中得到解决,其中初始值设定项的所有临时项的生存期已扩展到整个 for 语句。(原文请参考《 Avoiding Bugs in Range-Based For-Loops with MISRA C++:2023®》 ) 关注更多MISRA C++2023内容请见直播回放《汽车行业为何需要MISRA C++:2023》,本期课程我们联合了嵌入式静态分析领域公认的行业领导及先驱Perforce公司,并邀请到其合规总监Jill Britton女士探讨在这项汽车行业调查中的发现并介绍MISRA C++2023为何如此重要。 使用 Helix QAC 执行 MISRA C++:2023 规则 Perforce 的 Helix QAC 是一款静态分析工具,在提供 MISRA C 和 MISRA C++ 合规性检查以及许多其他有价值的分析功能方面处于领先地位。 Helix QAC 通过其标准合规性模块为 MISRA C++:2023 规则提供 100% 的强制执行覆盖率,现已推出。 作为Perforce公司的合作伙伴,北汇信息将为客户提供优质的静态代码测试工具和服务,欢迎您发邮件到marketing@polelink.com,申请Helix QAC免费试用。
  • 热度 3
    2024-4-20 18:03
    248 次阅读|
    0 个评论
    前言 在汽车与自动化行业,基于模型的开发过程中,从业者希望能够在保证建模效率的同时确保模型质量。此时,合理使用建模工具变得尤为重要。合适的工具不仅能够通过建模规范检查分析测试模型的质量,还能根据分析结果对模型进行自动改进。本篇文章为您介绍广受业界认可的静态测试工具MES Model Examiner® (MXAM) 。从MXAM在静态测试中的应用角色到实际演示与10.0版本功能更新,本文带您透彻了解MXAM如何能轻松帮助您实现优质建模。 基于模型的开发中静态测试的应用与MXAM MXAM是用于对Simulink®、Stateflow®、Embedded Coder®和TargetLink®模型进行全面静态分析的专业工具,主要应用于软件V型开发流程的左侧设计阶段,覆盖从架构到单元设计和实现的全过程。 基于模型的开发(MBD)依赖基于需求的,测试驱动的工作流来持续地确保质量。软件V型开发流程由左侧的设计阶段和右侧的测试阶段组成。功能质 量和功能的适用性是右侧测试阶段的主题,而设计的适用性和设计质量则是设计阶段关注的重点。设计质量和功能质量同样重要,因为模型设计的适用性能够有效促进功能的适用性。 那么,模型设计质量应如何保证? 模型静态测试能够帮助工程师保证模型设计的适用性:不仅可以改进已在开发过程中的模型,还可以通过质量保证前置帮助模型在代码生成前确保质量,生成代码的质量得以有效提升。 实际应用中,MXAM支持高度自动化的静态分析并致力于Simulink和TargetLink模型的可读性,鲁棒性,避免模型错误以及改进生成代码。 图1是一个Simulink模型的次级子系统。可以看出,模型目前存在违背建模规范的多项错误。例如第1处,模块命名应位于模块下方,而不是上方。再比如第2处,对于常值模块而言,其命名不应使用具体的、非0和1的数字,而应当设置为参数进行表示。对于模型的可读性来说,图1的信号流未对齐(第3处)。模块的命名应当被清晰识别,而第4处显然不符合建模规范的相关要求。第5处的输入端口隐藏在了系统布局内。此外,出于避免模型错误的出现,第6处的乘积模块不应存在超过两个输入端口…等等,这些问题严重影响了该Simulink模型的可读性和设计质量。图2展示了该模型经过MXAM修改优化后的结果:所有在之前讨论过的错误都被一一准确修正,模型的可读性得到了显著提升。 由此可见,评估模型的建模规范合规性在保证模型质量的实际应用中至关重要。此环节主要评估模型的布局,数据和控制流,数据类型,及其配置情况。模型的布局要求确保模型元素之间的关系和连接方式符合设计规范。模型的数据和控制流要求检验可能的逻辑错误及路径偏差。模型中的数据类型定义必须正确且一致。模型的配置情况则要求模型的配置参数符合设计规范。 这样的评估需要遵循相关的模型设计原则或标准,例如MISRA,MATLAB Simulink,或相应建模规范文件等等,设计原则的具体应用主要通过对根据相应规范而设置的模型指标的检验评估实现。例如汽车功能安全行业标准ISO 26262 – 6: 软件级别产品开发中对汽车软件架构所提出的具体建议和原则。其中,模型的复杂度,大小,和非相干度是检验模型是否符合相应建模规范的重要指标。模型的复杂度分析旨在发现模型中可能导致问题的复杂结构或关系,及时优化并简化模型,确保模型合规。模型的大小意在评估模型子系统,接口等等的规模,确保模型的可理解性和可维护性。模型的非相干度要求减少模型中的非相干性,以此确保模型各部分之间的关联适度。 模型指标的检验分析可以通过静态测试的方式在模型开发中及早实现,提高模型的质量,并保证软件系统运行的稳定性和安全性。在模型开发过程的敏捷工作流中,建立模型之后,根据建模规范或行业标准的要求分析模型指标,再生成清晰且全面的分析报告,并根据报告结果对模型进行修复,最终实现并输出优质的模型。 在模型开发过程中执行静态测试,可通过敏捷工作流实现。如图3所示,敏捷工作流中,首先建立模型,再根据业界标准和建模规范进行模型分析,得出清晰全面的分析报告,最后根据分析报告的结论快速解决和修复模型遇到的问题,最后实现质量门的通过,轻松实现优质建模。在这一过程当中,MXAM和MoRe (MES Model & Refactor® (MoRe), 现已集成在MXAM中) 两大工具,分别在敏捷工作流的不同阶段为建模工作提供有力支持。 图3:MXAM与MoRe为模型开发过程中敏捷工作流的不同阶段提供支持 通过启动模型分析,MXAM可以向用户展示模型根据建模规范一致性的分析结果报告,如图4所示的分析结果视图。 图4:MXAM分析结果视图 从展示形式来说,如图5所示,MXAM中的报告视图可展示为不同的导览方式,如规范文档导览(Document Navigation)和模型工件导览(Artificial Navigation)。规范文档形式下,在报告和文档的每个级别都显示聚合的分析结果:模型名称、分析完成的时间。在工具栏中,还可以通过选择树查看分析结果。工件导览是以模型结构树的形式显示相应系统或子系统对应的模型聚合分析结果。 图5. MXAM报告视图的不同导览方式 内容而言,图6显示了模型的合规报告视图右侧显示了模型的合规分析结果列表(Findings),模型架构分析的相应指标(Metrics),模型合规性的注释列表(Annotations),模型分析的配置详情(Analysis Configuration)和模型分析指标的摘要(Metrics Summary)。 图6. MXAM合规分析结果 用户还可以通过菜单(Menu)或过滤选项(filter)选择并查看相应的分析结果。分析结果的详细信息可以在详情结果视图(Finding Details)查看。如图7所示,用户可以查看到违反相关建模规范的详细信息和结果描述。 图7. MXAM违规项的详细信息 比如出现错误的具体路径(Path)和具体模块(Name),和出现这条错误报告的具体原因。用户可以通过路径及模块名称上的超链接直接到达模型中该错误所在的位置。修复选择(Repair Finding)可以帮助用户一键修复错误。 对于建模规范来说,此处以建模规范mcheck_misra_slsf_030_c为例,在详情页中(如图8所示)可以找到关于这一建模规范的详细描述,包括检查项通过该建模规范或不通过的评判标准(Pass-Fail Criteria),以及相应的解决方案(Solution)和修复的具体描述(Repair Action)。 最终的检查报告可以HTML-、 PDF-、 EXCEL-、XML-以及MXAM自带的mxmr格式快速导出。 图8. MXAM建模规范详情页 MXAM v10.0: MoRe的集成与功能升级 MoRe现已成为MXAM的一部分。 在前文中已提到,MXAM能够在模型敏捷开发流程的多个阶段提供强有力的支持:加速模型分析流程,快速生成报告,并辅助自动修复。同样来自MES模赛思的MATLAB Simulink扩展建模辅助工具MES Model & Refactor® (MoRe)能够为敏捷开发流程中的建模和修复提供高效帮助。 MoRe能将您日常建模中的步骤自动化,省去大量重复单调的操作,帮助您在建模时专注于重要步骤,节约时间,全面提高工作效率。现在,在MXAM全新版本v10.0之下, MoRe已集成在MXAM中。MXAM的功能变得更为全面,全力支持您基于模型的开发过程。 如图9所示,这是普通的MXAM安装程序。用户可以在此处选择许可证文件,而MoRe的标志已在此标注。接下来用户可以继续正常的下载步骤,MoRe的下载会自动随MXAM同步进行。 图9. MoRe的安装已集成在MXAM下载器中 进入MATLAB界面后,MXAM和MoRe即可马上使用。如图10中的Simulink 模型所示,"MES MoRe"选项已经显示在菜单中,可以直接调用MoRe的相关功能。 图10. MoRe的轻松调用 MoRe最新版本的所有功能均包含在内,集成在MXAM中和MoRe独立工具使用的体验相同。不仅是自动布局,MoRe同样可以从多角度帮助模型进行快速优化。不论是从将Goto/From模块转换为信号线,或是命名问题, MoRe都可以辅助您改进模型,并节约大量时间。 新增可选扩展全局参数及建模规范。 新版本中,MXAM 对Embedded Coder AUTOSAR运行实体中的参数进行了扩展。在使用Embedded Coder进行模型开发时,如果静态测试包括了自动生成的模型部分,则会导致大量的时间和资源浪费。MXAM v10.0对分析参数进行了扩展(见图11)。如果将此参数设置为“True“,那么MXAM只会对运行实体子系统中的模型元素进行分析。 图11:MXAM v10.0新增参数: "Global.AnalyzeAutosarRunnablesSubsystemsOnly" 在开发AUTOSAR模型的过程中,工程师一般通过ARXML文件开始进行模型生成和框架的构建,因而模型会自动生成很多层级以及其他文件。而模型的自动生成部分并非必须进行静态测试,因其必须遵循AUTOSAR提供给您的内容,模型结构固定,对固定部分进行静态测测试会耗费大量不必要的时间和精力。这个新的全局参数能够帮助工程师实现只分析 AUTOSAR运行实体中的模型和函数,这样开发工程师就可以将模型分析专注于实际应用和可以进行更新修改的模型部分,从而节约大量时间。 而对于建模规范而言, MXAM新版本的更新完全围绕主题“ 功能安全 “展开。 建模规范mes_slsf_1500: 确保可重用模型组件具有已解析并启用的链接。本建模规范完全专注于功能安全。在工程师应对可重用模型组件时,应当确保所有链接已解析,如果其中有尚未解析的链接,将模块用未启用的链接进行连接可能会导致潜在的问题。使用本建模规范可以确保模型引用可用且已更新,同时提高了可测试性,确保模型在进入下一个质量保证阶段前一切就绪。 另一项更新来自mes_slsf_2200: 避免舍入模式(Rounding Mode)。绝大多数 Simulink中的计算模块都可以设置特定的舍入模式。此时,确保代码生成的舍入模式都被明确定义十分重要。本建模规范能够避免模型将舍入模式设置为“Simplest”,并且对应的MES检查项中也有对应的检查参数可供使用。 本次更新还包括建模规范mes_slsf_3500: 禁止在Stateflow图中使用用户定义的事件。基于事件的建模可能会导致模型难以维护,出现隐藏控制流和可能的无限递归。同步问题也可能发生,且Stateflow的早期返回逻辑可能导致不良后果。此建模规范可确保模型不会在Stateflow图中使用用户定义的事件,从而防止隐藏控制流出现在模型之中。 除此之外,新版本还添加了对三个版本的TargetLink用户的相应变量类别和全新的MES检查。 如您想了解并体验MXAM v10.0全新版本,欢迎您申请免费试用,了解更多。
  • 热度 3
    2024-3-29 09:43
    208 次阅读|
    0 个评论
    应用程序安全 (AppSec) 对于高效和有效的安全措施至关重要,有助于解决软件应用程序日益严重的安全威胁。在这里,我们将讨论应用程序安全 (AppSec) 的原则、实施它的最佳实践以及您应该使用的 AppSec 工具。 什么是应用安全? AppSec 是在硬件、软件和开发过程中在应用程序级别查找、修复和防止安全漏洞的过程。它包括对应用程序设计和开发以及整个生命周期(包括应用程序启动后)的措施的指导。 具有强大应用程序安全性的组织认识到,AppSec不是一项单一的技术,而是一个持续的过程,涉及最佳实践和流程,旨在帮助预防和解决应用程序面临的网络威胁。许多组织使用服务和AppSec工具来加速应用程序开发,同时减少代码漏洞并防止网络安全风险。 为什么应用安全很重要? 应用程序安全性很重要,因为软件应用程序中的漏洞很常见 - 据报道,84%的安全事件发生在应用程序层。 为什么是应用层?由于应用程序包含重要的公司和用户数据,因此应用程序层是恶意行为者的主要目标。如果黑客能够在合法组织和合法用户之间的交换过程中访问或重定向信息,他们可以使用各种技术并利用漏洞——包括代码注入、访问控制中断、安全错误配置和密码故障——窃取公司数据和资源、登录凭据和其他特权信息。 应用程序安全保护软件应用程序代码免受此类威胁。AppSec战略计划包括在软件开发生命周期(SDLC)的所有阶段检查应用程序安全性。 通过遵循应用程序安全措施,您可以确保在开发周期的早期识别和处理软件应用程序中的弱点和漏洞,以免它们成为严重的安全漏洞。 应用安全最佳实践 AppSec 最佳实践应从软件开发生命周期的开始启动,并被整个产品团队采用。当整个团队都参与并在整个开发过程中积极测试、识别和修复代码漏洞时,您更有可能防止以后可能出现的安全问题。 把你的DevSecOps团队想象成一个管弦乐队,把你的AppSec工具想象成你的乐器,把最佳实践想象成排练。你要确保你在正确的音高和时间演奏正确的音符,无缝协调,创造出最终的、响亮的结果。所有这些工具、实践和流程协同工作,以创建应用程序的安全性和功能安全性的更大整体。使用AppSec工具和最佳实践,您可以为成功奠定基础。 遵循以下最佳实践以实现高效的软件应用程序安全性: • 建立 应用程序安全风险配置文件 ,以识别潜在的安全漏洞和弱点。 此方法可帮助您评估潜在风险并确定不同类型的应用程序的优先级,以帮助做出最有利于组织的战略安全决策。通过询问有关网络攻击者如何可能进入应用程序并将这些安全点记录到配置文件中的问题,您可以避免在维护评估中重复相同的基础,并加快未来的风险评估。 • 识别并消除软件应用程序中的安全漏洞。在开发应用程序时,对应用程序进行彻底的风险评估将帮助您识别和修复安全漏洞。 • 识别并解决开源和第三方软件中的安全漏洞。 这是一个重要的实践,因为对于应用程序,您只有这么多的控制权。一旦他们在世界上访问并与第三方软件交换数据,您还必须对该软件中的潜在风险进行说明并做好准备。 • 使用正确的应用程序安全工具。 现在,越来越多的数据和资源正在迁移到云中,应用程序开发人员越来越依赖于使用有助于指导安全软件开发的AppSec工具。使用正确的 AppSec 工具,您可以快速识别和修复软件中的漏洞,同时确保符合行业编码标准。 • 为您的团队提供应用程序安全培训。 如果您的整个团队都掌握了最新的知识和专有技术来识别应用程序代码中的常见弱点,那么您将在开发过程中更早、更快地发现问题并加速开发。将 AppSec 工具作为培训的一部分也将有助于加快应用程序的上市时间。 采用应用程序安全最佳实践将最大限度地降低风险并保护数据。为了确保您的应用程序安全措施高效且有效,您需要正确的工具。 SAST 和 DAST 都可以保护您的软件免受漏洞的影响,从而使 DevSecOps 过程更容易。以下是每种测试方法的优点: • SAST :也称为“白盒测试”,SAST是一种软件安全漏洞测试。该工具会在您开发应用程序时分析源代码,以检测和报告可能导致安全漏洞的弱点。通过使用此类工具,可以在开发早期识别安全漏洞。 • DAST :也称为“黑盒测试”,DAST是一种软件安全漏洞测试。这种类型的工具在运行时检测指示存在安全漏洞的情况。通过使用这种类型的工具,您可以在开发周期的后期识别安全错误、运行时和与环境相关的问题。 除了用于测试代码的静态分析器之外,还有许多其他工具可以在 本地和云 中测试和保护应用程序和 API ,这些工具可在应用程序的整个 SDLC 中提供 漏洞的可追溯性 。此外,您还可以使用复杂的 移动应用 测试 工具,帮助您像用户一样进行测试,并通过测试失败分析获得快速反馈。 在整个开发工作流程中对应用程序进行 持续的性能测试 使您的团队能够获得高质量的代码,并最大限度地减少可能导致安全问题的错误和漏洞。 应用安全左移安全性 在 SDLC 中左移是许多开发人员实施的原则,用于在开发过程的早期执行诸如测试软件之类的任务,而不是等待过程结束时(或线性开发时间线的“右侧”)。 左移安全性, 或“采用左移方法”进行安全性,意味着在 SDLC 的早期执行安全检查或其他与安全相关的任务。 这种早期方法可帮助应用程序开发人员提高效率,因为他们不会因必须经常切换任务而中断。通过在开发人员脑海中还记得最近编写的代码时获得安全结果,他们可以在当时和那里快速进行更改,而不是等到他们签入代码并持续集成运行分析。 将安全措施应用于应用程序可确保在产品仍处于开发阶段时仍有时间查找和修复漏洞,并提高开发人员对常见漏洞和 AppSec 最佳实践的认识。 应用安全编码标准 安全编码标准是用于识别、预防和消除可能危及软件安全性的软件漏洞的规则和准则。 • CERT :CERT是一系列安全编码标准,针对C,C++和Java中可能导致安全风险的不安全编码实践和未定义的行为。 • CWE :常见弱点枚举 (CWE) 列表可识别 C、C++、Java 和 C# 中的软件安全漏洞。 • DISA-STIG :DISA-STIG 是技术软件安全发现的集合。 • OWASP:开放Web应用程序安全 项目(OWASP)确定了最大的Web应用程序安全风险。最受欢迎的 OWASP 资源是 OWASP Top 10 ,它们是应用程序的 10 个最关键的安全风险。 • ISO/IEC TS 17961: ISO/IEC TS 17961 是C语言检测安全漏洞的安全编码标准。 应在开发周期的早期使用 AppSec 工具(如静态代码分析器)来强制实施安全编码标准,以确保对潜在安全漏洞的最佳解决方案。 为什么Klocwork和Helix QAC是理想的AppSec工具 针对 C、C++、C#、Java、JavaScript、Python 和 Kotlin 的 Klocwork 静态应用程序安全测试 (SAST) 可识别应用程序软件的安全性、安全性和可靠性问题,帮助确保符合安全编码标准。它还使您能够在编写代码时自动执行源代码分析。 此外,Klocwork的差异 分析 使您能够仅对已更改的文件执行快速增量分析,同时提供与完整项目扫描结果相同的结果。这确保了尽可能短的分析时间。 Klocwork还为您提供以下好处: • 在开发早期检测代码漏洞、合规性问题和违反规则的行为。这有助于加快代码审查以及开发人员的手动测试工作。 • 执行行业和编码标准,包括 CWE 、 CERT 、 OWASP 和 DISA STIG。 • 报告一段时间内和跨产品版本的合规性。 Perforce的另一个静态分析解决方案 Helix QAC 可以轻松遵守安全编码标准,并在 应用诊断中获得 更少的误报和漏报 。它提供了深度覆盖和风险优先级,以帮助您首先解决最重要的问题,并涵盖安全标准,如 CERT C、CWE(包括 CWE Top 25)和 ISO/IEC TS 17961(C 安全)。 使用验证指挥您的应用安全交响曲 Klocwork和Helix QAC的调查结果都可以导入 Perforce 的Valdate 平台 ,该平台是一个持续的安全和代码合规性平台,为所有Perforce静态分析产品提供单一管理平台。借助 Validate,您可以为嵌入式和任务关键型应用程序提供功能安全性、安全性、可靠性和质量保证。 Validate是一个单一的真相来源,它使您能够看到一组统一的报告,显示更完整的应用程序安全情况。该平台还能够整合来自各种其他工具的发现,将测试数据与静态分析结果一起提取,以识别未覆盖测试路径的代码中的关键缺陷。 正如您的 DevOps 团队就是您的管弦乐队一样,插入 Validate 的工具是单独的乐器,当它们组合在一起时,可以创建一首有凝聚力的交响乐,从而增强应用程序的整体性能和安全性。 ➡️ 联系北汇信息申请静态分析(Helix QAC、Klocwork)免费试用
  • 热度 4
    2024-3-14 09:41
    450 次阅读|
    0 个评论
    静态分析可帮助面临压力的开发团队。高质量的版本需要按时交付。需要满足编码和合规性标准。错误不是一种选择。 这就是开发团队使用静态分析工具/源代码分析工具的原因。在这里,我们将讨论静态分析和使用静态代码分析器的好处,以及静态分析的局限性。 什么是静态分析? 静态分析是一种调试方法,通过自动检查源代码来完成,而无需执行程序。这使开发人员能够了解他们的代码库,并有助于确保其合规性和安全可靠性。 什么是静态代码分析? 静态代码分析是指静态分析工具执行的操作,即根据一组(或多组)编码规则分析一组代码。 静态代码分析和静态分析通常与源代码分析一起互换使用。 静态代码分析解决了源代码中可能导致漏洞的弱点。当然,这也可以通过手动源代码审查来实现。但是使用自动化工具要有效得多。 静态分析通常用于遵守编码准则,例如 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 静态代码分析工具对软件质量的影响。立即注册免费试用。
  • 热度 4
    2024-3-7 10:37
    362 次阅读|
    0 个评论
    如今,新车购买者的关注点更多地集中在“数字驾驶舱生态系统体验”上,而不是传统功能,如马力和燃油经济性。汽车行业已将提供这种体验作为优先事项,包括全连接的车载信息娱乐 (IVI) 系统,包括触摸屏显示器、语音命令以及集成的信息和娱乐功能。 什么是车载信息娱乐系统? 越来越多的终端消费者希望能够完全连接到他们的“数字生态系统”体验。“智能座舱”是车载信息娱乐系统的核心,其正在成为原始设备制造商及其汽车品牌的关键差异化优势。 车载信息娱乐(IVI)是一种车辆系统的组合,用于向车辆乘客提供音频/视频接口和控制元件——触摸屏显示器、按钮面板、语音命令等。 以下是构成“智能驾驶舱”的组件或模块的快照: 用户界面: 驾驶员和乘客通过触摸或旋钮和转盘在屏幕上看到的内容和互动的内容。 主机: 包括显示器、外壳、电路板、CD/DVD 播放器、收音机和多个处理器(统称为车辆的主机)。它也是车辆所有物理输入的接口,例如音响系统和/或外部摄像头。 操作系统 (OS): 作为信息娱乐系统的核心,操作系统控制对主机中的处理器、内存、存储和显示器的访问。 应用程序框架模块 :管理从 Spotify 应用程序到导航和与系统交互的所有内容,例如文本转语音和语音命令。它控制所有应用程序功能以及哪些应用程序可以出现在主机中。 移动集成: 使车辆能够连接各种智能手机和设备。支持 Wi-Fi、蓝牙和即插即用程序,例如 Google Play 的 Mirror Link、Apple CarPlay 和 Android Auto,可将手机媒体和应用程序的修改版本导入屏幕。 汽车平台: 应用程序框架和操作系统之间的软件桥梁,支持多媒体、视频、导航、音频、广播、声学、软件更新、云服务等。 根据行业研究公司Frost&Sullivan最近的一份分析报告,到2025年,“车联网”将构成全球汽车市场近86%的份额。同年,IVI市场预计将达到427亿美元。 但是,IVI系统本身以及第三方应用程序也为网络犯罪分子创造了许多漏洞威胁点。汽车行业IVI系统的原始设备制造商和一级供应商必须努力确保这些系统中的嵌入式代码符合安全和安保关键标准。这样做有助于避免召回成本和对商业声誉的影响。 网络攻击给车载信息娱乐系统带来严重风险 车载信息娱乐系统在短短几年内取得了长足的发展,随着AI、ML和AR等新兴技术进入汽车领域,成为这些嵌入式“数字驾驶舱”系统的标准集成,预计该系统将进一步快速发展。虽然IVI系统目前用于提供信息和娱乐,但它们很快就会作为车辆内所有功能的主要通信部件发挥更大的作用。用户可以通过 AR 和 3D 导航和警报、交互式交通和危险警告以及与道路上其他车辆的通信方式看到更多信息。 随着IVI系统每年增加更多的功能和连接性,管理无线软件更新的开发人员必须考虑到车载网络的无数攻击面和潜在漏洞。 由于 IVI 系统连接到互联网并使用 Android、RTOS、Linux、QNX 和 Windows Embedded Automotive 以及 USB 连接、蓝牙和 Wi-Fi 运行操作系统,因此黑客可以通过多种方式找到这些入口点并利用代码中的漏洞,这可能会影响用户隐私和安全。 高达 90% 的软件安全问题是由编码错误引起的。这就是为什么确保不会发生故障的情况很重要的原因。然而,代码质量仍然没有达到许多IVI系统应有的水平,导致新车出现故障和繁琐的IVI。希望提高代码质量和车载信息娱乐网络安全的开发人员应使用编码标准和静态分析工具,作为网络安全和质量优先最佳实践的一部分。 车载信息娱乐系统编码标准的重要性 可以说,联网车辆是通过其IVI系统连接到互联网的四轮计算机。由于IVI系统是车内网络的一部分,它可能为黑客创造许多易受攻击的威胁点,他们可能能够控制驾驶员的智能手机并访问个人数据,操纵车辆安全关键系统功能,或制造系统更新程序。因此,IVI 系统开发实践必须遵守编码标准和指南。 最近还有两项有望使IVI系统受益的举措是ISO/SAE 21434标准和联合国欧洲经济委员会(UNECE) WP.29法规 。这些标准相辅相成,为汽车行业确保新一代互联汽车的安全做好准备。 ISO /SAE 21434 标准 建立在其前身 ISO 26262 的基础上 ,该标准不包括软件开发或子系统。ISO/SAE 21434 侧重于汽车电子设计和开发中固有的网络安全风险。汽车软件安全标准提供了一个结构化的流程,以确保在汽车产品的整个生命周期内将网络安全考虑因素纳入其中。 与 ISO/SAE 21434 不同,WP.29 法规要求 OEM 负责管理整个供应链的网络安全风险。 IVI 网络安全漏洞如何影响 OEM 原始设备制造商及其一级供应商需要采取措施避免其IVI嵌入式软件漏洞的负面影响,因为攻击可能会威胁到驾驶员及其乘客的隐私和安全。网络安全事件可能代价高昂且耗时,并可能导致车辆召回,最终影响利润、声誉损失和组织生产力。 IVI系统中的软件故障经常导致召回。MSN.com最近对最不可靠的家用汽车进行的一项调查显示,最新一代的汽车位居榜首,57% 的车辆出现故障,其中33%的汽车受到IVI问题的影响。 由于安全和安保问题,信息娱乐系统中的软件故障可能会导致召回。例如,故障可能允许驾驶员在驾驶时浏览互联网和看电视。软件故障也可能导致汽车屏幕在寒冷天气下熄灭。 即使故障不是很明显,恶意行为者也可能利用软件中的这种类型的漏洞,关闭影响安全和安保的关键功能。 确保IVI系统中的代码符合必要的标准和合规性要求,有助于避免召回成本以及对商业声誉和盈利能力的影响。 为什么SAST对于车载信息娱乐系统软件代码至关重要 静态应用程序安全测试 ( SAST ) 软件测试方法检查和分析应用程序源代码、字节码和二进制文件的编码和设计条件,以发现 IVI 系统软件中的安全漏洞。SAST背后的工作机制是一个静态分析工具,用于检查设计和编码缺陷。 Klocwork 是 企业 DevOps 和 DevSecOps 的理想选择 , 是行业领先的 静态分析和 SAST 工具,适用于 C、C++、C#、Java、JavaScript、Python 和 Kotlin 设计的源代码。此外,10 家顶级汽车零部件制造商中有 9 家依靠 Perforce 静态分析工具来帮助确保其汽车软件的安全性和合规性。