企业官网建设流程全解析

上个月帮朋友审一份二类监护仪的510(k)申报材料，打开eSTAR一看，网络安全章节下挂着一长串待上传附件。他丢了句话过来：“这玩意儿到底要交多少文档才算完？”我数了数自己经手过的申报项目，再对照手头的审评意见记录，告诉他一个比较稳的答案：按大类算11份打底，拆到子项经常还会多出来。

这个问题不是个例。FDA从2023年10月开始对510(k)和De Novo强制使用eSTAR模板后，网络安全模块从原来的“能填就填”变成了结构化必答题。很多注册工程师第一次打开模板，光是看懂网安章节的字段提示就要耗掉半天。这篇文章我就把自己实操中摸索出来的文档清单、每种文件的写法和常见坑位一次性摊开，给正在做FDA申报的同行一个可以直接照着对账的清单。无论是二类联网设备、三类植入物还是SaMD，这个拆解思路都能用上。

1. 为什么eSTAR里的网安模块让人头疼

1.1 eSTAR不是填表，是文档装配系统

eSTAR全称是eSTAR Submission Template，表面看是一个动态PDF或在线表单，实际底层逻辑是按照设备类型、审查路径、产品特征动态生成问题清单。你选“设备有无线连接”，系统自动展开一串网络安全相关问题；你选“完全没有任何网络接口”，网安章节可能只保留最基本的三四条。所以很多人问“到底要交多少文档”，答案不是固定的，而是跟着你前面的选项走。

这个设计跟FDA 2023年9月发布的网络安全最终指南《Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions》直接对齐。eSTAR里的网安模块字段，基本就是把指南里要求的递交内容拆成了结构化提问。换句话说，你不是在“填表”，你是在回答审评员打算在受理阶段就要看到的所有网安证据。

这里有个关键认知要纠正：eSTAR的网安模块不是一个独立PDF附件，它是“正文结构化字段+附件上传”的组合体。正文里答什么直接决定附件区建议传什么。很多人第一次用，正文草草填完，发现附件区没法上传所有想传的文件，或者反过来附件一大堆但正文没提，审评员根本不知道你这堆文件是干嘛的。这两种情况都会拖慢审评节奏。

1.2 “11+附件”这个数字怎么来的

“11+附件”不是eSTAR模板里直接写出来的数字。模板本身会给出建议上传的网安附件位置，但实战中你会发现，审评员期望看到的支撑材料比模板提示的更多。我自己按FDA指南和实际审评反馈，把网安递交物归纳成四层：

• 第一层：设备网络安全属性的直接证据，包括漏洞与可利用性评估、SBOM、威胁建模、安全架构说明。
• 第二层：验证与确认证据，包括网络安全测试计划、测试报告、异常问题清单。
• 第三层：风险管理整合证据，包括网安风险分析和危害分析、风险管理报告。
• 第四层：标签与售后承诺，包括网络安全标签草稿、软件更新与维护计划、第三方组件说明和认证证书。

四层加起来，核心附件就在11类左右。如果设备带云服务、远程升级、第三方数据库连接，还会额外增加云安全说明、接口文档等子项。所以11是“起跑线”，不是“终点线”。

我在下面逐份拆，每份说清三个问题：写什么、为什么审评员要看、怎么写能少改一轮。

2. 网安模块的正文部分到底填什么

2.1 设备描述里的网安信息是总开关

eSTAR的Device Description部分是网安内容的入口，很多人以为这只是在填“设备长什么样”，实际上这是网安模块的总开关。里面有几个选项直接决定后续章节是否启用、附件是否需要上传：

• 设备是否包含有线或无线网络连接（包括以太网、Wi-Fi、蓝牙、蜂窝、NFC、Zigbee等）。
• 是否包含USB、SD卡、串口等可移动介质或物理接口。
• 是否与电子健康记录系统或外部信息系统交换数据。
• 是否支持远程访问、远程维护、远程升级。
• 是否收集、传输或存储患者健康信息。

