摘要CRA要求产品“secure by design and by default”。FHI发布的CRA合规产品开发实用模式指南提出了四个工程实践领域让安全开发对工程师可操作、评估完整解决方案、维护清晰的软硬件BOM、将威胁建模作为风险评估的核心。本文从工程实践角度分析CRA合规的落地路径。一、让安全开发对工程师可操作CRA期望产品“secure by design and by default”但在实践中这只有在开发者知道这在日常工作中意味着什么时才有效。FHI的建议是定义一组小型、一致的安全开发实践适用于所有产品无论其分类如何并使这些实践易于查找和使用。关键在于将指南嵌入工程工作流而不是停留在政策文档中。培训和工具是关键。将检查集成到IDE、流水线和模板中使遵循正确的实践变得更加容易。工程含义。安全开发不是额外的“安全功能”而是日常开发流程的一部分。输入校验、最小权限、安全默认——这些习惯需要融入每个工程师的日常工作而不是作为发布前的检查项。二、评估完整解决方案虽然CRA似乎关注的是交易性产品但在现实中许多组织交付的是由多个组件组成的集成解决方案。从风险的角度来看最终解决方案才是重要的。这意味着需要理解组件如何交互以及它们组合时会出现什么风险尤其是在工程到订单ETO场景中。当客户要求偏离参考架构时进行“偏离风险评估”是好的做法。CRA还要求产品默认安全因此如果客户要求进行削弱安全的更改该风险应被明确记录并达成一致。工程含义。嵌入式系统的安全评估不能只关注单个组件。RTOS、协议栈、第三方库和硬件组件的交互风险需要在系统层面评估。偏离参考架构的定制化需求需要记录安全影响并获得客户确认。三、维护清晰的软硬件BOMCRA强调在产品生命周期内处理漏洞而不仅仅是发布前。这包括识别组件、监控漏洞和提供及时修复。在实践中这意味着需要清晰地了解产品内部的内容包括第三方软件和硬件。维护软件物料清单SBOM以及相关的硬件BOM使这一过程更加可管理。它允许跟踪新披露的漏洞并快速评估其影响。工程含义。SBOM不是一次性文档而是需要持续维护的活文档。每次固件更新、每次组件升级SBOM都要同步更新。对于嵌入式系统SBOM需要覆盖RTOS、协议栈、第三方库和芯片厂商SDK。四、威胁建模作为风险评估的核心一份有据可查的网络安全风险评估是CRA合规的核心。它应该描述产品的使用方式、需要保护的资产以及在预期环境中相关的风险。在实践中这通常采取威胁建模的形式结合安全控制、数据流和信任边界的架构文档。这不是一次性的。风险评估需要随时间维护并定期更新或在出现新漏洞或变更时更新。它也成为合规评估或事件发生后的重要证据。工程含义。威胁建模不是安全团队的专属工作。嵌入式工程师对产品的技术细节有深入了解通常可以很好地完成威胁建模。理解产品的攻击面、数据流和信任边界是威胁建模的基础。五、对嵌入式工程师的影响第一安全实践融入日常工作。CRA合规不是发布前的检查项。嵌入式工程师需要将安全实践融入日常开发流程。第二系统级安全评估。安全评估不能只关注单个组件。嵌入式工程师需要理解组件交互的风险以及偏离参考架构的安全影响。第三SBOM的持续维护。SBOM需要与产品版本形成可追溯关系。嵌入式工程师需要理解SBOM的生成和维护方法。第四威胁建模的参与。威胁建模是风险评估的核心。嵌入式工程师需要参与威胁建模识别产品中的资产、威胁和攻击面。六、总结CRA“Secure-by-Design”工程模式的核心是四个实践领域让安全开发对工程师可操作、评估完整解决方案、维护清晰的软硬件BOM、将威胁建模作为风险评估的核心。对于嵌入式工程师而言CRA合规意味着安全从“发布前检查”变成“日常习惯”。从输入校验开始逐步掌握SBOM维护和威胁建模是在CRA合规窗口期建立工程能力的有效路径。