2. 安全审计框架：NIST SP 800-161、ISO 28000、SAFECode 等标准解读
做供应链安全审计，最怕什么？
怕没有章法。你拿着一份清单去查供应商，对方反问一句「你们按什么标准审？」，你就得能说出个一二三来。
我个人习惯，先搭框架，再填细节。今天聊的三个标准——NIST SP 800-161、ISO 28000、SAFECode——就是目前业界最主流的三个框架。它们侧重点不同，但组合起来，基本能覆盖 80% 的审计场景。
2.1 三个标准，各自管什么
先看一张对比图，心里有个底。
一句话总结：NIST 管「信息安全」，ISO 28000 管「物理与流程安全」，SAFECode 管「软件开发安全」。别搞混。
| 标准 | 发布机构 | 核心关注点 | 适用场景 |
|---|---|---|---|
| NIST SP 800-161 | 美国国家标准与技术研究院 | 供应链信息安全管理、风险缓解 | ICT 供应链、政府/军工项目 |
| ISO 28000 | 国际标准化组织 | 供应链安全管理体系（物理、流程） | 物流、制造、仓储、运输 |
| SAFECode | SAFECode 组织（行业联盟） | 软件开发生命周期安全实践 | 软件供应商、SaaS 服务商 |
嗯，这里要注意：这三个标准不是互斥的。我在项目中遇到过一家硬件代工厂，既要审它的信息安全（NIST），又要看它的物料流转流程（ISO 28000），还得评估它给客户做的固件开发（SAFECode）。三个框架一起上，才把风险兜住。
2.2 NIST SP 800-161：信息安全的「硬骨头」
这个标准全称很长，叫《供应链风险管理实践指南》。说白了，它教你如何识别、评估和应对供应链中的信息安全风险。
我个人觉得，它最实用的部分是那套 风险缓解控制清单。你想想看，供应商的服务器有没有被入侵？他们的员工能不能接触到你的源码？这些事你不可能天天盯着，但 NIST 给了你一套「问什么、查什么」的框架。
核心控制域（我常审的几项）
- 访问控制：供应商是否对敏感系统做了最小权限管理？
- 供应链威胁情报：他们有没有渠道获取最新的漏洞信息？
- 组件溯源：关键元器件能不能追溯到原厂？
- 安全事件响应：出了事，他们多久能通知你？
我的经验：审 NIST 时，别只看文档。我曾经让一家供应商提供他们过去 6 个月的访问日志，结果发现三个离职员工的账号还在活跃。这就是典型的「制度写了，没执行」。
2.3 ISO 28000：物理世界的「守门员」
ISO 28000 是供应链安全管理体系的标准。它不像 NIST 那样盯着数据，而是关注 人、货、场 的安全。
举个例子。你委托一家物流公司运输一批芯片。ISO 28000 会要求你审：仓库有没有门禁？运输车辆有没有 GPS 追踪？装卸过程有没有监控？这些看起来是「体力活」，但芯片被调包、被掉包的事，我见过不止一次。
审计要点清单（我常用的）
- 物理安全：围墙、监控、入侵检测系统是否到位？
- 人员安全：关键岗位员工有没有背景调查？
- 流程安全：货物交接有没有双人复核机制？
- 应急响应：遇到自然灾害或罢工，有没有备选方案？
避坑指南：我曾经审过一家仓库，ISO 28000 证书挂得漂漂亮亮，但实际去现场一看，监控摄像头有一半是坏的。证书只能证明「体系存在」，不能证明「体系有效」。一定要做现场验证。
2.4 SAFECode：软件安全的「手术刀」
SAFECode 是专门针对软件供应链的。它由微软、Adobe、EMC 等公司联合发起，核心是一套 安全开发生命周期（SDL） 的最佳实践。
你想想看，如果你的供应商用的是外包团队写的代码，你怎么保证那代码没有后门？SAFECode 给了你一套「从需求到发布」的审计点。
SAFECode 核心实践
| 阶段 | 审计要点 |
|---|---|
| 需求阶段 | 是否做了威胁建模？安全需求是否写入文档？ |
| 设计阶段 | 架构评审是否包含安全专家？ |
| 开发阶段 | 是否使用静态分析工具？第三方库有没有做漏洞扫描？ |
| 测试阶段 | 有没有做渗透测试？模糊测试覆盖了多少？ |
| 发布阶段 | 代码签名是否强制？发布包有没有完整性校验？ |
关键点：SAFECode 特别强调「第三方组件管理」。我见过太多供应商，自己代码写得不错，但引了一个有已知漏洞的开源库，整个系统就垮了。审 SAFECode 时，一定要看他们的 软件物料清单（SBOM）。
2.5 三个框架如何组合使用
讲到这里，你可能会问：我到底该用哪个？
我的建议是：按角色选框架。
- 如果你是 ICT 设备采购方，优先用 NIST SP 800-161，重点审信息安全。
- 如果你是 物流/制造企业，ISO 28000 是基础，先搭管理体系。
- 如果你是 软件采购方或 SaaS 客户，SAFECode 更对口，直接审开发流程。
当然，大企业往往三个都要。我参与过一个汽车供应链项目，Tier 1 供应商同时要过 NIST 和 ISO 28000，因为既涉及车机软件，又涉及零部件物流。这时候，我会把三个框架的控制项拆开，合并成一份统一的审计清单，避免重复劳动。
2.6 一张图看懂审计框架关系
下面这张图，是我自己画的标准关系图。你可以把它贴在审计团队的墙上。
2.7 我的审计清单模板（三个标准合并版）
最后，分享一个我实际用过的合并清单。每次去供应商现场，我就拿这张表逐项打勾。
| 审计项 | 对应标准 | 检查方法 |
|---|---|---|
| 供应商是否建立信息安全管理制度？ | NIST | 查阅制度文件，访谈安全负责人 |
| 关键元器件是否有溯源记录？ | NIST | 抽查 5 个批次，核对采购记录 |
| 仓库是否有 7×24 小时监控？ | ISO 28000 | 现场查看，回放 24 小时录像 |
| 员工入职是否做背景调查？ | ISO 28000 | 抽查近 3 个月入职档案 |
| 软件开发是否做威胁建模？ | SAFECode | 查看最近两个项目的威胁建模文档 |
| 是否维护软件物料清单（SBOM）？ | SAFECode | 要求提供最新版本的 SBOM |
嗯，这张表不是万能的，但能帮你快速建立审计的「骨架」。剩下的「血肉」，得靠你在现场一点点填。