ソフトウェア部品表（SBOM）とは？導入・運用と国内外10事例

ソフトウェアを使う製品には、社内で書いたコードだけでなく、オープンソースや取引先の部品が入っています。部品の種類は多く、製品の版ごとに組み合わせも変わります。

そのため、問題が起きてから構成を調べ始めると、顧客への説明や修正が遅れます。

SBOMは、こうしたソフトウェア部品を機械で読める形にした一覧です。ただし、一覧を一度作るだけでは、製品は守れません。

本記事では、SBOMの意味、SCAやVEXとの違い、規制の動き、国内外10事例を整理します。そのうえで、どのような新規事業が考えられるか、参入前に何を確認すべきかを考えます。

ソフトウェア部品表（SBOM）とは、部品と依存関係を示す一覧

SBOMは「Software Bill of Materials」の略です。日本語では、ソフトウェア部品表と呼ばれます。

製造業の部品表を思い浮かべると分かりやすいでしょう。完成品にどの部品が入り、誰が供給し、どの型番なのかを確認する一覧です。

そしてSBOMは、そのソフトウェア版です。

採用する基準の版も確認します。CISA等が2026年7月に公表した最小要素の更新では、部品のハッシュ値、ライセンス、生成ツール名、生成時の文脈が追加項目として示されています。

下の一覧は概要であり、特定制度の提出要件をすべて満たすチェック表ではありません。

• 部品やライブラリの名前
• バージョン
• 供給者や作成者
• 部品を特定する識別子
• ほかの部品との依存関係
• ライセンス
• SBOMを作成した日時と方法

代表的な交換形式はSPDXとCycloneDXです。標準形式にすると、取引先やツールの間で情報を渡し、脆弱性情報と照合しやすくなります。

ただし、形式が正しいだけで内容も正確になるわけではありません。対象製品、生成日時、抜けた範囲、部品識別子を確認します。

重要なのは、SBOMが安全証明書ではないことです。部品が分かっても、その脆弱性が製品で悪用できるとは限りません。

逆に、一覧にない独自コードの欠陥や設定ミスもあります。

正確な構成情報を、問題が見つかったときに影響範囲を絞る基礎データとして使います。

SCA・VEXとの違いは、情報をどう使うかにある

SBOMを調べると、SCA、VEX、CVE、PSIRTという言葉も出てきます。役割が違うため、同じものとして扱わない方がよいでしょう。

SCAは、SBOMを作る方法の一つです。開発時のソースコードや設定ファイルを調べる製品もあれば、完成したファームウェアを分解する製品もあります。

VEXは、特定の製品で脆弱性の影響があるか、その根拠と判断を伝える情報です。問題のある部品が見つかったら、製品の版、設定、使われる機能を確認します。

解析できない状態と、根拠をもって影響なしと判断した状態を分け、構成変更時に判断を見直します。

ツールを選ぶ前に、自社がどの問いで困っているかを決めます。たとえば、「一覧を作れない」のか、「取引先から集まらない」のか、「脆弱性が多すぎて判断できない」のかを見極めます。

というのも、課題が違えば、必要な製品と運用も変わるからです。

製品セキュリティでは、出荷後の更新が本番

Webサービスでも更新の試験と承認が必要ですが、運営会社が一元的に配布できる場合があります。一方、自動車、医療機器、工場設備などは顧客の現場にあり、稼働停止の調整や現地作業まで含めた更新計画が必要です。

販売後の期間も長くなります。たとえば、十年以上使われる設備もあります。

そのため、販売時に把握していなかったものも含め、数年後に使っている部品の脆弱性が公表されることがあります。

このとき必要なのは、三つの答えです。

1. どの製品と版に、その部品が入っているか
2. その脆弱性は、実際の製品で影響するか
3. 修正、回避策、顧客への説明を誰が進めるか

正確なSBOMと出荷版の対応があれば、影響する製品を絞りやすくなります。影響の判断には製品の使い方や設定、コード経路を調べ、修正と説明では開発・品質保証・PSIRTなどが役割を分担します。

部品表を作成した時点は、運用の開始にすぎません。そのため、製品の新版、供給者の変更、保守部品、修正版に合わせて更新します。

というのも、出荷した実物とSBOMがずれれば、緊急時に誤った判断をするからです。

この考え方は、工場設備や制御機器を扱うOTセキュリティの記事とも共通します。社内ネットワークだけでなく、長く使う製品と供給網を含めて守る必要があります。

欧州・自動車・医療機器でSBOMの実務が変わる

