Parasoft静态分析怎么配置 Parasoft静态分析误报怎么确认

如何设置Parasoft的静态分析，以及怎样确认它产生的误报，许多开发团队在引入代码检查的时候，都会遇到这类问题。静态分析并不是把工具装好，点一次扫描就结束了，在这之前，要去看工程的配置是否准确，挑选的规则集是否合适，在那之后，还要看扫描出来的结果，能不能被开发人员弄明白，愿不愿意去处理。如果配置与真实项目差别很大，告警就会大量出现；如果判断误报时缺少依据，后面的评审又容易反复争论。

一、Parasoft静态分析怎么配置

要配置Parasoft的静态分析，第一步是把项目原来的环境还原出来，尤其是C或者C++的项目，宏定义、头文件的路径、编译器的选项、目标平台这几样，只要有一处配错了，工具看到的代码就会和实际编译出来的代码不一样。扫描表面上是完成了，实际上很多告警很可能是由于配置不准确被带出来的。

1、先把工程环境配准确

配置的时候，需要核对编译器的版本、源码的目录、include的路径、宏定义、库的依赖，还有目标平台。第一次扫描完成以后，不要只盯着问题的数量，还要去翻看解析日志，如果日志里很多地方都出现了找不到头文件、符号识别不出来、条件编译的分支不正常的情况，那就说明工程的基础还没有配置稳妥，这个时候直接去处理告警，能起的作用并不大。

2、选一套合适的规则集

可以依照【MISRA】、【CERT】、【CWE】或者企业内部自己的编码要求，来选定规则集，然后再结合项目的安全等级，做一点删减。规则并不是开得越多就越好，和安全关系紧密的模块，要求可以严格一些，普通的业务模块，可以先抓住高风险的问题。对于老项目，如果一下子把所有规则都打开，常常会冒出几万条告警，开发人员根本看不过来，一个比较可行的做法，是先定下一个基准，以后再慢慢地把要求收紧。

3、把分析的范围说清楚

分析的范围要提前讲明白，核心的源码、平台适配的代码、测试代码、自动生成的代码，还有第三方的库，它们是否都参加扫描，应当有一个统一的说法。自动生成的代码和第三方库，如果不把它们排除，告警就会显得很杂乱；但是核心的业务代码，又不能随便被排除，否则扫描的结果看起来是干净了，实际的风险却还留在那里。

二、Parasoft静态分析误报怎么确认

Parasoft静态分析出现误报并不少见，但是不能因为“看起来不太像问题”就随手把它关掉。确认误报需要去看规则的含义、代码的上下文，以及运行时的条件，特别是空指针、数组越界、资源泄漏、没有初始化的变量这一类问题，宁可多花点时间多看一层，也不要随意就把它判为误报。

1、先看规则到底在检查什么

同样都是告警，有的只是代码风格上的事情，有的却可能影响到运行时的安全，像命名、括号、注释这一类的问题，可以拿项目规范去衡量；但是遇到内存访问、指针使用、除零、资源释放、数据竞争这类告警，就要小心得多，需要先弄明白规则关注的风险在哪里，然后再去决定用什么方法去处理。

2、对照代码的上下文来判断

需要顺着【变量来源】、【赋值位置】和【使用位置】去检查，确认告警的路径是不是真的能够成立。只看报错的那一行，通常是不够的。比如工具提示了空指针，可能是上游已经做过非空的检查，也可能是检查了另一个变量；提示了数组越界，可能是索引的范围在调用方已经被限制住了，也可能只是写代码的人默认“不会超出去”。这些都要回到代码的路径里去一条一条确认，不能靠着经验一句话就带过去。

3、把误报和暂不修复分开

误报是指工具的判断本身就不成立；暂不修复是指问题确实是存在的，但是项目做完评估以后，暂时把风险接受下来。这两样要分开来记录。比如一些底层的驱动去访问硬件的寄存器，可能是因为编译器的扩展，或者平台自身的特性才触发了规则，这类情况可以写一份偏离说明；但是如果只是因为“到现在还没有出过问题”，就不能直接把它当成误报来处理。

三、Parasoft静态分析结果怎么落地

静态分析真正让人头疼的地方，并不是头一次扫描，而是后面怎样持续去维护它。今天标记了一批误报，下一次扫描又原样冒了出来；这个分支把规则关掉了，另一个分支却没有关，结果就会越来越乱，所以工具生成的结果要和流程放在一起管理。

1、先处理新增的问题

对于老项目，可以先把历史告警的基准冻结住，把精力重点放在拦截新增的高风险问题上，新增的代码不应该再带进来严重的规则违反，修改旧代码的时候，也可以随手把相关的告警清理一下，这样就不会在一开始把团队压得太紧，又能让代码的质量慢慢地提高。

2、把误报的说明保留下来

误报确认以后，要写清楚判断的理由，比如输入的来源是固定的、边界在上游已经被限制住了、指针在进入函数之前就已经校验过了、相关的分支在目标平台上根本不会被编译进去。只写一句“false positive”显得很空，后面复查的时候差不多还是要重新看一遍。

3、定期复查被压下去的条目

规则升级、编译器发生变化、平台迁移以后，旧的误报结论可能就不再正确了，尤其是和安全相关的代码，不能长时期放着不去管。可以在版本变化的节点，抽查一部分suppress、waiver或者deviation，确认这些说明还能不能站得住。

总结

Parasoft静态分析怎么配置，以及误报怎么确认，关键的地方是先把工程环境配准，再让规则集和项目的编码要求对应起来。确认误报的时候，不要只看一行告警，要结合规则的含义、变量的路径、运行的条件和已有的控制措施去下判断。真正要落地的时候，新增问题要先被拦住，历史问题分批去治理，误报和偏离说明也要能够被复查，这样Parasoft的静态分析才不会变成一堆没人愿意翻看的告警，而是能服务项目质量的检查手段。