如何在现代 DevOps 流水线中实现 IEC 62304（可追溯性、SOUP、风险控制和 CI/CD 证据）
Source: Dev.to
如果您正在构建 SaMD 或医疗器械内部的软件，您可能已经搜索过：
“如何在 Agile/DevOps 工作流中实现 IEC 62304？”
真正的挑战不是学习标准，而是 将其落地运营，同时仍然保持现代工程的感觉：PR、CI/CD、IaC、容器、SBOM、自动化测试以及快速发布。
IEC 62304 概要
- 目的： 定义医疗器械软件的软件生命周期过程。
- 不可协商的要求： 必须能够端到端证明已实施、已验证软件风险控制，并且已对更改进行控制。
- 证据管道 = 你的可追溯性图。
Safety Classes
| Class | Description |
|---|---|
| A | 不会造成伤害 |
| B | 可能导致非严重伤害 |
| C | 可能导致严重伤害或死亡 |
类别决定了在单元验证、独立性、追踪深度、审查严格程度、异常处理等方面的深入程度。
工程翻译： 定义一个 “合规配置文件”（文档 + CI 规则），其内容会根据类别和特性风险而变化。
最小可行可追溯图
Hazard (ISO 14971) → Risk control → Software requirement → Design element
→ Code change → Test case → Test result → Release这并不是繁琐的工作——它是证明风险控制有效并在审计中不靠奇迹生存的方式。（IEC 62304 和 ISO 14971 正是因为这种映射而常常一起实施。）
建议的仓库布局
/docs # compliance docs, risk analyses, etc.
/src # source code
/.github (or /ci) # CI/CD pipelines, GitHub Actions, etc.为什么这样可行
- 生命周期对齐 – 计划 → 需求 → 设计 → 验证 → 发布。
- CI 强制证据 – 后期无需手动追踪。
- 与工具无关 – 适用于 GitHub、GitLab、Bitbucket 等。
- 第 1 天无需重量级工具 – 只需稳定标识符和机器可检查的链接。
推荐模式：Typed IDs + PR Gating
标识符方案
| 制品 | 前缀 | 示例 |
|---|---|---|
| Risk control | RC- | RC-012 |
| Requirement | SRS- | SRS-041 |
| Design | SDS- | SDS-010 |
| Test | TST- | TST-201 |
| Anomaly | ANOM- | ANOM-033 |
强制规则（通过 CI / PR 模板）
- PR 描述 必须至少包含一个
SRS-###。 - 如果 PR 涉及安全关键模块，则需要关联一个
RC-###。 - 测试必须在其元数据或文档字符串中引用相应的
SRS-###。 - CI 会生成可追溯性报告，如果缺少必需的链接则 失败。
示例 PR 模板片段
### Linked items
- **Requirements:** `SRS-041`, `SRS-044`
- **Risk controls:** `RC-012`
- **Tests:** `TST-201`, `TST-205`
- **Anomalies (if any):** `ANOM-033`你已经将“可追溯性”转化为可强制执行的契约。
从风险控制到工程制品
常见的合规缺口：风险控制仅存在于 PDF 中，且从未纳入工程工作流。
将风险控制表示为：
- 需求（带接受准则）
- 设计约束（架构决策）
- 自动化验证（测试 + CI 证据）
示例：报警时序风险控制
- 风险控制
RC-012– “报警必须在 2 秒内触发。” - 需求
SRS-041– 时序规范。 - 设计
SDS-010– 事件循环 + 优先级调度。 - 测试 –
TST-201（集成），TST-202（系统）。 - 发布证据 – CI 测试报告 + 性能日志，归档为制品。
这形成了一条从风险 → 验证的清晰链路。
管理 SOUP（未知来源软件）
IEC 62304 将 SOUP（开源库、操作系统组件、第三方 SDK 等）视为安全影响的一部分——如果你发布它，你就拥有它。
最小化 SOUP 控制策略
- 维护依赖清单（SBOM 为理想选择）。
- 锁定版本 并使用 lockfile。
- 定义更新规则——计划的、审查的、测试的。
- 验证关键依赖的安全影响。
- 添加补偿性控制——沙箱、超时、重试、看门狗。
CI “SOUP 门”
如果在未提供以下信息的情况下引入新依赖，则构建失败：
- 记录的用途
- 负责人
- 版本锁定
- 风险说明（即使是简短的）
这将 “我们使用开源” 与 “我们控制 SOUP” 区分开来。
IEC 62304 所需的验证证据
| 级别 | 典型产物 |
|---|---|
| 单元 | 逻辑层测试 |
| 集成 | 接口与数据流测试 |
| 系统 | 需求层行为测试 |
| 非功能 | 性能、可靠性、安全（根据风险需求） |
让 CI 生成审计友好的产物
在你的 CI 流水线中：
- 导出 测试摘要（JUnit XML，HTML 报告）。
- 归档 带版本的日志（性能、覆盖率、静态分析）。
- 嵌入 构建元数据（提交哈希、环境、工具版本）。
每次构建都成为可重现的“迷你发布包”。
进一步阅读
关于 IEC 62304、安全等级和典型工件的更深入探讨，请参见以下链接：
变更管理与发布文档
IEC 62304 要求 受控的变更管理 和 维护。
工程翻译
您的 Git 工作流 就是 变更控制系统——只要您正确地组织它。
受监管的 PR 检查清单（轻量但强大）
- 改动了什么，为什么？
- 受影响的需求 (
SRS-###)？ - 受影响的风险控制 (
RC-###)？ - 回归范围（需要重新运行哪些测试）？
- 新的异常？
- SOUP（商用现成软件）变更？
自动化枯燥的部分
- 映射被触及的模块 → 所需的测试套件。
- 对安全关键区域 强制必须的审阅者。
- 若缺少追踪链接 阻止合并。
CI 生成的发布包
无需手动组装文档，让 CI 生成：
- 追踪报告（需求 ↔ 测试 ↔ 结果）
- SBOM / 依赖清单
- 测试摘要 + 环境元数据
- 已知异常列表（附风险评估说明）
- 版本 ID 与制品哈希
将这些存放在不可变的制品库中（签名发布、受控存储）。
这将审计从“讲故事”转变为“这里是证据包”，消除审计的首要失败模式：缺失或不一致的文档。
祝合规编码愉快！
结论
IEC 62304 并不是“一次性完成”的任务，而是需要持续嵌入的过程：
- 可追溯性 通过 PR + CI 强制执行
- 风险控制 以需求 + 测试的形式实现
- SOUP 作为依赖工程的一部分进行管理
- 发布 打包并附带可复现的证据
如果您希望有一个团队帮助您以仍然符合现代软件交付（敏捷、CI/CD、云）方式实现 IEC 62304，请在此处了解 CitrusBits：