嵌入式安全

欧盟《网络弹性法案》（CRA）把问题从"你的产品是否安全"变成了"你能否证明这一点"。监管机构现在要看的是证据，而不是意图：是否强制执行并留存编码规范记录、漏洞是否可追溯到已知的缺陷类别、构建是否可以精确复现，以及支持承诺是否能持续多年而非仅停留在发布时的口头保证。这些证据必须来自工具链本身，因为事后是无法拼凑出来的。

在缺陷交付之前就将其拦截

大多数漏洞并非始于攻击，而是始于没人发现的缺陷。IAR 的 C-STAT 强制执行 MISRA C/C++ 和 CERT C/C++ 标准，在编译阶段就能捕获映射到 CWE（Common Weakness Enumeration，通用缺陷枚举）的缺陷，防患于未然，无论是在产品交付现场还是审计之前。C-RUN 则接续静态分析的边界，捕捉内存泄漏和运行时错误——这些正是仅靠代码评审容易遗漏的问题。

着眼长远，持续护航

及早发现缺陷，只有在产品整个生命周期内持续获得保护时才真正有意义。10 到 15 年的产品寿命，意味着即便在十年之后，仍然需要补丁与可复现构建——而这正是 IAR 长期支持（LTS）服务所提供的：将 CRA 要求的多年支持义务，落实为工程层面的实际承诺，而非一句合规声明。

IAR 的工具链已针对 IEC 61508、ISO 26262 和 IEC 62304 完成预认证，使功能安全与网络安全能够相互强化。此外，由于每一次构建都通过版本锁定、容器化的 IAR Build Tools 完成，通过测试的二进制文件正是最终交付的那一个版本，多年后仍可为续期或现场调查完全一致地重新构建。

综合来看，这些能力让 CRA 合规不再是纸面文书，而成为工具链默认具备的能力。而且这一证据链条不仅适用于 CRA，同样适用于 RED/EN 18031、IEC 62443 以及 FDA/IEC 81001-5-1。