SBOMが注目される理由の一つは、製品セキュリティの制度が具体化していることです。ただし、業界ごとに求められる実務は同じではありません。

EUサイバーレジリエンス法（CRA）の報告義務は、対象製品で実際に悪用されている脆弱性と、製品のセキュリティに影響する重大インシデントを対象に、2026年9月11日から適用されています。検出した脆弱性をすべて報告する制度ではありません。

主要な義務は2027年12月11日から適用されます。

欧州委員会の法令要約では、EU市場に供給される接続性のあるデジタル製品を対象とし、他の法制度による適用除外も説明しています。販売地域、製品分類、自社の立場を確認したうえで、必要な報告・文書・保守を整理します。

具体的な適用判断は法務や専門家と確認してください。

自動車のUN R155は、サイバーセキュリティ管理システムと車両のリスク管理を扱います。供給者との情報連携も重要ですが、これを全供給者に同じSBOMファイルの提出を直接義務付ける制度と読み替えず、完成車メーカーの要求や契約を確認します。

米国では、FD&C法524Bの対象となる「cyber device」の市販前申請で、商用・オープンソース等を含むSBOMが要求されます。すべての医療機器に一律の条件ではありません。

FDAの2026年2月の最終ガイダンスは、設計・表示・申請文書と524Bへの対応を扱っています。法の対象と、ガイダンスの推奨を分けて確認します。

日本では、経済産業省が「ソフトウェア管理に向けたSBOMの導入に関する手引ver2.0」を公開しています。さらに、2024年の第2.0版では、脆弱性管理の実施事項や契約のひな形が追加されました。

ただし、日本の手引は、すべての企業に一律の提出を義務付ける法律ではありません。むしろ、目的と業界条件に合わせて使う実務資料です。

SBOM関連サービスを、生成・管理・運用の仕事で比較する

SBOM市場の数字を見るときは注意が必要です。調査によって、SCAだけを数える場合、製品セキュリティ基盤まで含める場合、コンサルティングを含める場合があります。

そのため、異なる調査の市場額を横に並べても、成長の大きさを正しく比べられません。

本稿で確認した製品・支援サービスを、当研究所では次の四つの仕事に整理しました。一社が複数の仕事を担う場合もあり、統計上の市場分類や成長率を示すものではありません。

1. ソースコード、バイナリ、ファームウェアから部品を見つける
2. 開発工程の中でSCAを動かし、問題のある部品を止める
3. 複数のSBOMを集め、版、VEX、規制資料を管理する
4. 自動車、医療、産業機器などの製品セキュリティ運用を支える

生成・解析だけでなく、管理や運用を扱う企業も既にあります。後半の二つを未開拓の市場と決めず、対象顧客が使っている製品、外部支援、社内作業でどこまで解決できているかを確かめます。

一覧の作成に加え、影響調査・修正・説明で何が改善するかを確認します。問い合わせへの回答時間、修正対象を絞る工数、説明に必要な記録を作る手間が評価の候補です。

継続運用には、初期設定後も構成の更新、供給者への確認、影響評価などの仕事が残ります。継続契約を考える場合は、その頻度と人員時間を測ります。

情報が蓄積することと、十分な利益が残ることは別の検証です。

導入は「作る・集める・判断する・直す」の4工程

SBOM導入では、対象製品と解決したい仕事を決め、生成から修正までを一度つないで試します。必要な機能と社内の判断が明確になります。

1．作る

自社開発部分は、ビルド工程でSBOMを生成します。組込み製品では、完成したファームウェアやバイナリから部品を調べる方法も必要です。

2．集める

取引先から部品情報を受け取ります。具体的には、形式、必須項目、版、提出時期、機密の扱いを契約や調達条件に落とします。

というのも、ファイルをメールで集めるだけでは、更新漏れや重複が起きるからです。

3．判断する

SBOMと脆弱性情報を照合し、深刻度、実際の悪用情報、使われる機能、外部からの到達性、顧客への影響で優先順位を決めます。調査が足りないものは「調査中」として担当と期限を残し、確認できないことを理由に安全扱いしません。

4．直す

修正版の開発、試験、配布、顧客説明を進めます。ただし、供給者しか直せない部品では、代替部品や一時的な軽減策も考えます。

そして、新しい版へ更新したら、SBOMも更新します。

この四工程を、製品の発売後まで回します。担当部署、回答期限、承認者、顧客への通知経路を決めて初めて、SBOMが日常業務になります。

