作者：译安 ｜ 思倍信息科技旗下医疗器械出海合规顾问
一句话结论：网络安全章节不是"写"出来的，而是把研发里真实发生的安全工作，翻译成 FDA 能追溯的证据链——审评员看的不是你的文笔，是每一条安全措施能不能从需求一路追到测试报告。写不齐、追不上，就会收到发补（Additional Information），上市时间被拖后。
先记住一个反直觉的事实：审评员并不关心你的"网络安全报告"写得多漂亮，他只关心"你声称做的，是不是真的做了、能不能证明"。
一、先破除一个误区：网络安全章节 ≠ 一份"网络安全报告"
很多团队的做法是：快截止了，找份模板，把"加密、认证、防火墙"这些词往里一填，凑成一份"网络安全报告"交上去。
结果几乎必然是发补。原因很简单：FDA 审的是证据链，不是文档厚度。你写"设备采用加密传输"，审评员会顺着往下追——这条要求写在哪个设计输入文件里？加密用什么算法、怎么实现？测试报告里哪一条验证了它？哪一环断了，整段就被打回。
所以正确的思路是：别把网络安全章节当作文档来写，当成"把研发证据归档"来做。
二、到底要交哪几类证据
下面是 FDA 上市前审查实际会看、也最常被打回缺口的几类证据。注意这是便于你准备的整理方式，具体以 FDA 现行指南和 eSTAR 要求为准——其中 SBOM 对「cyber device」（含软件、能够连接互联网、存在被网络安全威胁利用可能性的器械）是法定要求，须覆盖商业、开源及现成软件组件（缺失会在 eSTAR 验证或 RTA 审查中被拦下），其余是审评实际看重、缺了大概率吃缺陷信的证据。
| # | 证据 | 写什么 | 审评员实际看什么 |
|---|
| ① | 威胁模型 | 系统分解（数据流图 + 信任边界 + 资产）、威胁枚举、缓解措施映射 | 是不是针对你设备的实际架构，而不是套模板 |
| ② | 安全风险管理报告 | 资产/威胁/漏洞/可利用性评估/残余风险 | 用"可利用性"评估，且与 ISO 14971 危害分析有可追溯链接 |
| ③ | SBOM（+VEX） | 全部软件组件清单（机器可读） | 是否覆盖传递依赖、OS、固件、AI 模型；是否有更新机制 |
| ④ | 渗透测试报告 | 测试范围、方法、发现、修复状态 | 范围是否与架构视图逐接口一致，方法是否多样 |
| ⑤ | 漏洞与事件管理计划 | 监控源、评估节奏、阈值、通知路径 | 是"运行中的机制"，不是一句"我们会监控" |
| ⑥ | 安全架构视图 | 认证/授权/加密/完整性/日志/更新机制 | 每项控制是否映射到它要缓解的威胁 |
三、写作的五条铁律（决定过不过，不是文笔）
1. 每条证据都要能追溯到质量体系。
2026 版指南把引用框架对齐到 QMSR（ISO 13485）。审评员会往 ISO 13485 的设计输入（7.3.3）/设计输出（7.3.4）/设计评审（7.3.5）/设计验证（7.3.6）/设计确认（7.3.7）去追。写每一条都问自己：它的源头文件和证据文件在哪？
2. 威胁模型必须具体到架构，不能模板化。
"通过加密和认证缓解风险"这种泛泛之谈是最高频缺陷。用 STRIDE 或攻击树，把威胁落到数据流、接口、组件上。
3. 渗透测试范围 = 架构视图，逐接口对得上。
只跑现成工具或范围对不上架构图是另一个高频缺陷。方法覆盖静态分析、动态分析、模糊测试、鲁棒性测试。
4. SBOM 要完整，还要有"管理机制"。
漏了传递依赖/OS/固件/AI 模型会被认定不合规；交了静态快照说不清更新机制同样过不了。SBOM 用机器可读格式（行业通行做法为 CycloneDX 或 SPDX，指南未强制指定格式与版本）。
5. 安全风险文件"独立成册，但显式映射"到 ISO 14971。
安全风险管理（建议对齐 AAMI SW96:2023 框架）与安全风险管理（ISO 14971）方法不同——前者用"可利用性"、后者用"发生概率"，两者不能混，但必须有可追溯的链接。完全割裂反而是高频缺陷触发点。
四、分步模板（可直接套用的目录）
系统与安全架构描述：设备功能概述、系统分解图、数据流图（DFD）、信任边界、所有接口清单（无线、有线、USB、云、App、调试口等）。
威胁建模：方法（STRIDE / 攻击树 / MITRE）；威胁清单每条 = 资产 + 攻击面 + 攻击路径 + 对应缓解措施。
安全风险管理：安全风险文件（建议对齐 AAMI SW96:2023 框架）；与 ISO 14971 危害分析的交叉引用表。
安全控制（架构视图）：认证、授权、加密、完整性、机密性、审计日志、安全更新机制、降级与弹性；每项控制映射到威胁。
SBOM + VEX：机器可读 SBOM（覆盖全部组件）；VEX 说明高危/严重 CVE 在本设备配置下是否可利用。
安全测试与验证：渗透测试报告、静态/动态/模糊/鲁棒性测试报告；每条测试追溯到控制与威胁。
漏洞与事件管理（上市后）：监控源、评估节奏、分诊阈值、补丁部署、协调漏洞披露（CVD）、用户通知路径。
提示：这个目录是"把证据归位"的框架，顺序可微调，但每一节都要能回答"审评员会追的那条证据链"。
五、FAQ
Q：这个章节要写多长、多细？
长度不重要，可追溯性才重要。宁可每项控制只写三行、证据链齐全，也不要写二十页却每条追不下去。
Q：能直接用模板吗？
模板帮你"不遗漏"，但救不了"不真实"。把模板当 checklist，把真实架构和真实测试结果填进去。
Q：VEX 到底要不要写？
SBOM 对 cyber device 是法定要求，缺失会在 eSTAR 验证或 RTA 审查中被拦下；VEX 非法定必备，但强烈建议提供。
Q：写好之后怎么自查？
让非本项目的人逐节问："这条措施，源头文件和证据文件各在哪？"答不上来的，就是审评员一定会追的地方。
合规提示：本文为通用信息梳理，不构成对任何具体申请的审评结果承诺；具体材料要求以 FDA 现行指南、Section 524B 及 eSTAR 提交要求为准。
