一、先画出固件资产与责任边界
1.1 固件包往往包含多个独立受控对象
一个量产包可能包含主程序、引导程序、配置区、校准参数、证书、设备身份、烧录脚本和测试脚本。它们的发布人、版本、保密级别和烧录时点可能不同。采购应要求资产清单列出文件名、逻辑名称、版本、校验值、适用板号/硬件版本、加载顺序、是否可重复使用和保留期限。
客户通常负责发布经过批准的固件及适用规则，制造方负责按受控输入执行并保存规定记录；密钥由客户、制造方或第三方安全服务管理，要在项目协议中明确。若客户仅通过聊天发送附件，没有签名或校验值、批准人和生效批次，现场很难区分正式发布与临时调试文件。
1.2 按机密性、完整性和可用性分别设控制
机密性关注未授权读取和复制，完整性关注文件或配置被替换、损坏和错配，可用性关注生产或返工时能否取得正确版本。不同资产权重不同：公开固件也需要强完整性，设备私钥则同时要求严格机密性与完整性。NIST SP 800-193以保护、检测和恢复讨论平台固件韧性，采购可借此检查生产烧录是否具备相应证据。
| 资产 | 主要风险 | 客户需冻结 | 审厂证据 |
|---|---|---|---|
| 固件镜像 | 错版、篡改、损坏、未批准复制 | 版本、签名/校验、适用硬件 | 接收、批准、分发和使用日志 |
| 烧录脚本 | 地址、选项或顺序错误 | 脚本版本与判定规则 | 变更记录和工位基线 |
| 密钥/证书 | 泄露、重复、误用或生命周期失控 | 生成、交付、用途和撤销策略 | 权限、调用记录与余量对账 |
| 设备身份 | 重复、跳号、板号错配 | 编码格式、号段和重用规则 | 领用、写入、验证和报废记录 |
| 生产日志 | 缺失、可改写、无法关联实物 | 字段、保存期和交付方式 | 单板记录、权限和备份 |
二、发布与接收环节先验证来源和完整性
2.1 文件传输通道只是起点，批准链更重要
安全传输应结合发送方身份、接收人权限、文件完整性和版本批准。工厂接收后可在隔离位置核对签名或客户提供的散列值，登记时间、发布人、接收人和适用项目；验证失败或信息不完整的包不得进入量产基线。散列值如果与固件放在同一封未经验证的邮件里，只能检测传输损坏，难以证明来源。
NIST SP 800-218 SSDF强调保护软件、建立安全开发环境和保留发布来源信息。EMS不负责替客户完成软件开发安全，但采购可以要求双方接口保留版本来源、批准和变更记录。紧急修复也应使用明确的临时版本、适用批次、过期条件和后续正式归档，而不是覆盖原文件。
2.2 板号、硬件版本和固件版本要有可执行矩阵
版本矩阵至少关联板号、PCB版本、BOM/关键器件版本、固件、配置、烧录脚本、测试脚本和生效序列范围。工位应依据受控任务或扫描输入选择版本，避免操作员凭文件名判断。存在A/B分区、多MCU或先烧录后校准时，要写明顺序和依赖。
三、密钥与设备身份执行最小权限和职责分离
NIST SP 800-57提供密码密钥材料管理的一般指导，涉及保护级别、访问控制、身份鉴别、库存和生命周期等。生产项目应先决定密钥在哪里生成、是否允许导出、制造现场看到明文与否、调用次数如何授权、失败是否消耗号段、密钥轮换与撤销怎样传递。所有选择都需要客户安全架构批准。
职责分离可将固件发布、工位批准、密钥管理、生产操作和日志审查分给不同角色，避免一个账户同时能替换固件、调整判限并删除记录。服务账户、共享账户、远程支持和离职人员权限应纳入审查。最小权限也包括文件系统：普通操作员只需执行批准任务，不应浏览项目目录或复制敏感包。
设备序列号、MAC、证书或客户自定义身份要防重复和错配。号段领用、写入结果、未用余量、失败板、报废板和返工板必须对账。板卡报废不代表身份可以自动重用；是否回收或吊销由客户策略确定。
| 控制节点 | 日志字段 | 异常检查 | 退出动作 |
|---|---|---|---|
| 任务下发 | 项目、板号、固件/脚本版本、批准人 | 过期任务、错版矩阵 | 撤销任务与权限 |
| 单板烧录 | 序列、工位、时间、操作身份、结果 | 重复身份、跳号、连续失败 | 导出项目记录 |
| 密钥调用 | 用途、对象、次数、状态和错误 | 超额、未授权时段、重放 | 归还/吊销/销毁证明 |
| 返工重烧 | 原版本、原因、批准、新结果 | 绕过锁定、日志断链 | 关闭返工入口 |
| 数据保存 | 备份、校验、保留期、访问记录 | 可改写、缺段、时钟偏差 | 客户接收与本地清理 |
四、验证、锁定与返工规则要在首批前确认
4.1 “烧录成功”不等于内容和功能都正确
工位成功可能只表示通信和写入完成。项目应定义是否回读、校验签名或散列、检查安全位、读取版本、验证配置及执行功能测试。安全锁定位、调试口和读保护涉及产品架构，错误设置可能影响返修或安全，应由客户提供受控配置，制造方按批准步骤执行。
烧录失败板要物理隔离并保留失败码、尝试次数和原身份状态。是否允许擦除重烧、次数限制、哪些失败需要工程评审、返工后如何标识，都要预先写明。更换MCU、存储器或整板后，旧身份和密钥如何处置也要闭环，防止两个实体获得同一身份。
五、日志要支持单板追溯、客户审计和安全事件调查
IPC-1782提供电子产品制造供应链追溯的一般框架。固件日志可与物料批次、板号、工单、序列、测试和出货关联，但追溯深度由客户风险和合同确定。记录应使用统一时钟、受控字段和不可随意改写的存储，导出格式需在首批验证。敏感日志可能包含身份或安全信息，交付和访问同样需要权限。
审厂可联动PCBA序列号与条码追溯体系与PCBA代工保密和知识产权，并与可编程元器件来源筛查、业务连续性与备份恢复对接。山西英特丽可按客户文件评审固件输入、批次和日志字段，具体安全设施、加密方案和权限实现须逐项核实。
六、PCBA固件烧录安全常见FAQ
固件文件有版本号就足够控制量产烧录吗？
不够。还要验证发布身份与完整性，并关联板号、硬件、配置、脚本、生效批次和批准人；仅凭文件名容易错版或被覆盖。
烧录日志只保存成功和失败可以吗？
通常不足以支持审计。应按客户风险定义单板身份、工位、时间、操作身份、固件和脚本版本、校验结果、失败码、返工及密钥调用等字段。
设备私钥可以作为普通文件发给生产工位吗？
是否允许导出及如何使用应由客户安全架构决定。高敏感密钥通常需要更严格的生成、传输、访问、调用审计、轮换和销毁控制，不能照搬普通固件流程。
烧录失败后更换芯片可以沿用原设备身份吗？
要按客户身份生命周期规则处理。应记录原身份状态、失败件和批准，防止重复身份；重用、回收或吊销均需有受控依据和对账。
七、资料依据与安全输入
资料依据：
评审带固件、证书或设备身份的PCBA项目时，可提交板号版本矩阵、发布与校验方式、烧录脚本、序列策略、权限和日志字段，与山西英特丽逐项核对实施边界。
联系山西英特丽