SBOMの導入・支援事例5件と、製品紹介5件を比較する

実際の導入・支援結果と、製品が提供する機能を分けて読みます。前半5件は企業の取り組み、後半5件は公式製品情報です。

日立建機は関連するOSS管理の事例であり、10件すべてがSBOM導入の成功実績ではありません。

比較の焦点は、構成情報をどの業務へつなぐかです。導入ルール、供給者からの収集、影響判断、顧客回答、開発工程への組み込みで、必要な体制と評価指標が変わります。

国内4事例に学ぶ、SBOMとOSS管理の体制づくり

国内4件は、実証支援、OSSルール策定、医療機器の継続運用、取引先要求への対応という異なる目的を持ちます。それぞれの成果と、他社へ応用する際の条件を確認します。

三菱総合研究所と日立ソリューションズ

三菱総合研究所と日立ソリューションズの事例は、業界ごとに異なる導入条件と運用課題を調べる実証です。2022年6月から翌年3月までの約10カ月間、3分野6社にツールの選定・提供・技術支援を行いました。

成果の一つは、実運用の課題を反映したSBOM導入手引ver1.0への貢献です。6社という数は実証の参加規模で、6社すべての費用削減や本格展開の成果ではありません。

業界、開発環境、担当者の経験をそろえて評価する必要性が読み取れます。

支援事業を考えるなら、ツールの提供だけでなく、エラー対応、必要情報の整理、担当者への定着支援も見積もります。実証支援の経験を、顧客が継続して購入する運用サービスへ転用できるかは別に確かめます。

日立建機と日立ソリューションズ

日立建機の2022年公表事例では、OSS活用のルールを整えるため、開発・品質保証・知財・法務などの担当者が議論し、約3カ月でガイドラインを完成させました。確認できる成果は、文書の完成と部門間の合意形成です。

この3カ月は、SBOMツールの全社導入や脆弱性の削減に要した期間ではありません。公表時点では承認フローなどの整備は今後の課題でした。

SBOM導入でも、誰が情報を登録し、例外や出荷を承認するかを決める際の参考になります。

積水メディカルとベリサーブ

積水メディカルの導入事例では、専門知識や人員を補い、医療機器の脆弱性管理を継続する目的で「SBOM.JP」を採用し、2024年9月に本格運用を開始しました。製造委託先から集めた情報の登録・照合をベリサーブが支援し、製品への影響と対応は品質保証部門などが判断します。

年4回はSBOM情報を連携する頻度です。それとは別に日々の脆弱性監視を行い、緊急性の高い情報は都度連絡する運用を組み合わせています。

年4回しか監視しない仕組みではありません。

2025年9月時点の事例では、製品ごとに分かれていた管理を一元化し、調査依頼から顧客への回答まで会社として動ける仕組みができたと説明されています。工数・費用の削減も担当者の定性評価です。

外部へ任せる登録・監視と、社内に残す影響判断を分けることが、運用設計の参考になります。

岡山トヨタシステムサービスとサイバートラスト

岡山トヨタシステムサービスの事例は、取引先が求めるNIST SP800-171対応を背景に、OS・ミドルウェアの構成把握と脆弱性監視を進めたものです。顧客との取引条件であり、日本の全企業に同規格が直接義務付けられたという意味ではありません。

3カ月の試行後にツールを採用し、サーバー構築を要しない点、画面の分かりやすさ、新しい脆弱性の画面・メール通知を評価しています。導入後の通知運用は確認できますが、全製品の完全な検出や、事故・費用の定量的な削減を示す事例ではありません。

構成が変われば、登録情報の更新も必要です。

自動車では、供給者の情報を集める力が問われる

Hyundai MotorとCybellumの公開事例では、供給者のソフトウェアを対象に、SBOM・OSSライセンス・脆弱性を自社で評価するため、5カ月のPoCを経て製品セキュリティ基盤を採用しました。ソースだけでなくバイナリからも部品を調べる能力が選定項目でした。

導入後の成果として、開発パートナーの報告に依存していた分析を自社でも行えるようになったこと、構成把握と分析工程の改善が挙げられています。所要時間の削減率や事故件数の比較は公表されていないため、5カ月を投資回収期間とは扱いません。

自動車には、完成車メーカーが直接書いていないソフトウェアが大量に入ります。一次取引先の部品にも、その先のソフトウェアやOSSが含まれます。

したがって、自社の開発工程だけをスキャンしても全体は分かりません。取引先のSBOMを集め、形式と品質を確認し、車種、型式、部品番号へ結び付ける必要があります。