这五个选项必须跟产品的真实设计逐一核对，不能图省事。我见过一个项目，注册负责人觉得“反正蓝牙也算无线连接”，把所有网口选项都勾上，结果后台生成了大量本不需要回答的问题，附件区多了一堆“不适用的也要解释”的字段，团队白白多写了两周文档。反过来，也有设备明明带USB配置端口，因为没勾选，到了审评阶段被补充信息要求追问，来回浪费一个多月。

这里我的习惯做法是：把设备所有对外接口列一张表，硬件接口和无线协议分开，然后拿着表去跟设计工程师、法规工程师一起核对，确认每个接口的数据流方向、是否传输PHI、是否允许第三方接入，再回头填eSTAR。这张接口表后面还能直接改造成网安架构说明里的附件，一举两得。

2.2 网络安全章节的核心字段

eSTAR网安章节的核心字段，可以看作一个“摘要式问卷”。它要求你回答设备如何保证保密性、完整性、可用性这三性，并针对不同攻击面说明控制措施。常见字段包括：

• 设备的主要网络威胁面、攻击路径和潜在攻击者模型。
• 是否采用加密、身份验证、访问控制、安全启动、代码签名、防回滚等安全控制。
• 哪些安全功能依赖医院或用户侧的网络基础设施，也就是业内常说的“网络安全控制项转移”。
• 软件更新机制的类型：自动、手动还是OTA，更新包是否有签名校验。
• 风险分析中如何考虑网络安全相关的危害。
• 设备标签与说明书中包含哪些网络安全信息。

这些字段在eSTAR里通常有提示文本，告诉你“如果要提交更多信息，请参见相关附件”。这就是正文与附件之间的衔接关系：正文是给审评员看的摘要，附件是支撑摘要的证据链。正文篇幅不需要很长，但每个字段的答案必须能在附件里找到对应的详细文档。如果正文写了“采用端到端加密”，附件测试报告里却没有加密验证的用例，这就是一致性缺口，审评员很容易挑出来。

3. 11+附件全景拆解：每一份文件怎么写

3.1 漏洞与可利用性评估，FDA最看重的一份

FDA网络安全指南里反复强调“vulnerability and exploitability assessment”，直译是漏洞与可利用性评估。审评员并不指望你的设备是零漏洞的，但只要设备运行的软件组件存在已知漏洞，你必须评估这个漏洞在具体设备环境中是否可被利用、可能造成什么影响、有没有缓解措施。

写这份文件时，我建议按漏洞条目组织：每个已知漏洞列一行，内容包括组件名称、组件版本、CVE编号、CVSS评分、漏洞描述、是否可利用、利用条件、影响分析、缓解措施。关键点不是罗列CVE，而是做“可利用性判断”。同样是CVSS 9.8的漏洞，如果这个组件只在内网维护端口上使用，物理访问才能触发，那在设备的既定使用环境下，可利用性评价和“直接暴露在互联网上的Web服务器”完全不同。你要把这个推理过程写出来，审评员才认可你不是拿CVE清单糊弄。

实操建议：先在SBOM基础上跑一遍组件漏洞扫描，常见工具包括NIST NVD、GitHub Advisory Database、商业漏洞扫描平台等。然后把扫描结果按设备实际结构筛选、分级、逐条分析。这项工作的产出质量，直接决定审评员对你们团队的信息安全能力的第一印象。

3.2 SBOM软件物料清单，粒度越细越省事

SBOM（Software Bill of Materials）是FDA网安模块里绝对不能缺的附件。指南明确鼓励提交机器可读格式的SBOM，常见的工业格式是SPDX和CycloneDX。审评员要求SBOM的目的很直接：没有完整的组件清单，漏洞评估就是空谈。

写SBOM的时候，很多人会犯一个错误：只列“顶层依赖”，比如操作系统版本、主库版本，但不开源依赖的传递依赖（传递依赖）。真实设备里，一个开源库往往引用了几十个次级库，漏洞往往藏在这些间接依赖里。所以SBOM的粒度要深到能支撑漏洞扫描，至少做到“组件名称+版本+供应商+许可证类型+用于设备的功能模块”这个层面。

