这两年汽车行业的变化比过去十年都大。

2024 年，欧盟 CRA 正式生效，带 SBOM 成了出口欧洲的硬门槛。
2025 年，AI 编程工具从实验室杀进生产环境，CodeBuddy、通义灵码、Trae 三个国产 AI IDE 同时开打，开发者在写代码的阶段就被 AI 接管了一部分。
2026 年——也就是现在——信创要求从"建议使用"变成了"必须执行"，越来越多的自主品牌车企在招标时直接写明了"投标方需使用国内自主可控的安全检测工具"。

在这个背景下，很多 Tier 1 的功能安全经理和软件质量负责人开始重新审视自己用了多年的工具链。

QAC 和 Parasoft C/C++test 都是好工具，这没得说。但它们诞生于二十年前，设计时考虑的场景和今天面对的问题已经不太一样了。

---

它们依然是主力——但场景在变

先客观说一句：QAC 和 Parasoft 在汽车嵌入式代码合规领域，该做的都做了。

• 二十年的 MISRA 规范覆盖积累
• TÜV 的 ISO 26262 工具认证，行业标准制定者级别的信用背书
• 被全球几乎所有 OEM 的功能安全审核体系接纳

如果你的项目场景是：给外资 Tier 1 供货、甲方明确指定、只需要跑 MISRA 合规然后交报告——那这两款工具仍然是最稳妥的选择。这个格局短期内不会变。

但问题在于：这个"短期"还能持续多久？

2026 年的 Tier 1 面临的已经不是三年前的问题了。拿一个典型的智驾域控项目举例，它需要的安全覆盖是这样的：

甲方要求：MISRA 合规 → QAC 能管 ✅
甲方没说但现实需要：
  → 多路传感器输入异常怎么办？              ← QAC 不管
  → 芯片 SDK 是二进制的，里面有后门吗？      ← QAC 不管  
  → 出口欧洲车型要出 SBOM，谁能出？          ← QAC 不管
  → 百万行代码每天告警上百条，谁审得过来？    ← QAC 管不了这么多

不是 QAC 变差了，是这个时代的"软件安全"定义变宽了。

---

盲区一：代码合规 ≠ 软件鲁棒

QAC 做的是静态分析——不跑代码，只看源码有没有违反规则。

它在发现"你有没有用危险函数"这件事上很强。但下面这种场景它发现不了：

座舱域控在高温老化测试中偶发黑屏。定位后发现是触控驱动收到了一组异常高频信号，导致音视频进程堆溢出。
QAC 检不出这类问题。因为代码本身没有语法错误，逻辑也没写错——问题是"异常输入下系统扛不扛得住"。

这类问题，需要用**模糊测试（FUZZ）**来解决——也就是往系统里灌非预期的数据，看它会不会崩、会不会漏、会不会挂。

FUZZ 不是新概念，在安全研究领域已经用了很多年。但过去它主要是个研究工具，企业和开发团队很少去碰，有"门槛太高/不知道什么场景该用/自己搭环境太折腾"之类的各种原因。

但这几年情况在变化。一些国产 FUZZ 工具在低代码化上做了很多改进，不需要手写脚本，在 IDE 里配置好策略就能跑——这才让 FUZZ 从安全研究人员的冷兵器变成了开发工程师可以日常使用的温度计。

---

盲区二：源码扫得再干净，也管不了拿到手的二进制

汽车电子电气架构从分布式往集中式走，域控里的代码结构早就变了。

现在的典型项目构成是：30% 自研代码 + 70% 第三方库/芯片 SDK。

地平线的芯片 SDK 是 .a / .so，NXP 和 TI 的也是。黑芝麻、芯驰的也是开源一部分，核心库还是二进制。

QAC 只能看源码。拿到二进制固件的时候，它没有任何招数：

• 这个 SDK 版本里有没有已知高危 CVE？
• 编译时 Stack Canary 开了没有？
• 第三方库有没有被篡改过？

这些问题在几年前可能不是必答题——"芯片厂商出的 SDK，我们信任就完了"。

但 2025-2026 年，供应链安全已经从"信任"变成了"验证"。欧盟 CRA 要求产品上市就带 SBOM，里面的组件信息得精确到版本号和补丁状态。信任不能替代验证，这句话已经从安全圈的口号变成了法规要求的底线。

