米国食品医薬品局 (FDA) の SBOM（ソフトウェア部品表）作成の義務化は、医療機器メーカーにとって大きな変革をもたらし、ますますつながりが深まる世界において、より高い透明性とサイバーセキュリティの向上を強く求めています。ソフトウェアコンポーネントを追跡するための、手作業による時代遅れのプロセスは過去のものとなりました。今日、メーカーは、デバイス内で実行されているすべてのソフトウェアについて、リアルタイムかつ包括的な情報を提供する必要があります。
サイバーセキュリティの脅威が高まり続ける中、透明性は単なる規制上のハードルではなく、患者の安全を守り、コンプライアンスを維持するために不可欠な要素です。この記事では、FDA の SBOM 要件の詳細、その重要性、ソフトウェア構成分析 (SCA) などのツールを活用することでコンプライアンスを容易に実現できる方法について説明します。この記事を最後まで読めば、コンプライアンスを維持し、デバイスを安全かつ最新の状態に保ち、市場投入に向けて万全な状態を維持するためのロードマップが得られるでしょう。
SBOM が必須になった理由
医療機器はますます複雑なソフトウェアシステムに依存するようになり、サイバーセキュリティの脅威に対して脆弱になっています。FDAはこれを認識し、これらの機器に組み込まれているすべてのソフトウェアコンポーネントが完全に透明で説明責任が果たされていることを確認するために SBOM 要件を導入しました。これは単なるコンプライアンスのチェックボックスではなく、メーカー、規制当局、患者が医療機器を動かすテクノロジーを信頼できる、より安全な医療環境を構築するための積極的なステップです。
FDAの義務
FDA の SBOM 要件は、メーカーに対し、自社のデバイスを動かすソフトウェア（オープンソース、独自開発、サードパーティ製を問わず）に関する詳細情報の開示を義務付けています。SBOM は機械可読（コンピュータが自動的に読み取り、処理できるデータ形式のこと）で、SPDX や CycloneDX などの標準フォーマットに準拠している必要があります。これによりメーカー、規制当局、監査機関など、すべての関係者がソフトウェアを評価するための標準化された方法を確保できます。
何が危機に瀕しているのか
SBOM 標準に準拠しないと、深刻な結果を招く可能性があります。製品承認の遅延だけでなく、非準拠によりデバイスがサイバーセキュリティの脅威にさらされ、高額なリコール、法的影響、さらには患者の安全に対するリスクにつながる可能性があります。FDA による継続的な監視により、メーカーは最新の SBOM を維持し、新しい脆弱性に迅速に対応し、デバイスのライフサイクル全体を通じて積極的なリスク管理を実施する必要があります。最終的に、この義務化により、メーカーはセキュリティ体制を強化し、古いソフトウェアのリスクを回避する機会が得られます。
SBOM がなぜ重要であるかについて説明したので、次に、具体的に何を含める必要があるのかについて詳しく見ていきましょう。
SBOM 101 – FDA のチェックリスト
SBOM は単なるソフトウェアコンポーネントのリストではありません。FDA の基準を満たすには、医療機器で実行されるすべてのソフトウェアコンポーネントについて、詳細かつ構造化された概要を提供する必要があります。では、FDA は具体的に何を期待しているのでしょうか。
SBOM の要旨
ここでは、FDA の基準を満たすために SBOM に含める必要がある主要コンポーネントと、それがコンプライアンスとセキュリティの両方にとって重要である理由について説明します。
サプライヤー情報
含める内容：各ソフトウェアコンポーネントのソース（オープンソース、独自仕様、またはサードパーティ）を特定します。
理由：サプライヤーを知ることで、ライセンスや法的リスクを管理し、古くなったコンポーネントや廃棄されたコンポーネントがセキュリティ上の脆弱性をもたらさないようにすることができます。
コンポーネントのバージョン
含める内容：各コンポーネントの正確なバージョン番号を明示します。
理由：ソフトウェアのバージョンによって脆弱性は異なります。コンポーネントのバージョンを把握しておくことは、玄関のドアを開ける鍵を知っているようなものです。間違った鍵を使用すると警報が鳴る可能性があるからです（最悪の場合、ハッカーが侵入する可能性もあります）。
依存関係
含める内容：ソフトウェアコンポーネントが相互にどのように依存しているかを概説します。
理由：1つのコンポーネントの脆弱性が他のコンポーネントに影響を及ぼす可能性があります。依存関係を文書化することで、ソフトウェアの問題の波及効果を特定しやすくなります。
タイムスタンプ
含める内容:：SBOM の作成日とタイムスタンプを含めます。
理由：タイムスタンプにより、SBOM がソフトウェアの現在の状態を反映し、新しい脆弱性が発生したときに追跡できるようになります。
脆弱性評価
含める内容：各コンポーネントの既知の脆弱性と軽減策をリストにします。
理由：FDA は、サイバーセキュリティの脅威を防ぐために、メーカーにソフトウェアリスクの積極的な管理を実証することを要求しています。
ライフサイクル情報
含める内容：コンポーネントが保守されているか、廃止されているか、またはサポートされていないかについての詳細を提供します。
理由：サポートが終了したソフトウェアコンポーネントは、セキュリティアップデートが提供されなくなるため、リスクを伴います。ライフサイクル情報は、長期的なセキュリティリスクの評価に役立ちます。
機械可読形式
SPDX や CycloneDX などの機械可読形式で SBOM を送信すると、データにアクセスでき、自動的に処理されるため、人的エラーが削減され、監査プロセスが簡素化されます。
注目の人物は誰ですか?
SBOM の作成義務は、「サイバーデバイス」に分類される医療機器に適用されます。これらの機器は、ネットワークに接続したり、組込みソフトウェアを使用したり、サイバーセキュリティの脅威に対して脆弱です。ペースメーカー、インスリンポンプ、画像診断システムなどは、ソフトウェアに依存するだけでなく、インターネットにも接続されるため、サイバー攻撃の標的となります。
誰が順守しなければならないか
デバイスがインターネットに接続したり、ソフトウェアを使用したり、「アップデートしてください」という通知が表示されたりする場合、それは FDA の目から見て正式に「サイバーデバイス」です。FDA によると、サイバーデバイスとは次のような製品です。
- インターネットまたはネットワークへの接続：Wi-Fi、Bluetooth、またはその他のネットワークプロトコルを使用するインスリンポンプ、ペースメーカー、画像システムなどのデバイスは、サイバー攻撃に対して脆弱です。
- 機能がソフトウェアに依存：オープンソースか独自のものかを問わず、動作に不可欠な組込みソフトウェアを備えたデバイスはすべて、この義務の対象となります。
- サイバーセキュリティの脅威にさらされる可能性：機密データを保存したり、外部システムとインターフェースするデバイスは侵害のリスクがあり、FDA はこれらのリスクを軽減するために完全なソフトウェアの透明性を義務付けています。
FDA は、サイバーデバイスに焦点を当てることで、包括的なソフトウェアの透明性を確保し、重大なインシデントにつながる前にメーカーが脆弱性を特定して対処できるようにする標準化されたプロセスを作成することを目指しています。
サイバーセキュリティリスクの管理
FDA の SBOM 作成義務は、ソフトウェアの透明性確保だけを規定しているわけではありません。医療機器で使用される複雑なソフトウェアに関連するサイバーセキュリティリスクを積極的に管理することも目的としています。次のセクションでは、脆弱性評価の実施からソフトウェアライセンスに関連する法的リスクへの対応まで、これらのリスクを管理するために必要な主要な手順について説明します。
脆弱性評価
SBOM には、各ソフトウェアコンポーネントの既知の脆弱性の詳細なレビューを含める必要があります。製造元はリスクを特定し、デバイスへの影響を評価し、リスクを軽減するための手順を概説する必要があります。目標はすべてのリスクを排除することではなく、プロアクティブなリスク管理を実証し、軽微な問題が重大なサイバーセキュリティの脅威に発展するのを防ぐことです。この継続的なプロセスは、コンプライアンスを維持し、デバイスの安全性を確保するために不可欠です。
VEX (Vulnerability Exploitability eXchange：脆弱性悪用可能性交換)の使用
FDA は、メーカーに対し、脆弱性の状況を明確にするためにVEX ステートメントの使用を推奨しています。VEX は、脆弱性が軽減されているか、あるいは差し迫ったリスクをもたらさないかを説明するのに役立ちます。これは規制当局に重要な背景情報を提供し、審査プロセスを効率化し、医療提供者と患者にデバイスのセキュリティについて安心感を与えることができます。
法的リスクの回避
オープンソースソフトウェアの使用は、医療機器メーカーにとって費用対効果の高いソリューションになり得ますが、リスクも伴います。SBOM は、使用されているソフトウェアコンポーネントと、そのライセンス条件への準拠状況を把握するのに役立ちます。ソフトウェア構成分析(SCA：Software Composition Analysis)ツールによって生成され、専門のソフトウェア監査担当者によってサポートされる SBOM を利用することで、メーカーはすべてのライセンス要件を満たし、知的財産を保護し、高額な法的措置を回避できます。この積極的なアプローチにより、メーカーは訴訟や規制上の障害を回避し、デバイスの安全性とイノベーションに集中できます。
SCA ツールによる SBOM コンプライアンスの管理方法
FDA の SBOM 作成義務では、医療機器で使用されるソフトウェアコンポーネントに高い透明性と詳細さが求められています。これを手作業で管理するのは、特に複雑なソフトウェアシステムでは大変な作業です。そこで、SCAツールが役立ちます。SCAツールは、SBOM の作成、管理、コンプライアンスを自動化し、手作業の負担を軽減すると同時に、SBOM が正確で最新であり、FDA に準拠していることを確保します。
SCA ツールがこのプロセスをどのように効率化するのか、そしてそれがコンプライアンスにとってなぜ不可欠なのかを探ってみましょう。
自動 SBOM 生成
SCA ツールは、手動では見逃されがちなサードパーティ製やオープンソースのコンポーネントを含め、すべてのソフトウェアコンポーネントをスキャンすることで、SBOM の作成を自動化します。これにより、面倒な手作業によるドキュメント作成を必要とせずに、包括的かつ正確なインベントリを作成できます。
SBOM を手動で作成すると時間がかかり、特にソフトウェアが進化するにつれてエラーが発生しやすくなります。自動化によりすべてのコンポーネントが正確にキャプチャされ、時間が節約され、人的エラーが削減され、FDA コンプライアンスが確保されます。
リアルタイム監視
SCA ツールはソフトウェアコンポーネントをリアルタイムで継続的に監視し、新しい脆弱性が発見されると SBOM を自動的に更新します。これにより、SBOM が常に最新の状態に保たれ、メーカーは潜在的なリスクを即座に把握できます。サイバーセキュリティの脅威は急速に進化するため、リアルタイム監視により、メーカーはデバイスのライフサイクル全体にわたってコンプライアンスを維持し、脅威が発生したときに対応してデバイスの整合性を保護することができます。
ソース SBOM
SCA ツールは、専門の監査担当者の協力を得て、依存関係やサードパーティ製ソフトウェアを含むソフトウェアコンポーネントの完全かつ詳細なインベントリを提供するソース SBOM を作成します。これらのソース SBOM は表面的なスキャンよりも深く掘り下げて、メーカーに潜在的なリスクの完全な可視性を提供します。
ソース SBOM は、Cybersecurity and Infrastructure Security Agency （CISA：アメリカ合衆国サイバーセキュリティ・社会基盤安全保障庁）の 6 種類の SBOMに準拠しています。ソフトウェア ID、依存関係、ソフトウェアの来歴、開発の整合性、ビルドの整合性、運用の整合性を網羅しています。CISA のフレームワークに準拠することで、FDA の要件を満たすだけでなく、業界全体のサイバーセキュリティの基準が強化され、メーカーのリスク管理とコンプライアンスを向上させるのに役立ちます。
SBOMの波及効果
FDA の SBOM 義務は他の業界への青写真となる
これまで見てきたように、SCAツールはコンプライアンスを簡素化するだけでなく、医療機器のセキュリティを強化します。しかし、SBOM の影響は医療分野だけにとどまりません。
FDA の SBOM 作成の義務化は、他の業界が同様の基準を採用するきっかけとなっています。サイバーセキュリティの脅威があらゆる分野で増大する中、透明性と積極的なリスク管理が不可欠になっています。これまでは医療機器が中心でしたが、自動車、航空、製造業などの業界でも、ソフトウェアの脆弱性管理やコネクテッドデバイスを保護するための SBOM の価値が認識され始めています。
医療機器を越えて
FDA の SBOM 作成の義務化は、ソフトウェアの安全性が極めて重要な他の業界にとってのモデルとなる可能性があります。自動車業界では、エンジン性能からナビゲーションまで、あらゆるものがソフトウェアによって制御されています。同様に、航空業界では、飛行制御と通信システムにソフトウェアが使用されています。これらの業界は、医療機器と同様のサイバーセキュリティリスクに直面しており、SBOM の実践を採用することで、深刻な被害につながる前に脆弱性を特定して対処することが可能になります。
ソフトウェア、特にコネクテッドデバイスに依存する業界は、FDA の先例に従う可能性が高いです。
世界的な規制動向：世界標準としての SBOM
FDA の義務化は、サイバーセキュリティの透明性向上に向けた広範な動きの一環です。世界的に、規制当局はソフトウェアセキュリティリスクの管理における SBOM の重要性を認識しつつあります。EUサイバーレジリエンス法では、接続されたデバイスに SBOM 作成が義務付けられる予定で、アジアや南米などの他の地域でも同様の規制が検討されています。
SBOM がまもなく世界標準となり、さまざまな業界や規制環境でソフトウェアのセキュリティが確保されるようになることは明らかです。