如果你用的是自动构建系统，建议在CI流程里接入SBOM生成插件，构建时自动导出SPDX文件。如果产品已经量产、没有现成SBOM，那就只能手工梳理了，过程非常痛苦，我建议先从构建脚本、固件打包清单、第三方库目录入手，反查组件版本。

提示：SBOM不只是在递交时管用。产品上市后，一旦爆出新的高危漏洞，你是靠SBOM快速筛查受影响客户和评估风险的。磨刀不误砍柴工，别嫌麻烦。

3.3 网络安全威胁建模，体现你对设备的理解深度

威胁建模是FDA指南里的明确要求。eSTAR网安章节的正文问“主要威胁面是什么”，答案的详细证据就是这份威胁建模文档。

写威胁建模不用追求“方法论炫技”。我见过好几份被审评员认可的威胁建模，用的还是最经典的STRIDE模型，关键是把设备的资产、攻击面、信任边界、威胁场景和对应控制措施写透了。

一份合格威胁建模的骨架是：

• 设备和系统架构图，标注数据流方向、网络边界。
• 资产清单：固件、配置参数、患者数据、系统日志、加密密钥等。
• 攻击面枚举：无线接口、USB口、远程维护端口、云服务API、网页后台。
• 信任边界：设备内部、用户手机端、医院网络、云服务端之间的跳转点。
• 威胁场景：用“攻击者想达成什么目的，通过什么路径，利用什么漏洞”的方式描述。
• 每个威胁场景的缓解措施和验证状态。

我以前做过一个输液泵的项目，团队一开始威胁建模写得特别宽泛，什么“黑客远程控制设备”这种表述都有，但审评员追问的是“你的泵通过蓝牙和手机App通信，手机App被攻破后泵端怎么验证指令合法性”。后来我们改成逐条威胁场景对应缓解措施，测试报告按这个矩阵逐项验证，审评一次性通过。威胁建模不是写给FDA看的作文，是给整条开发线的安全设计依据。

3.4 网络安全架构与设计说明，画图不是重点，说清保护机制才是

大多数设备上市前的技术文档里已经有系统架构图，网安模块要的架构说明是在原有架构基础上叠加安全控制视图。审评员想看的是：数据明文走到哪一段、在哪一段加密；身份认证在哪个环节做；固件升级包的签名校验怎么实现；日志系统记录哪些安全事件；密钥存在哪里、如何保护。

我在实际递交时会把这份文档做成两层：先给一张“安全架构总览图”，再配一个“安全控制措施表”。架构图不用画得特别精美，但要能看出数据流和信任边界。安全控制措施表是一个二维表格，每一行是一个安全控制目标（比如“防止未经授权的配置修改”），对应措施（比如“配置界面要求管理员密码+操作审计日志”）、对应威胁建模里的威胁条目、对应测试报告里的测试用例编号。这样一份文档，等于把威胁建模、架构设计、测试验证三份材料串起来了，审评员你可以省去大量在多个附件之间来回比对的时间。

3.5 网络安全测试报告，与威胁场景逐条对应

网安测试报告是审评员重点看的一份支持性证据，内容包括漏洞扫描、渗透测试、模糊测试和缓解措施有效性验证。FDA指南不强制规定必须用某个测试等级，但要求测试计划与威胁建模对应，测试结果能证明安全控制措施有效。

写这份报告时最容易出问题的是“测试条目和威胁建模脱节”。比如威胁建模里写了“防止未授权蓝牙连接”，但测试报告里只有常规漏洞扫描结果，没有蓝牙连接尝试的测试记录，审评员一眼就能看出你没按自己的威胁模型做验证。

我的建议是三段式结构：