ここから検証したい事業の候補は、供給者が情報を出しやすい仕組み、完成車側が不足項目を返す仕組み、必要な構成情報を合意した範囲で共有する仕組みです。既存の調達基盤で対応できるかも確認します。

ただし、プラットフォームを作れば情報が集まるわけではありません。調達条件、契約、提出期限、問い合わせ窓口まで変える必要があります。

組込み製品は、ソースコードがない部品も調べる

ONEKEYの公式文書では、ファームウェアからの検出と外部SBOMの取り込みを組み合わせ、SPDXやCycloneDXへ出力します。VEX付き出力はCycloneDXで提供されています。

これらは機能の説明であり、対象部品が必ずすべて検出されるという保証ではありません。

取り込んだSBOMにしかない部品は、自動影響評価の対象外になる場合があります。ONEKEYは、解析するバイナリの証拠がない部品ではAutomated Impact Assessmentを実行できないと説明しています。

収集した一覧と、実際に検証できる範囲を分けて評価します。

Finite Stateは、ソース、ファームウェア、バイナリ、供給者SBOMを、出荷した製品の記録へまとめる機能を提供しています。VEXや確認記録の作成支援もありますが、規制適合を自動で保証するものとしてではなく、どの証拠を収集・レビューできるかで比較します。

両社の違いを細かい機能で比べる前に、自社の証拠がどこにあるかを確認します。たとえば、開発リポジトリにあるのか、完成したファームウェアしかないのか、供給者の資料として届くのかという入口によって、適した製品が変わります。

到達可能性とVEXで修正の順番を決める

部品とCVEを照合すると、多くの警告が出ます。すべてを同じ優先度で扱えば、開発者は対応しきれません。

Endor Labsの到達可能性解析には、関数単位、依存パッケージ単位、事前計算した依存関係による評価があり、必要な入力と判定の細かさが異なります。「到達可能性を判定できない」と「到達しない」は区別します。

言語等が未対応のために判定できない場合もあるため、結果だけでなく解析が完了した範囲を確認します。

静的解析で経路が見つからなかった場合も、対象のビルド、実行時の読み込み、設定変更などの条件を確かめます。特定の版での判断を、別の版や運用環境へそのまま引き継がないことが重要です。

Interlynkは、SBOMの生成だけでなく、取引先からの収集、品質確認、脆弱性監視、VEX、共有までを一つの流れにします。製品、環境、版、部品、脆弱性という階層で管理し、更新で情報が古くなる問題を減らします。

Anchoreは、コンテナや開発工程に近い領域が中心です。具体的には、SBOMを生成・取り込みし、開発パイプラインやレジストリの脆弱性を確認します。

そのため、問題のある成果物をリリース前に止める使い方ができます。

これらは各社の提供機能であり、同じ条件での性能比較や顧客での改善率を示すものではありません。自社の成果物を使い、誤検出の確認、担当者への引き継ぎ、判断記録の出力まで試します。

架空例：同じ部品でも、製品の版ごとに判断を分ける

説明用に、産業用ゲートウェイのA版とB版に同じライブラリが入っていると仮定します。公表された脆弱性について、A版では該当機能を使い、B版は構成が異なるものの影響の確認が済んでいません。

これは実在製品の安全評価ではありません。

VEX等には、対象の版、判断の根拠、作成者、日時を対応させます。B版を一度調べて影響なしと判断できた場合も、構成や利用条件が変われば再確認します。

部品名が一致しただけで全版を危険扱いせず、調査が終わっていない版を安全扱いしないための運用です。

SBOMの事業機会は、既存製品で解決しきれない仕事から探す

参入の判断には、既存製品で足りない仕事と、顧客が支払う理由が必要です。生成だけでなく、収集・品質確認・監視も既存製品が扱っています。

機能名の違いより、顧客の実際の手順で残る作業を調べます。

例えば、次の課題が対象顧客に残っているかを確認します。市場全体で未解決と確認された一覧ではありません。

• 取引先へ何を依頼すればよいか分からない
• 届いたSBOMの品質を確認できない
• 自社製品と部品表の版が一致しない
• 警告が多すぎて修正の順番を決められない
• 脆弱性の報告期限に合わせて社内承認を進められない
• 長期保守の製品で、修正版を出せない
• 顧客へ説明できる記録が残っていない

これらの課題は、調達、品質保証、開発、法務、顧客対応にまたがります。役割分担だけで解決する問題と、追加のサービスが必要な問題を分けます。

