FDA 2026医疗器械网络安全指南中，Cybersecurity Testing的定位非常明确：
测试不是为了单独证明“产品没有漏洞”，而是为了证明Security Requirements和Security Controls真正有效
FDA明确指出，普通Software Verification & Validation并不足以完全覆盖Cybersecurity，因为Security Controls需要在实际Security Context下进行额外验证。FDA同时建议将Security Testing Documentation以及相关Report / Assessment纳入Premarket Submission。
因此，对于一个FDA项目来说，正确的问题不是：
“我们是不是做一个渗透测试就可以？”
而应该是：
“基于Threat Model、Cybersecurity Risk和Security Architecture，我们到底需要哪些测试来证明风险控制有效？”
01
「FDA网络安全测试的起点
不是Penetration Test 」
FDA Cybersecurity Testing Does
Not Start with Penetration Testing
很多企业做FDA Cybersecurity时，第一反应就是：找实验室 → 做渗透测试 → 出一份Report
但FDA 2026 Guidance的逻辑并不是这样，真正的测试链应该从前面的设计活动开始：
1
Threat Modeling
2
Cybersecurity Risk Assessment
3
Security Requirements
4
Security Controls
5
Security Architecture
6
Cybersecurity Test Strategy
也就是说：
先知道要保护什么、风险在哪里、设计了什么控制，再决定怎么测试。
FDA明确要求制造商提供证据证明每项Security Design Input已经成功实施，同时应根据Threat Model证明Risk Controls有效，包括Global System、Multi-Patient Harm、Updateability / Patchability以及Security Use Case Views中识别出的控制。
02
「第一类：Security
Requirements Testing 」
Category 1: Security Requirements Testing
这是所有Cybersecurity Testing中最基础的一层，如果产品已经定义了：
Authentication
Authorization
Logging
Encryption
Backup / Recovery
Secure Update
Session Management
那么首先要验证：
这些Security Requirements是否真正被实现。
例如Requirement：Only authenticated users shall access administrator functions.
那么测试至少应该证明：
正确Credential可以登录
错误Credential无法登录
未认证用户不能绕过Access Control
Session过期后不能继续操作
Repeated Failed Login是否按设计处理
所以Security Requirements Testing本质上是在建立：Security Requirement → Test Case → Result的Traceability，它更接近传统Design Verification，但对象变成了Cybersecurity Design Input。
03
「第二类：Threat Mitigation Testing 」
Category 2: Threat Mitigation Testing
Security Requirement Testing证明：
“功能按照要求实现了。”
Threat Mitigation Testing进一步证明：
“这个设计真的能够抵抗Threat Model里的攻击场景。”
例如Threat Model识别：
Unauthorized firmware installation
对应控制可能包括：
Digital Signature
Secure Boot
Version Verification
Rollback Protection
那么测试就不能只确认：
“设备存在Software Update按钮。”
而应该实际验证：
Unsigned Firmware能否安装
Modified Firmware能否安装
错误Signature能否通过
旧版本是否可以Unauthorized Rollback
Update中断以后设备进入什么状态
FDA要求Testing能够证明根据Threat Model建立的Risk Control Measures是有效的。
所以：
Threat Model实际上应该成为实验室测试范围的重要输入。
04
「Known Vulnerability Scanning：
先找“已经知道的问题” 」
Known Vulnerability Scanning: First,
Identify the “Known Issues”
Known Vulnerability Testing主要解决：
产品里有没有已经公开的已知漏洞？
它通常会结合：
SBOM
Operating System
Third-party Libraries
Open Source Components
Network Services
Software Version
去识别：
CVE
Known Vulnerability
其他公开Security Issue
FDA 2026 Guidance明确将Closed-box Known Vulnerability Scanning列入建议考虑的Cybersecurity Testing内容。
这类测试特别适合发现：
过时OpenSSL
存在公开CVE的Operating System
旧版本Web Server
已知漏洞Library
不安全Protocol或Service
但要注意：
Scanner找到CVE ≠ 产品一定存在不可接受风险。
仍然需要回到产品级：
Exploitability
Risk Control
Applicability Assessment
Security / Safety Impact
05
「Software Composition Analysis：
从Binary进一步看软件组成 」
Software Composition Analysis: Look Beyond
the Binary at Its Software Components
Software Composition Analysis，简称：SCA
主要用于识别产品软件中使用了哪些：
Third-party Components
Open Source Libraries
Dependencies
可能对应的Known Vulnerabilities
FDA 2026 Guidance将Software Composition Analysis of Binary Executable Files明确列入建议考虑的分析方式。
SCA与SBOM之间关系非常紧密，理想逻辑应该是：
Declared SBOM
SCA Result
确认Software Component和Version
CVE Matching
Risk Assessment
因此，SCA不仅是“找漏洞”，它还可以帮助企业核对：
实际产品Binary中的软件组成，是否与SBOM一致。
06
「Fuzz Testing：专门挑战输入处理能力 」
Fuzz Testing: Specifically Challenge
Input Handling Capabilities
FDA 2026 Guidance明确列出了：
Malformed / Unexpected Inputs
Robustness
Fuzz Testing
Fuzz的核心不是攻击某一个已知CVE，而是向Interface持续发送异常、随机、边界或者畸形输入，看产品会不会出现未知问题，例如：
Malformed Network Packet
异常Bluetooth Data
超长字符串
异常File Format
错误Protocol Field
Boundary Value
Unexpected Command Sequence
希望发现：
Crash
Memory Corruption
DoS
Unexpected State
Input Validation缺陷
Remote Code Execution
ANSI/CAN/UL 2900-2-1也将Malformed Input Testing作为独立测试类型，并指出其在行业中也称为Fuzz Testing，因此Fuzz特别适合的产品：
通信接口较多
Protocol复杂
大量External Input
使用C/C++等 Memory-sensitive
Implementation
07
「Static Code Analysis：
代码还没跑，就先找Weakness 」
Static Code Analysis: Find Weaknesses
Before the Code Even Runs
Static Code Analysis主要是在：
不实际运行程序的情况下分析Source Code。
它通常用于识别：
Null Pointer
Use-after-free
Injection
Race Condition
其他CWE
Buffer Overflow风险
Unsafe Function
Hardcoded Credential
Insecure Cryptography
Memory Safety问题
FDA 2026 Guidance明确建议考虑：
Static and Dynamic Code Analysis
并特别点名检查：
Hardcoded
Default
Easily Guessed
Easily Compromised Credentials
所以对于有Source Code控制权的制造商，Static Analysis非常适合在开发早期使用。
它的优势是：
问题越早发现，修改成本越低。
这也符合FDA强调Cybersecurity Testing贯穿SPDF的逻辑。
08
「Dynamic Analysis：
看软件真正运行时会发生什么 」
Dynamic Analysis: See What Really
Happens When the Software Runs
Dynamic Analysis与Static Analysis不同。
它是在程序实际运行的情况下分析：
Memory
Network
Process
Privilege
Runtime Behavior
Input Handling
它可能发现Static Analysis难以识别的问题，例如：
Runtime Configuration错误
Session问题
Real-time Data Handling问题
异常Resource Consumption
Runtime Injection
Privilege相关行为
因此：Static Analysis和Dynamic Analysis并不是互相替代。
更合理的是：
从不同角度验证同一Software Security Posture。
09
「Attack Surface Analysis：
先确认攻击者能碰到哪里 」
Attack Surface Analysis: First, Identify
Where an Attacker Can Reach
Attack Surface Analysis回答的是：
攻击者到底可以从哪些地方与产品发生交互？
例如：
Wi-Fi
Ethernet
USB
7
Serial
9
JTAG
11
Cloud API
Bluetooth
Web Interface
Remote Service
8
Update Interface
10
Mobile App
分析以后进一步确认：
哪些Interface是Intended
哪些是Unused
哪些需要Authentication
哪些存在External Input
哪些可以访问Critical Function
FDA把Attack Surface Analysis单独列入Cybersecurity Testing / Analysis建议。
它尤其重要的一点是：
测试范围必须覆盖真正的Attack Surface，而不是只测试实验室方便连接的几个端口。
否则即使Penetration Test“Pass”，测试范围本身也可能不完整。
「Vulnerability Chaining：
单个小问题组合起来可能变成大问题 」
Vulnerability Chaining: Small Issues
Can Combine into a Major Risk
这是FDA 2026 Guidance中特别值得注意的一项：
Vulnerability Chaining
一个单独的Finding可能Risk很低，例如：
信息泄露一个Device Identifier
某个接口可以枚举User
某个Local Function权限控制较弱
单独看都不严重，但如果：
Finding A → Finding B → Finding C
可以组合成：
Unauthorized Access → Privilege Escalation → Critical Function Modification
那么整个风险可能完全不同，因此FDA把Vulnerability Chaining明确列入建议考虑的Testing / Analysis。
这也是为什么单纯使用自动Scanner往往不够，因为工具擅长发现：“一个点有什么问题。
而真正的Security Assessment还需要判断：
“多个点串起来会发生什么。”
「Penetration Testing：
不是所有网络安全测试的代名词 」
Penetration Testing: Not a Synonym
for All Cybersecurity Testing
Penetration Testing当然非常重要，但它只是整个FDA Cybersecurity V&V中的一个部分。
FDA对Penetration Testing的定位是：
通过主动发现并尝试利用Security Vulnerabilities，识别和Characterize产品中的Security-related Issues。
它比较适合回答：
攻击者能否绕过Authentication？
能否Privilege Escalation？
能否读取Sensitive Data？
能否修改Critical Parameters？
能否利用某个Network Service？
能否通过多个Vulnerability
完成Attack Chain？
所以Penetration Test更接近：
模拟真实攻击者验证整个Security Design。
而不是简单的自动漏洞扫描。
12
「FDA对Penetration Test
Report有什么要求？」
What Does FDA Require in a Penetration Test Report?
FDA 2026 Guidance写得非常具体，Penetration Test Report应包括：
Independence and Technical
Expertise of Testers
Scope of Testing
Duration of Testing
Testing Methods
Results
Findings
Observations
因此一份报告如果只有：
Testing completed. No critical vulnerabilities identified.
显然不足以完整呈现FDA希望看到的信息。
FDA Reviewer还需要理解：
谁测的？
测了什么？
为什么这样测？
测试多长时间？
使用什么方法？
发现了什么？
13
「FDA是不是强制要求第三方实验室测试？」
Does FDA Require Testing by a Third-Party Laboratory?
FDA的表述需要准确理解。
FDA要求报告说明：
Testing由谁完成
Internal还是External
Tester与Device Developer之间的Independence程度
FDA进一步指出：
在某些情况下，可能需要第三方测试，以确保测试人员与产品开发团队之间具有适当独立性
因此不能简单宣传成：
“FDA强制所有医疗器械必须做第三方渗透测试。”
更准确的表达应该是：
FDA重视Tester的独立性和Technical Expertise；对于部分项目，Third-party Testing能够更好地证明适当的独立性。
如果采用第三方Test Report，FDA还建议提交：
Original Third-party Report
14
「测试发现漏洞以后，不能只写“Fixed”」
After Finding a Vulnerability,
You Can’t Just Write “Fixed”
这是FDA网络安全测试中非常重要的一点。
FDA明确要求：对于所有Testing Findings，制造商应提供自己的Assessment。
如果某个Finding没有整改，或者计划Deferred到Future Release，也需要给出Rationale。
完整的Finding处理应该是：
Finding
Security Impact
Safety Impact
Remediation / Risk Control
Retest
Residual Risk
所以实验室发现的问题必须重新进入Cybersecurity Risk Management
而不是仅仅留在Test Report。
15
「如果漏洞暂时不修，FDA要看什么？」
If a Vulnerability Remains Unfixed,
What Does FDA Look For?
有些Finding可能经过Risk Assessment以后决定暂时接受，下一Software Release再处理。
FDA并没有说所有Finding必须在Submission前全部清零，但是对于Deferred Remediation，FDA明确建议Premarket Submission说明：
未来将解决哪些Vulnerabilities
预计Software Release Timeline
期间已经上市的Device是否能够获得Update
Update需要多久才能到达Fielded Devices
因此：
Accept / Defer本身可以是风险决策，但必须有充分的Risk Rationale和后续Plan。
不能只是：
“Low risk, accepted.”
16
「测试项目到底怎么选择？」
How Do You Choose the Right Testing Methods?
FDA 2026 Guidance并没有要求每一个产品机械完成所有测试，合理的方法应该是：
Risk-based Test Strategy
例如一个仅有USB Maintenance Port、没有Network或Cloud的设备，测试重点可能是：
USB Input
Local Privilege
Code Analysis
Firmware Update
Device Interface
而不是强行开展大量Web Application测试，但如果产品包含：
Cloud
Remote Update
Web API
Third-party OS
测试范围就可能扩大到：
Network Vulnerability
API Security
Session
Cloud Communication
Fuzz
SCA
Penetration
Attack Chaining
所以测试选择应该来自：
Architecture + Threat Model + Risk Assessment 而不是使用一份固定测试套餐。
17
「UL 2900-2-1可以提供什么参考？」
What Can UL 2900-2-1 Provide as a Reference?
FDA 2026 Guidance明确指出，包括ANSI/UL 2900、ANSI/ISA 62443-4-1以及IEC 81001-5-1在内的标准，可能部分满足其Security Testing建议。这里要注意，是“may partially meet”，并不是表示只做一个标准就自动满足全部FDA要求。
ANSI/CAN/UL 2900-2-1的测试框架中包括：
Known Vulnerability Testing
Malware Testing
Malformed Input / Fuzz Testing
Structured Penetration Testing
Software Weakness Analysis
Static Source Code Analysis
Static Binary and Bytecode Analysis
因此，它可以作为实验室制定Testing Program的重要技术参考，但最终FDA Submission仍然需要回到：
产品自己的Threat、Risk、Architecture和Security Requirements
18
「Cybersecurity Testing什么时候做？」
When Should Cybersecurity Testing Be Performed?
FDA非常明确：
Cybersecurity Testing应该贯穿SPDF
研发早期进行Security Testing，可以更早发现设计问题，减少产品Release前重新设计的风险。
产品上市以后，FDA还建议根据Risk，以适当的Regular Interval开展Cybersecurity Testing，并举例提到例如Annual Testing。
因此更合理的节奏是：
Development
Static / SCA / Requirement Testing
Integration
Interface / Fuzz / Dynamic Testing
System Verification
Threat Mitigation / Vulnerability Testing
Release Candidate
Penetration Testing
Postmarket
Periodic Security Testing / CVE Monitoring / Patch Verification
这才是真正的Lifecycle Cybersecurity V&V。
19
「FDA网络安全测试最终
要形成什么证据链？」
What Evidence Chain Should
FDA Cybersecurity Testing Build?
理想状态下应该能够追溯：
这也是为什么单独交一份Penetration Test Report往往不够，FDA真正需要看到：
为什么做这个测试、测试覆盖什么风险，以及测试结果如何支持产品Safety and Effectiveness
20
「 实验室测试真正要回答的
不是“Pass还是Fail” 」
Laboratory Testing: It’s Not Just About “Pass or Fail”
一套好的FDA Cybersecurity Testing最终应该帮助制造商回答：
Security Requirements是否真正实现？
Threat Model的关键攻击路径是否得到控制？
Third-party Software是否存在Known Vulnerability？
External Interfaces能否抵抗Malformed Input？
攻击者能否通过Vulnerability Chaining突破产品？
Penetration Test是否能够验证整个Security Architecture？
所有Finding是否已经进入Risk Management？
代码和Binary中是否存在Security Weakness？
所以FDA 2026 Guidance下的网络安全测试，不应该被理解成：
“产品送到实验室，做一个渗透测试。”
以Threat Model和Cybersecurity Risk为输入，通过多种Testing和Analysis验证Security Controls，并最终形成可以支持Premarket Submission的完整Cybersecurity V&V Evidence。
[ END ] .
联系我们
Contact us
网络安全服务
Cybersecurity Services