• 测试环境说明：被测设备软硬件版本、网络拓扑、测试工具及版本、测试时间。
• 测试计划表：每个测试项目对应威胁建模中的威胁编号、测试目的、测试方法、预期结果。
• 测试结果与结论：逐条列出实际结果、剩余风险说明和备注。

渗透测试或模糊测试这块，如果内部团队没有足够能力，可以外包给有医疗器械测试经验的第三方实验室。需要留意的是，FDA审评更关注的是结果里面有没有对设备实际运行环境的“适用性讨论”，而不是单纯堆一堆渗透测试工具的输出报告。外包报告拿回来后，一定要让熟悉设备的人补上一段“该问题在本设备使用环境下可利用性评估”，否则直接上传容易被打回。

3.6 网络安全风险评估与风险管理报告，纳入ISO 14971体系

网安风险不能独立于器械风险管理体系之外，是要嵌入ISO 14971的风险管理流程的。FDA在指南里明确说了，制造商应考虑与网络安全相关的威胁、漏洞的利用是否可能造成患者伤害或产品功能失效，并在风险管理文件中形成记录。

实际操作中，我建议把网安风险放进已有的风险管理文档中：危害分析表里增加“信息安全事件”类别，包括未授权访问、数据篡改、拒绝服务、恶意软件感染等。每个危害事件按“引发原因→网络路径→可利用性→触发条件→严重度→发生概率→风险可接受性→缓解措施”的格式描述。

这里要掌握一个度：网安风险分析不必把每个CVE都列成一条风险管理条目，那样文档会失控。正确做法是：先按威胁建模里的威胁场景做风险分析，再针对风险不可接受的场景，叠加漏洞扫描中发现的已知漏洞做具体分析。最终的风险结论落到“风险可接受”或“风险已通过缓解措施降低至可接受水平”上，并给出一句话理由。

3.7 网安标签与说明书草稿，容易被漏掉的“加分项”

FDA网络安全指南明确要求提交网络安全标签草稿，确保用户在设备发布时能获取已知网络安全风险的摘要、可用的保护措施、软件更新机制等安全信息。这不是上市后市场部门自己决定的文档，是在申报阶段就要放进eSTAR附件区的。

实操层面，我一般把用户手册里的“网络安全声明”章节草稿直接拉出来作为附件，内容包括：设备支持的软件版本和更新策略、设备使用方需要配合维护的安全设置（比如修改默认密码、关闭不用的端口）、已知风险的说明路径、漏洞报告联系方式。

这个文档容易被团队漏掉，因为很多人觉得“标签”是市场部的事，而实际上FDA把网络安全标签当作风险沟通的一部分来审。虽然没有网络安全标签不会像缺SBOM那样直接给技术缺陷的反馈，但补上它至少能给审评官留下一个“这家考虑了上市后安全沟通”的印象，对于流程推进有益无害。

3.8 软件更新与维护计划，别只写“我们会推送补丁”

FDA在指南里对上市后的漏洞响应和维护策略有明确期望。对应的递交材料就是一份软件更新与网络安全维护计划，内容通常包括：设备软件更新机制的描述（自动/手动/OTA）、更新包签名和验证机制、已知漏洞响应的SLA、用户和医院的升级通知流程、向FDA报告重大安全事件的内部流程。

很多团队把这份文档写成了“产品未来某天支持在线升级”的泛泛承诺。审评员真正想看的是：如果产品已经上市，你如何在不断变化的威胁环境中保持安全性。所以文档里至少要把“漏洞接收→风险评估→筛选受影响产品→发布修复→推送更新”这条流程说清楚，并指出由哪个角色负责哪个环节。

如果你目前的设计根本不支持OTA升级，那就如实写“硬件手动更新流程”，同时说明更新发布后如何通知用户执行操作。坦白说，没有OTA是减分项，但写不清楚更新流程比没有OTA更要命，因为FDA会更担心你连更新都无法组织。

3.9 未解决异常问题清单，建立独立的网安缺陷列表