支援事業では、顧客ごとの調整工数を含め、対価に見合う改善が出るかを検証します。

また、ソブリンクラウドの記事で扱ったデータ所在地や運用主体の論点も関係します。SBOMには、製品構成や供給者に関する機密情報が含まれる場合があるためです。

そのため、保存場所、閲覧権限、外部事業者による二次利用を確認する必要があります。

自社はSBOM関連事業のどこへ入れるか

顧客接点、供給網、解析技術、運用人材から近い入口を確認します。

01　製造業の顧客と運用人材を持つ

対象製品を絞り、導入と継続運用を支援します。

• 製品版を追跡できる
• 更新と監視を続けられる
• 顧客回答の手順を作れる

02　調達・供給者との接点を持つ

取引先からSBOMを集め、品質と版を確認します。

• 必須項目を定義できる
• 機密と権限を守れる
• 不足情報を供給者へ返せる

03　脆弱性判断と規制対応に強い

VEX、承認、報告、証跡の流れを整えます。

• 到達可能性を説明できる
• 期限と責任者を決められる
• 規制専門家と連携できる

04　組込み・長期保守に強い

ファームウェアと出荷後の製品を継続管理します。

• ソースなしでも確認できる
• バックポートを追える
• 長期保守の費用を設計できる

新規事業で考えられる4つの参入方法

参入方法は、汎用ツールを一から作ることだけではありません。自社の顧客接点と専門知識に近い入口を選びます。

第一の候補は、導入と運用の支援です。積水メディカルの例のように、専門人材が不足する顧客なら、登録・照合・監視を外部が担い、製品への影響判断を社内に残す分担を検討できます。

製品数の少なさだけで代行が最適とは決めません。

第二は、供給者との情報交換です。これは、自動車や産業機器の取引関係を持つ企業に向きます。

具体的には、SBOMを集めるだけでなく、足りない項目を返し、版の不一致を知らせます。

第三は、判断と報告の流れです。具体的には、EU法や顧客契約に合わせ、期限、承認、VEX、報告内容を管理します。

そして、開発、法務、顧客対応を一つの案件で動かします。

第四は、組込み製品への特化です。ここでは、ファームウェア解析だけでなく、RTOS、Yocto、バックポート、保守部品の知識が差になります。

業界ごとの長い製品寿命まで理解する必要があります。

製品セキュリティ事業で先に決めたい7つの懸念

構成情報の正確さ、運用体制、開示範囲、保守原価を確認します。解析ツールの機能だけでは決まらない7つの論点です。

1．一覧の精度を保証しすぎる

どの解析方法にも、見落としと誤検出があります。そのため、生成したSBOMが完全だと約束すると、事故時の責任が重くなります。

むしろ、対象、検出方法、確認できない範囲を契約と画面に示します。

2．製品版とSBOMがずれる

開発版のSBOMと、実際に出荷した製品が違う場合があります。生成の時点、ビルド番号、署名、配布記録を結び付けます。

3．警告が多すぎて運用が止まる

深刻度だけで並べると、重要でない警告に時間を使います。到達可能性、利用機能、外部公開、悪用状況、製品の重要度を加えて絞ります。

4．取引先が情報を出さない

SBOMは知的財産や供給関係を見せる可能性があります。誰に何を開示するか、必要項目だけを渡せるか、契約終了後に削除するかを決めます。

5．判断責任が曖昧になる

ツール会社は脆弱性を示せても、製品を出荷してよいかは決められません。開発、品質保証、PSIRT、経営、顧客の役割を分けます。

6．長期保守に費用が積み上がる

監視する製品や版が増えると、確認・問い合わせ・更新の工数も変わります。一括料金でも保守原価を含める設計はできますが、想定期間と対象の追加条件が曖昧だと採算が崩れます。

初期費用と保守費用、対応期限、例外作業を明確にします。

7．規制対応を保証してしまう

SBOMがあっても、法令や認証の全要件を満たすとは限りません。法的判断、技術評価、証拠作成の責任範囲を分け、必要に応じて専門家と組みます。

セキュリティ事業は、売る前の説明が重要です。できることだけでなく、できないこと、顧客が担う判断、事故時の連絡手順まで示します。

参入・提携・待機・見送りは、運用資産で決める

自社が参入できるかは、四つの質問で判断できます。

1. 顧客の製品と版を継続して特定できるか
2. 取引先や開発部門から必要情報を集められるか
3. 脆弱性の優先順位を説明できる専門家がいるか
4. 出荷後の監視と顧客対応を続けられるか

