SOUP (Software of Unknown Provenance)
出自不明ソフトウェア — 自分の(医療)機器のために開発したのでない、または十分な開発記録が手に入らないソフトウェア部品。IEC 62304 の用語で、OS・OSS ライブラリ・サードパーティのネットワークスタック・クラウド API などが該当する。「使う部品の信頼を外注できない」ことを制度化した概念。
定義の2条件
どちらかに当てはまれば SOUP:
- 出自不明 — 機器組み込みを目的に開発されていない(既製・汎用)
- 記録不足 — 開発プロセスの記録が、安全臨界の要求を満たす形で残っていない
→ 自社で安全臨界プロセスに沿って作ったコード以外はほぼ SOUP になる。現代のソフトは大半が SOUP(自分で書くのは数%、残りは依存)という現実が、この概念の重さの源。
IEC 62304 が SOUP に課すこと
「使うな」ではなく「正当化して管理せよ」。
| 要求 | 内容 |
|---|---|
| 同定 | SOUP の名称・製造元・バージョンを特定・記録 |
| 要求の明示 | その SOUP に期待する機能・性能要求(5.3.3)、必要な動作環境(5.3.4) |
| 既知不具合の評価 | SOUP の公開アノマリリスト(既知バグ/CVE)を入手し、安全に影響するものが無いか評価(7.1.3) |
| リスク制御 | SOUP 起因のリスクを残存リスクとして管理。テスト要求を定める |
特に既知不具合の継続評価が肝 — 採用時に問題なくても、後から見つかった CVE が安全に効くなら対処が要る。実質的に継続的な CVE トリアージであり、現代の SBOM(部品表)/サプライチェーンセキュリティの先取り。
なぜ重要か(エンジニアリングの含意)
- 責任範囲は依存物まで及ぶ — コンパイラ・OS・ランタイムも検証/正当化対象。許容される安全性の第6原則そのもの。
- 境界の問題 — 「自分のコードは完璧」でも、システムの大半を占める SOUP を正当化できなければ全体は通らない。
- 認証ギャップの「ランタイム未認証」= WASM ランタイム(wasmtime 等)は典型的な SOUP。Almide のコンパイラが機械証明されていても、実行系を SOUP として正当化する負担は別に残る。
他標準での対応物
SOUP は医療の呼び名で、同じ「既製・外部ソフトをどう扱うか」は各基準にある。
| 標準 | 対応概念 |
|---|---|
| IEC 62304(医療) | SOUP |
| [do-178c|DO-178C] | COTS / PDS(Previously Developed Software)、ツールは DO-330 で認定 |
| [iso-26262] | ソフトウェアコンポーネントの qualification / SEooC |
Links
関連
- iec-62304 — SOUP の出自。医療機器ソフトのライフサイクル標準
- safety-critical-certification — ランタイム未認証 = SOUP 問題
- accepted-safety-in-systems — 第6原則「責任範囲は依存物まで」の具体
- cots — 同じ対象を調達側から見た呼び名。無改変要件・統合コストの実証データ・OSS/SaaS への延長
- do-178c / iso-26262 — 他基準での対応概念(COTS/PDS, qualification)
- rust-safety-critical — rustc も本来 SOUP。Ferrocene の tool qualification がそれを解く例
- ferrocene — rustc を SOUP でなくす tool qualification の実例