FDA软件递交中一直要求提交“未解决异常问题清单”，网安相关的缺陷也要单独列出来。做法上我建议不要在通用软件bug清单里附带，而是单独创建一份网络安全异常清单，逐条记录：缺陷描述、影响组件、是否有已知攻击路径或PoC、临时缓解措施、是否计划修复、修复版本和计划时间、风险评估结论。

这其中的关键是：未修复的网安漏洞不等于“交不了申请”，只要你对风险进行了分析，并在说明书/维护计划里有针对性的缓解措施或用户警示，通常是可以被接受的。审评员怕的不是“有漏洞”，而是“有漏洞却不评估，或者评估了却没有结论”。

3.10 第三方组件与已知漏洞说明，避免审评追问时卡壳

如果你的设备用了第三方通信模块、操作系统、开源库或云服务SDK，建议单独准备一份第三方组件与已知漏洞说明。表面上这份文档和SBOM内容有重叠，但定位完全不同：SBOM是清单式证据，这份说明是“分析式总结”。

它要把第三方组件里最关键的已知漏洞挑出来，结合设备的实际使用场景逐一分析是否可被利用。比如一个开源HTTPS库有中间人攻击风险，但设备只在局域网内定期连接医院服务器且启用了证书锁定，那这个风险的利用难度就大幅上升。把这种判断写出来，既能体现你深入评估过，也能提前堵住审评过程中可能出现的“补材料”式追问。

3.11 云服务、接口说明和第三方认证，按需增加的扩展附件

如果设备涉及云平台，比如App数据上传到云端、医生网页端查看数据，需要增加云服务安全说明，内容包括云服务商信息、数据传输链路加密、密钥管理、账户权限模型、云端日志与审计机制、数据保留策略。如果设备对接医院HIS或EHR系统，需要增加接口安全说明：接口协议、数据格式、认证方式、审计跟踪。

有些产品会提供UL 2900-2-1等第三方网络安全认证证书，以及IEC 62443、ISO 27001等体系认证声明。这类认证证书可以作为支持性附件传上去，但要注意，认证证书不是免责牌，FDA不会因为你拿了UL证书就免除对具体设备的威胁建模和漏洞评估。我认为认证更多是给审评员增加信心，核心的网安文档一样都不能少。

3.12 附件的命名、交叉引用与打包细节

eSTAR每个附件在模板里都有对应的上传位置，有些还绑定了特定字段。附件命名建议采用“编号-文档名称-版本号-日期”的格式，例如“11-SBOM-1.2-20250215.spdx”。命名清晰可以方便审评员在eSTAR的附件列表里一眼定位。

另外强烈建议在正文或附件第一页加一份“网络安全附件交叉引用矩阵”，列明每份附件对应正文哪个章节、与威胁建模哪条威胁对应、与测试报告哪个用例对应。审评员每天看大量申报材料，一份清晰的索引能明显降低他的审阅时间，也侧面反映你自己做过系统性自查。

4. 实操经验：如何高效完成网安模块

4.1 团队配置别让注册工程师单打独斗

网安模块的文档产出不能只靠注册工程师一个人扛。我见过很多中小型企业的现状是：注册工程师既不懂渗透测试，又不了解密码学，却被要求写网安文档。这个模式迟早要出问题。合理的团队配置建议是：

• 系统架构师或软件负责人：输出架构图、接口表和SBOM。
• 信息安全工程师：主导威胁建模、漏洞可利用性分析、测试结果评估。
• 测试工程师：执行或配合执行网安测试，输出测试记录。
• 法规注册工程师：把前面的材料翻译成FDA审评语言，塞进eSTAR对应位置。

如果公司没有专职的信息安全工程师，最常见的选择是找外部顾问做威胁建模和渗透测试，内部团队负责整理设备信息和SBOM，然后由注册工程师整合。这个组合能兼顾效率和专业性。

实际推进时，我的方法是先定设备边界，再倒排时间线。第一周先列接口表和组件清单，第二周做威胁建模和SBOM，第三周启动漏洞扫描与测试，第四周写报告和风险分析。如果没有提前规划，等项目准备送检才想起网安文档，往往要额外付出四到六周的补救时间。