四つがそろうなら、運用サービスや業界特化型基盤として参入を検討できます。

顧客関係はあるが解析技術がない場合は、ONEKEY、Finite State、国内SCA事業者などとの提携が現実的です。反対に、解析技術はあっても業界の販売経路と責任体制がなければ、完成品メーカーや試験会社と組みます。

顧客が「規制が気になる」と話すだけで、対象製品、担当者、予算、保守期間が決まっていない場合は待機です。まず一製品の有償診断や運用設計で、支払意思と社内体制を確認します。

見送るべきなのは、SBOMを安全証明として売る場合です。製品の実物を確認できず、判断責任者もおらず、事故時の連絡もできない状態で事業化すると、顧客の安心ではなく誤解を増やします。

SBOMについてよくある質問

SBOMの定義、安全性との関係、交換形式、導入・参入の進め方を整理します。

Q. SBOMとは何ですか？

A. SBOMは、製品やサービスに含まれるソフトウェア部品、版、供給者、依存関係などを機械で読める形にした一覧です。日本語ではソフトウェア部品表と呼ばれます。

Q. SBOMがあれば製品は安全ですか？

A. 安全とは限りません。SBOMは影響範囲を調べる基礎データです。独自コードの欠陥、設定ミス、悪用可能性、修正方法は別に確認する必要があります。

Q. SBOMとSCAの違いは何ですか？

A. SBOMは部品の一覧です。SCAはソースコードやバイナリを調べ、部品、脆弱性、ライセンスを分析する方法やツールを指します。SCAの結果からSBOMを作ることがあります。

Q. SPDXとCycloneDXはどちらを選べばよいですか？

A. 取引先、規制、利用ツールが受け取れる形式を優先します。どちらかの名前だけで決めず、必要な項目、版、依存関係、VEXの扱いまで小さく試してください。

Q. 中小企業にもSBOMは必要ですか？

A. 業種と取引条件によります。自社製品が欧州、自動車、医療、重要インフラの供給網に入る場合は、顧客から構成情報を求められる可能性があります。まず対象製品を一つに絞る方法が現実的です。

Q. SBOM事業へ参入するなら、どこから始めるべきですか？

A. 自社の顧客接点と専門知識を確認し、収集、品質確認、影響判断、報告、長期保守のうち未解決の仕事を一つ選びます。既存製品や社内運用で解決できない理由、支払者、必要な工数を試行で確かめます。

まとめ｜SBOMは更新と判断の仕組みまで設計する

SBOMは、製品に含まれるソフトウェア部品を示す一覧です。しかし、一覧を一度作るだけでは、脆弱性への対応は速くなりません。

必要なのは、作る、集める、判断する、直すという四つの工程です。製品の版とSBOMを合わせ、供給者から情報を集め、VEXなどで影響を判断し、修正と顧客説明を進めます。

導入・支援の5事例では、目的に応じた構成把握や組織づくりが確認できました。製品5社の比較からは、収集、解析、影響判断、開発工程との連携という選択肢が分かります。

実績と提供機能を分け、自社で必要な仕事から選びます。

参入する企業は、機能の多さより、誰のどの判断を速くするかを決めるべきです。顧客の製品と供給網を理解したうえで、必要な専門人材、役割分担、保守の採算を試します。

情報確認日：2026年9月27日。事例の結果は各社の公表時点、製品機能は確認時点の文書に基づきます。

法制度は対象・適用日を確認し、個別の法適合を保証するものではありません。

参考文献

制度、導入事例、製品仕様の確認に用いた一次資料です。結果の範囲と時点は本文に併記しました。

• 経済産業省「SBOMの導入に関する手引ver2.0」
• CISA「2026年版SBOM最小要素の公表（2026年7月29日）」
• EU Cyber Resilience Act, Regulation (EU) 2024/2847
• UNECE UN Regulation No. 155
• FDA 医療機器サイバーセキュリティ最終ガイダンス（2026年2月）
• 日立ソリューションズ「SBOM事例」
• ベリサーブ「積水メディカル株式会社様 導入事例」
• サイバートラスト「岡山トヨタシステムサービス 導入事例」
• Cybellum「Hyundai Motor Company Case Study」
• ONEKEY「SBOM management」
• Finite State「Product Security Platform」
• Endor Labs「Reachability analysis」
• Interlynk「Automated SBOM Management」
• Anchore「Security Analysis and Reporting」