功能安全与信息安全：嵌入式工具链如何落地安全开发实践

1. 安全不再是“加分项”会场里被频繁追问的三个问题上海世博展览馆的过道不算宽今年最热闹的区域之一是功能安全与信息安全工具链的演示区。这是我2023上海国际嵌入式大会回顾系列的第六篇前几篇聊了MCU选型、实时操作系统和通信方案今天这篇想集中聊聊嵌入式系统里最难绕开的一件事怎么用开发工具把功能安全和信息安全的各项要求变成每天都能执行、能验证、能留下证据的开发动作。为什么会有这个选题因为我在展台边上听到的问题变了。前几年大家问的是主频多少、Flash够不够、调试器支不支持这颗芯片今年问得最多的是客户要ISO 26262要ISO/SAE 21434我的开发流程和工具链该怎么准备这个问题几乎每个做汽车电子和工业控制的工程师都躲不开。1.1 第一个问题ASIL D到底要“逐条跑”什么做域控制器的一位朋友跟我说他手里已经有一份ASIL D的安全需求清单但不知道从哪里开始执行。我的建议是别急着找安全机制先做两件事第一件把安全目标Safety Goal拆成功能安全需求和技术安全需求第二件把每条需求跟具体的实现元件、测试用例和验证结果绑定起来。这个绑定动作就是开发工具第一个发力的地方。ISO 26262里对需求可追溯性有明确要求安全需求从哪来、由谁实现、用哪些测试验证都必须能被追溯到。人工用Excel也能做但需求数量一旦超过几百条Excel的关联关系就会变成一团乱麻。我看到越来越多的团队引入需求管理工具或ALM平台把需求、设计、代码模块和测试用例放在同一条链路上管理。这样做的价值不只是方便查找而是到项目认证阶段你能直接导出一份完整的追溯报告告诉审计员这条安全需求是在哪一次测试里通过的覆盖率是多少有没有遗留问题。报告是工具自动生成的而不是临时补的可信度完全不一样。1.2 第二个问题信息安全的“合规底线”怎么落另一类提问者来自工控和汽车电子行业他们的共同点是产品本身跑得很稳定但客户开始要求提供信息安全方面的证据。汽车行业现在绕不开ISO/SAE 21434和车辆准入法规里的网络安全要求工控领域则经常被提到IEC 62443。这类标准给人的第一感觉往往是“又多了一堆文档要求”但仔细看会发现它们要求的核心动作是识别资产、做威胁分析、确定风险等级、设计缓解措施、在开发过程中验证缓解措施有效。这些动作必须落到工具链里才可持续。比如威胁分析和风险评估的结果可以映射到安全测试用例漏洞扫描和软件物料清单SBOM能证明你对第三方组件做了持续监控。如果这些活动散落在邮件、聊天记录和个人脚本里那无论底层芯片多安全审计时仍然拿不出完整证据。信息安全不是装一套系统就能宣布完成它更像一套持续运行的安全开发流程工具负责让流程里每一步都有记录、可复现。1.3 第三个问题功能安全和信息安全为什么会在同一个论坛里被反复放在一起严格来说它们解决的是不同问题。功能安全应对的是随机硬件失效和系统性设计错误目标是防止系统因为故障伤到人信息安全应对的是恶意攻击者对系统的干扰目标是防止系统被外部力量操控。但放到一辆车或一套工业控制器里两者是死死缠绕在一起的。远程攻击可以关掉你功能安全设定的安全状态反过来如果一个ECU进了ASIL D的Fail-safe状态但固件更新通道没有安全保护攻击者也能利用升级机制把系统打回不安全版本。所以现在成熟的团队会做一件以前很少做的事把功能安全分析和信息安全分析的结论互相引用在工具层面共用同一个需求库和测试平台。同一个缺陷既可能是功能安全测试发现的也可能是信息安全模糊测试发现的集中记录能避免两边各改各的。这次大会上不少工具厂商也在强调这种融合趋势我觉得这是最值得注意的行业变化之一。2. 功能安全工具链从静态分析到故障注入的完整闭环功能安全开发里有一句常被引用的话预防比纠正便宜。落到实际工作里这句话可以翻译成一件很具体的事——你要在代码阶段、单元测试阶段、集成测试阶段分别把问题拦住而不是等整车或整机跑起来才发现安全机制不生效。工具链的完整闭环大致分三段静态分析、覆盖率评估、故障注入。2.1 静态分析MISRA C和工具置信度的作用MISRA C/C规则集被很多项目当作静态分析的默认起点。但静态分析工具的价值不仅仅是把不规范的写法挑出来而是为你提交安全审计材料时提供一份客观、可复现的代码状况报告。ISO 26262要求对编码规范进行静态验证这一条几乎只有工具能完成靠人来翻代码是翻不完的。选静态分析工具时我会多问一句工具的误报和漏报策略是什么有没有针对MISRA和CERT C/CWE的规则包更重要的是工具本身能否提供证据说明它不会漏掉某些关键错误。这个概念在后文会详细说也就是所谓的工具置信度。另一个容易被忽略的点是规则裁剪必须留痕。很多团队嫌某些MISRA规则太严直接关掉但在认证审计时审计员一定会追问这条规则为什么禁用有没有评估过禁用后的风险严谨的做法是走正式偏差流程Deviation写清楚原因、风险和影响范围并把偏差记录和工具配置一起存档。我见过不少项目代码写得不错但就因为规则裁剪没有记录审计时反反复复补材料非常痛苦。2.2 覆盖率与MC/DC测试工具如何证明“真的测了”单元测试和覆盖率工具是功能安全证据链里最难绕过的一环。ISO 26262在软件单元验证里对ASIL C和ASIL D的覆盖率方法通常要求包含MC/DCASIL B可以做到语句和分支覆盖。MC/DC听起来抽象我举个最简单的例子判断条件if (a b)如果要证明a的输出能够独立影响结果需要用a为真、b为假和a为假、b为真两组输入来验证表达式里的条件越多需要的用例组合就越复杂。覆盖率工具能自动统计哪些条件组合被执行到了但自动统计不等于自动测试。工具可以帮你找缺口具体用什么输入去覆盖缺口仍然需要测试人员基于需求设计。这里有一条经验想分享不要为了追求覆盖率数字而构造跟需求无关的用例。我见过有的项目覆盖率到了98%但最核心的一条安全路径反而没测过因为大家都盯着数字忘了覆盖率只代表“结构执行过”不代表“行为符合预期”。覆盖率报告和需求测试用例放在一起看才算真正闭环。2.3 故障注入用CANoe、调试器和可编程电源测出“最坏情况”如果静态分析和单元测试是“预防”那故障注入就是“演习”。功能安全标准要求验证安全机制在故障发生后的响应比如通信超时检测、看门狗、电压监控能不能把系统带到安全状态。故障注入的手段可以按层次来分故障层次典型手段常验证的安全机制总线通信层用CANoe制造CRC错误、报文丢失、报文延迟、总线关闭通信超时监控、E2E保护、状态机跳转内存/寄存器层通过JTAG/SWD调试器强制改写RAM、外设寄存器或程序计数器ECC校验、CRC校验、内存保护单元系统级用可编程电源注入电压跌落用时钟源注入频率偏移电压监控、时钟监控、安全状态切换表格里说到的工具不是每一种都需要买很贵的设备。以CANoe为例不少工程师问过我哪款CANoe型号适合做功能安全和故障注入我的建议是先看你项目里跑的是什么总线。如果还是传统CAN/CAN FD一个VN1640或VN1610接口配上CANoe的Test Feature Set加上CAPL脚本已经能完成很大一部分报文级故障注入比如改CRC、注入错误帧、按场景丢报文。如果项目已经切到车载以太网、DoIP诊断甚至SOME/IP那就需要带千兆以太网口的硬件接口比如VN4610。很多人以为越贵的型号越保险其实关键不是型号新旧而是硬件接口的总线类型、时间戳精度和数据吞吐量能不能满足你的测试场景。提示故障注入用例一定要和安全机制映射起来。测之前先问自己我要触发的是哪类故障对应哪条安全需求预期系统进入哪个安全状态没有映射关系的故障注入只能算是破坏性测试到认证时基本用不上。3. 信息安全靠工具“守门”启动链、运行时、通信链路三件事信息安全开发这几年最大的变化是从“上线前的渗透测试”变成了“开发过程中的持续防护”。工具要守三道门设备启动时、设备运行时、对外通信时。3.1 Secure Boot与HSM把信任根焊死信息安全的第一步是设备不能被轻易重刷或越权调试。所谓Secure Boot简单说就是让芯片从上电第一条指令开始验证代码签名BootROM验BootloaderBootloader验应用固件每一级都只信任持有正确密钥签名的镜像。开发工具在这里要处理的事很具体生成和管理密钥、给固件签名、把公钥烧进eFuse或HSM、在调试器里读取启动流程的每一个验证节点。我在现场看了一个域控制器Demo工程师在调试器里放了一个脚本记录安全启动每一步的耗时和验证结果哪一级签名过期、哪一级证书链不对都能直接在trace里定位。这种把抽象安全机制变成可调试过程的做法才是开发工具该有的样子。这里说一个我自己踩过的坑很多人开发阶段为了方便把Secure Boot关掉或让调试口永远打开结果到量产前才想起来补。开发阶段当然可以开调试口但一定要设计成生产模式能锁死调试口的机制并且把密钥分成开发密钥和量产密钥两套。否则你辛辛苦苦搭的信任链最后等于没有信任锚。3.2 通信防伪与模糊测试在攻击者视角下找漏洞信息安全里最大的攻击面是通信接口。CAN总线本身没有发送者认证以太网和DoIP又引入了大量IP攻击面所以模糊测试在车载信息安全里越来越重要。模糊测试工具会向目标设备发送大量畸形、越界、半合法的报文观察设备是否出现崩溃、异常复位或内存越界。很多人以为模糊测试就是把随机数据往接口里灌其实效果更好的做法是基于协议规范生成测试用例先构造一个合法报文再在特定字段上做偏移、溢出、枚举值越界。这样的用例更容易触发解析器边界问题。模糊测试一旦发现崩溃就要立刻和调试器联动拿到崩溃现场的任务栈、寄存器状态和指令回溯。如果这两类工具没有事先打通一次模糊测试发现的问题可能要花两三天才能定位。3.3 代码审计与依赖管理在源头堵住漏洞再往开发流程上游走就是代码层面的安全工具。嵌入式设备很少全部代码都是自己写的总会用RTOS、协议栈、加密库、文件系统这些第三方组件。第三方组件一旦出现高危CVE你很难第一时间知道更难为自己的设备提供修复版本。软件成分分析工具能自动扫描工程里引用了哪些开源组件匹配漏洞库生成软件物料清单SBOM。配合静态应用安全测试可以在编码阶段识别常见的注入、越界、不安全API调用。信息安全工程师的角色也就变了不再是项目后期才出现的“杀手”而是要在开发早期把工具门禁规则定义出来让开发人员在提交代码时就看见扫描结果。安全上线不是某一个时间点的检查而是每一次构建都要跑的一套检查这是我在这次大会里听到并且非常认同的一句话。4. 展台观察集成开发环境正在变成“安全驾驶舱”今年工具链厂商的展台有一个共同趋势大家不再强调“我能设多少个断点”而是强调“我能记录多少系统信息”。对安全关键系统来说调试器打断点这件事本身就有点危险因为断点会改变程序执行的时序尤其是在中断密集的实时系统里。你想测最坏情况执行时间结果一打断点时序就不是真实时序了。4.1 非侵入式trace实时系统的“黑匣子”非侵入式的trace采集因此越来越受重视硬件实时记录指令流、任务切换、中断响应时间事后用工具分析跟飞机上的黑匣子一个道理。出现偶发问题时如果有一份完整的历史轨迹定位效率会高很多。这个能力在功能安全测试里特别重要因为安全关键代码往往要证明时序有没有违反约束。比如某个安全响应必须在10毫秒内完成工具可以给出每一次执行的耗时分布而不是只靠某一次通过的测试来证明。4.2 多核、异构与混合ASIL工具链如何应对复杂架构另一个被反复提到的词是多核和异构。现在一个域控制器里可能有多个CPU簇、GPU、NPU同时运行不同ASIL等级的任务。按照功能安全标准高ASIL等级的软件和低ASIL等级的软件如果跑在同一颗芯片上必须有足够强的隔离和干扰分析。工具链面临的挑战包括多核调试时如何同步所有核的断点cache一致性如果在运行时被破坏怎么快速定位多个核争用同一总线或外设时能不能看到真实的延迟曲线。我在展台前看某家调试器厂商演示过这样一个场景两个核往同一个外设寄存器写数据导致高优先级任务偶发超时。用传统断点方法很难抓但他们的trace工具把总线上每个访问周期都记录下来当场就找到了是谁抢占了总线。这种系统级视角在复杂多核平台的安全验证里几乎已经成为标配。4.3 CI流水线里的安全门禁把检查变成每一次提交最后是流程自动化。如果安全测试只在项目阶段末尾做一次大检查那安全属性永远是被动的。现在集成开发环境的边界正在扩展不少工具都能嵌入到CI/CD流水线里每次提交代码自动化跑静态分析、编译、单元测试、覆盖率统计和漏洞扫描结果不达标就拦住合并请求。我建议团队不要一上来就把门槛设得很高否则CI一片红海大家很快就麻木了。先从最关键的几条规则开始新增代码不允许引入高危MISRA违规、覆盖率和上次相比不能下降、依赖库不能新增已知高危漏洞。等团队适应了再把门禁范围扩大。工具是流程的放大器流程是乱的工具会把乱放大流程是稳的工具才能把稳变成可持续的自动化。5. 工具认证和团队协作买对工具只是开始逛展的时候经常听到一句话工具买回来只是第一步。这句话在功能安全和信息安全领域尤其成立因为这里涉及一个很多团队第一次接触时会发懵的概念——工具鉴定。5.1 工具鉴定Tool Qualification没那么玄我第一次接触ISO 26262里的工具鉴定时也被TCL、TI、TD这些缩写绕晕。举个不一定完全严谨但很容易理解的类比你请了一个助手帮你检查代码但你不清楚这个助手会不会漏掉问题。如果助手漏掉一个问题可能导致严重后果而项目里又没有另一道检查能接住那你对这个助手的要求就必须很高。工具鉴定就是这么一回事它不是一个贴着“通过认证”标签的绝对状态而是结合工具在项目中的使用场景来评估在什么情况下可能出错出错的影响有多大有没有探测手段。商业工具厂商提供的安全手册就是帮助你做这个评估的材料。所以采购编译、测试或静态分析工具时比起问“这个工具过了认证没有”更专业的问法是你们的Tool Qualification Support Kit里包含哪些材料能不能覆盖工具影响分析现场工程师听到这个问题就知道你是有备而来的。5.2 工具买了不等于流程建立了三个常见坑工具选对了项目还是可能翻车。我听到的失败案例大多不是工具性能不够而是使用方式出了问题。坑一静态分析报告生成后直接归档组里没人看直到认证前才翻出来。这是把工具当成了“存档机”。坑二覆盖率工具跑完看到90%就松口气但没人去分析未覆盖的10%里有没有关键安全路径。坑三功能安全用一套工具信息安全又用另一套孤立平台两边各测各的缺陷互相不引用。要避免这些坑需要在项目启动时定义清楚哪些指标是每次迭代要回顾的哪些问题必须闭环处理哪些测试资产是两边共用的。工具只是帮助你把这些规则固化下来规则本身还是得由人来定。5.3 功能安全工程师与信息安全工程师怎么协作最后说说人。信息安全工程师这个角色在嵌入式团队里这两年变得越来越重要但很多团队其实说不清他到底该干什么。一种很窄的理解是信息安全工程师就是负责抓包、做渗透测试、写漏洞报告的。在消费互联网产品里可能还行但嵌入式产品里远远不够。真正能帮上忙的信息安全工程师得能看懂硬件信任根知道HSM里有哪些密钥槽理解Secure Boot的启动顺序还得能辨别诊断协议里面哪些服务容易被滥用。这样他才能把安全需求转成工具门禁规则和功能安全工程师一起评审同一个测试报告。反过来功能安全工程师也需要了解信息安全的基本攻击面否则设计出来的Fail-safe状态很容易被远程攻击绕过。功能安全和信息安全之间的关系可以这样理解功能安全是让系统在故障和事故中保护人信息安全是不让黑客制造故障和事故来伤害人。这两类工程师必须背靠背而不是各管一摊。工具链共享、威胁分析互相引用、测试结果统一管理是让这两类工程师真正协作起来的基础。逛完展回到办公室我把这次听到和看到的东西整理成了一份工具链checklist静态分析选了哪些规则、单元测试覆盖率目标设到多少、故障注入脚本覆盖哪几个层次、Secure Boot的密钥策略、CI里的安全门禁阈值每一条后面都留了一栏“当前状态”和“负责人”。有同行笑我逛个展回来还要布置作业但我的体会是安全这件事只有落到这样琐碎的检查项上才算真正被推进了。工具不是银弹但如果没有工具安全就连“可重复的证据”都拿不出来。希望这篇回顾能给你正在进行的工具链规划提供一些参考也欢迎在评论里聊聊你们团队在功能安全和信息安全落地时遇到的具体问题。