4.2 常见退审原因：一致性缺口最多

综合我接触到的FDA审评反馈，网安模块最常见的退审或补充信息原因并不是“文档数量不够”，而是“文档之间的逻辑对不上”。典型问题包括：

• SBOM里列了某个组件版本，漏洞评估里分析的却是另一个版本。
• 正文勾了“设备支持蓝牙”，架构说明与网安测试里却完全没提蓝牙接口。
• 威胁建模识别出五个关键威胁，测试报告只覆盖其中三个。
• 标签草稿没写软件版本和更新机制，与维护计划回答不一致。
• “网络安全不适用”的判断错误，导致整个网安章节空白，审评员直接要求补充。

每次提交前，我都会做一轮“一致性自检”：把正文答案、威胁矩阵、SBOM、漏洞评估、测试用例放到一张大表里，逐条核对编号是否互相对得上。这步很费时间，却能在正式提交前拦住大部分明显问题。

4.3 用好eSTAR自校验和Pre-Submission

eSTAR自带了Validation功能，提交前必须跑一遍。它不能帮你检查内容质量，但能查漏字段、缺附件等格式问题。我见过不少团队把材料交上去，因为某个必填字段没填被退回来，这种低级错误完全可以通过自校验提前规避。

如果对网安文档要求不笃定，尤其是新产品类型或新功能定义比较特殊的情况，建议先走Pre-Submission（Q-Submit）跟FDA做一次沟通。你可以在正式提交前把文档框架和疑问点提交给FDA，他们会在规定时间内书面反馈哪些内容还需要补充。这个流程会拖一两个月，但比起正式交上去后再等补充信息通知，成本可能更低。对于涉及复杂云架构或AI类功能的设备，Q-Submit尤其值得考虑。

5. 工作量与投入：网安模块到底占多大精力

5.1 不同产品类型的工作量差异

网安模块的文档数量和工作量取决于设备本身的网络暴露面。我根据经验给一个相对粗放的分级，便于你做时间评估：

这个表格不是绝对的，仅供参考。实际工作量还取决于公司已有文档体系是否完善，比如如果ISO 14971风险管理文档原本就维护得很好，网安风险分析可以直接在此基础上增量补充，能省不少时间。

5.2 成本与外包判断

网安测试外包成本通常是很多中小型企业纠结的问题。一般来说，渗透测试加漏洞扫描一次的费用跟测试范围成正比，设备接口越复杂越贵。带Wi-Fi和云端功能的设备，会比单纯USB端口的设备高一个档次。如果再加模糊测试，整体预算会明显上升。

要不要外包？我的判断标准是：内部没有人写过医疗器械的威胁建模或渗透测试报告，就不要硬磨。网安测试本身是熟练活，有经验的团队半天就能找到关键问题，没经验的人折腾两周可能还在测试方案里打转。外包时记得合同里明确交付物需要“结合设备使用环境的可利用性评估”，拿到报告后别原封不动上传，一定要让熟悉产品的人补充适用性分析。

文档统筹部分可以内部消化，注册工程师只要把各来源材料整合到eSTAR框架里。这样组合出来的成本，多数二三类设备项目是能接受的。

做网安模块我最大的体会是：它检验的不是“你会不会填表”，而是“你对自己产品的网络安全边界想清楚没有”。文档数量不是目的，一致性才是。你在eSTAR里每写一句结论，都要能在附件里找到对应的证据；每个证据，都要能追溯到设备真实的设计和测试记录。这套思路理清了，11份还是15份附件都不难，毕竟材料只是思维过程的载体。

最后再分享一个实用的习惯：拿到eSTAR模板的第一天，就把网安章节的字段和附件提示截图归档，做成一份团队内部的“网安文档状态追踪表”，每周更新一次。这个表在我手上撑过了三个项目，每次提交前对照自检，帮我们少改了好几轮。你也值得有一份。