这个场景需要的是二进制分析（BAT）——不需要源码，直接分析编译产物，提取组件信息、检测编译选项安全状态、识别已知漏洞。国内能做这个的厂商还不多，但需求已经在快速增长。

---

盲区三：欧洲 CRA 一来，需要的不只是代码检测

欧盟《网络弹性法案》（CRA）不是未来的事——它在走生效流程了。

一旦全面执行，所有进入欧盟市场的数字产品都必须附带 SBOM，并且要在产品生命周期内持续监控组件漏洞。

这意味着 Tier 1 需要回答这些新问题：

• 你用的每个开源组件，版本号和许可证是什么？
• 这个版本有没有未修补的高危漏洞？
• 下次 OTA 升级后，组件清单有没有变化？有没有引入新的风险？

QAC 和 Parasoft 不做这个。它们的产品设计里就没有"追踪开源组件生命周期"这个功能模块。

国内 SCA 工具这几年进步明显。新一代厂商不再用"文件哈希匹配"那种老方法——在代码语义层面做分析，能判断一个开源组件的漏洞在当前的代码路径里到底可达还是不可达。这意味着告警量可以砍掉 60-80%。对于百万行代码级别的项目来说，这个效率差异是质变的。

---

这些盲区的共同特点

回头看上面三个盲区，你会发现它们有一个共同点：

它们不是 QAC 或 Parasoft 的 bug，而是它们的产品设计边界。

QAC 诞生于 2000 年代初期。那时候没有智驾域控，没有 CRA，没有 AI 编程，汽车的代码量还没到千万行级别。工具的任务就是"跑 MISRA，出报告，过审核"。

2026 年的现实是：

AI 编程在谈秒级生成代码 → 代码量爆炸 → 安全检测也得跟着提速
信创在推全面国产化     → 外围工具也得配得上这个节奏
欧盟在推 CRA          → 供应链安全从锦上添花变成了必选项
ASPICE 4.0 在更新     → 审核标准在变严，覆盖维度在变宽

这些变化叠加在一起，让一个很尴尬的事实浮出水面：QAC 和 Parasoft 在第一层做的事依然很好，但安全合规的需求已经从一层扩展到了四层。

第四层：供应链合规（SBOM / SCA）       ← 法规驱动的新刚需
第三层：运行时鲁棒性（FUZZ）            ← 智驾域控带来的新场景
第二层：二进制安全（BAT）               ← 供应链安全的新要求
第一层：代码合规（SAST）               ← QAC/Parasoft 的舒适区

---

一个正在形成的行业做法

我最近观察到的情况是：部分走在前面的一级供应商和主机厂，已经在用"分层"的思路重新配置自己的工具链。

不是一刀切替换掉 QAC，而是：

保持第一层：QAC 继续跑 MISRA 合规——甲方清单满意，审核有据可依
补齐第二层：引入国产 BAT 工具做二进制分析和固件验证
补齐第三层：引入国产 FUZZ 工具做异常输入测试
补齐第四层：引入国产 SCA 工具出 SBOM，应对欧盟 CRA

为什么补的是国产工具而不是国际厂商的同类型产品？

有行业接触的朋友应该有所耳闻：一是国际工具价格不便宜，二是信创政策在加速落地，三是部分国内厂商在一些能力上确实走出了差异化的路线——比如 FUZZ 工具跟 AI 结合的自动测试策略生成、SCA 工具的可达性分析、BAT 工具对国产芯片 SDK 的覆盖等等。

这算不上什么"颠覆"或"替代"。更准确的说法是：QAC 体系在扩层，原有的工具解决不了新层的问题，缺口需要新的工具来补。 这是一个很自然的分工演进。

---

写在最后

如果你正在准备 ASPICE 审核，或者在评估欧盟 CRA 合规的应对方案，一个值得投入时间的动作是：把你当前的工具链摆在"四层模型"里看一遍，看看哪几层有人做了，哪几层还是空着的。

空着的那几层——可能就是未来半年到一年你最需要补齐的短板。

---

如果你觉得这篇文章对你有帮助，点个赞和收藏，方便回头对照检查自己的工具链。

作者在汽车嵌入式软件领域工作多年，文章基于个人行业观察，欢迎交流探讨。