製造業の「SBOM」は誰が構築し運用／管理すべきか【後編】：武田一城の「製品セキュリティ」進化論（4）（2/2 ページ）

[武田一城，MONOist]

1．設計開発部門

• 【特徴】
  • ソフトウェアの構成を最も熟知している。セキュア開発の推進という観点での実施も筋が通っており、実行しやすい
• 【メリット】
  • 開発の初期段階（シフトレフト）からSBOMを作成／更新できるため、脆弱性の早期発見／修正が最も効率的となる
  • OSS（オープンソースソフトウェア）ライセンスの依存関係など、コードレベルの判断が迅速にできる
• 【デメリット】
  • 開発チームの負荷が増えることで製品開発スピードが落ちる
  • 製品出荷後の長期間にわたる対応は組織の性質上苦手で対応がおろそかになりやすい
  • 開発チームが複数ある場合、組織／チームごとに管理手法がばらつきやすい

2．製造部門

• 【特徴】
  • 従来の物理的な「部品表（BOM）」の延長として標準化した管理がしやすい
• 【メリット】
  • 既存のBOM管理フロー（ERP連携など）を活用しやすい
  • 出荷単位でのソフトウェア構成を物理部品とひも付けて一元管理しやすい
• 【デメリット】
  • ライブラリの依存関係などのソフトウェアの詳細の専門知識が不足しがち
  • 脆弱性情報の評価やパッチ適用の可否を自部門だけで判断するのが難しい

3．リスク管理部門

• 【特徴】
  • CRAやJC-STARなど、法的／ガバナンス的観点を主導できる
• 【メリット】
  • 全社横断的なガバナンスとサプライチェーンリスクの評価や管理に強い
  • 監査対応がスムーズになる。
• 【デメリット】
  • ソフトウェア知識や実務（SBOM生成や脆弱性修正）から遠い
  • 現場意識の低さから「ルールの形骸化」の恐れがあり、緊急時の対応が遅れる

4．品質管理部門

• 【特徴】
  • 「品質保証プロセス」として網羅的な管理を行うことができる
• 【メリット】
  • 組織を横断している組織なので、全社を横断した網羅的な仕組み化が可能となる
  • JC-STARのような認証取得が必要なケースなどに対応しやすい
• 【デメリット】
  • 品質管理特有の重厚なプロセスが製品開発スピードを遅らせる可能性がある

5．情報システム部門

• 【特徴】
  • 社内のIT基盤全体やシステムの管理／運用の経験が多い
• 【メリット】
  • 全社的なIT基盤の構築／運用に強い
  • SBOM管理ツールやセキュリティソフトなどの選定／導入／運用にも強い
• 【デメリット】
  • 同じソフトウェアでも、製品への組み込みソフトは範囲外の場合が多い
  • 設計開発部門の設計意図や製造部門特有の制約などを理解しにくい

　ここに示したように、1〜5のどこの組織がSBOM構築や運用／管理の主管となっても、一長一短という状況になる可能性は否定できない。その理由は、現状の製造業の組織にとって「自社製品へのサイバー攻撃対策」というのは想定外の事象だからだ。各部門が事前に情報連携した上で緊急時の対応を迅速に行えるように、5つの組織を結ぶ連携の枠組みというこれまで想定していなかったものを作らなければならない。

　それは、一般にPSIRT（Product Security Incident Response Team）と呼ばれる組織が最も近いだろう。この組織があれば、緊急事態の対応を担うことができるので、もし自社にないのであれば、PSIRTを作ることが近道となる。このPSIRTを中心として、各組織の位置付けや考え方と一緒にSBOMの構築と運用／管理をどうすればいいかを検討する――というのが筆者の基本方針だ。

　「なぜ、PSIRTなのか？」。その答えは非常にシンプルだ。PSIRTが製品へのサイバー攻撃を受けた際の非常事態に対応するための組織だからだ。サイバー攻撃による非常事態が発生することを前提とするからこそ、SBOMのような事前準備が必要となる。

　例えば、SBOMを導入する主な目的である脆弱性への対応については、検出される脆弱性自体は月に数百〜数千件あるということが明らかになっている。非常事態になり得るようなクリティカルな脆弱性はそれほど多くないものの、膨大にある脆弱性の内容を把握し、最適な対応を選択しなければならない。いつ非常事態になるとも限らないからこそ、「SBOM導入は、PSIRTによる緊急事態への対応とセットで考えた方がいい」のだ。

　なお、ここでは分かりやすくPSIRTとしたが、CSIRTが既にある場合はそれがPSIRT機能も包含する形式でも構わない。その場合、貴重なセキュリティリソースを集中させることが可能というメリットがある。

「SBOM」は、誰が構築し運用／管理すべきか（法規制対応を優先する場合）

　最後に、本記事の主題でもある「SBOM」は誰が構築し運用／管理すべきか、という課題への筆者なりの回答を述べたい。まず、SBOMを導入する理由として、「出荷後の脆弱性監視」と「法規制への証跡管理」の2つが挙げられる。

　ただし、その企業の製品が欧州へ輸出されていてCRA対応が必要な場合、1500万ユーロ（日本円で約28億円）かそれ以上かかる重い罰則規定の対象とならないように法規制への対応を優先することが、「経営リスクマネジメントの観点から合理的」だといえる。

　そうした場合、スキームを単独の部門の課題ではなく「全社的な枠組み」で解決できるように構築することが重要だ。なぜなら、その部門の範囲内で解決できない課題に対応できなくなるからだ。筆者はSBOMの運用／管理を含むセキュリティ対応を「品質管理部門」を主管部門にしつつ、リスク管理部門が法務的な支援を行う体制が理想的だと考えている。

　この場合、先述した現場からの距離感や重厚なプロセスがスピード感を阻害する可能性があるが、「SBOMが正しく管理／運用されているプロセス」の証明が必要なことから、法規制対応を優先する場合は、上記の組織体制が有効だと考える。

法規制対応が済んだら、脆弱性対応の向上を目指す

　ここで、まず法規制をクリアするためのフレームワークができた。そうなれば、次の段階を目指したい。具体策としては、実務的なミス（脆弱性の見落としなど）を防ぐフェーズに移行する。

　この段階では、実務や製品に組み込まれたソフトウェアに最も詳しい「設計開発部門が主役」となる。基本方針としては、抜け漏れを防止するため人手による作業をできるだけ避けられる状況を目指したい。脆弱性動向の監視やマッチング作業の標準化／自動化がある程度できるようになれば、最終的なゴールとまでは行かないものの順調に階段を上っていると考えていいだろう。

　例としては、SBOM管理などを駆使して、自動的に出力されるアラートや生成AIと連動した機能で出力される対応方針のガイダンスを見ながら行動するような仕組みが有効だろう。この機能は、未リリースのプロトタイプながら、SBOM管理ツールで実装予定の機能として見たことがあり、さまざまなプロダクトやツールにAI機能が実装されている昨今の状況から、近いうちに業界標準になると思われる。

　進め方の成功の鍵は、「リスク管理部門」が、CRAの制裁金（最大1500万ユーロなど）の大きさを社内へ周知し、「SBOM対応はコストではなく、事業継続のための必須要素だ」という認識を共通認識とすること。これを経営層はもちろん現場まで浸透させ、利害が異なる各部門間での綱引きをさせないことが重要だ。

　筆者の知る限り、製造業の設計開発や製造の部門は新しい機能を生み出すことが非常に好きなことから、それらに制約を課すセキュリティについては、後ろ向きであることが多い。これはITとセキュリティという分野でも同じ図式がしばしば見られるため、ある程度仕方のないことなのかもしれない。

　しかし、世界的な世論としてそうは言っていられない状況になっている。既に対応が後手になっていることを自認し、CRA対応も社内の状況を優先して「2026年9月のインシデント報告義務」はスルーして、「2027年12月の全面適用」をターゲットとするという方針の企業も見られる。

　ただし、一般的に考えてCRAの義務違反のリスクを許容することは、非常に難しいだろう。そのような企業の違反が、もしもEUに指摘されて罰則が適用されるような場合、日本の製造業はパニックに近い状況に陥るかもしれない。

　そもそも、時間がないと言っても、まだ半年ほどの時間は残っている。間に合う可能性があるなら、経営リスクを無為に拡大させるような状況は避けた方が良いだろう。なぜなら、先述のようなCRA違反のニュースによって、業界全体がパニックになることもあり得るからだ。そうなると、さらに悪い環境下で拙速な対応をしなくてはならなくなる。

　そうなる前に、一刻も早く全社の仕組みとして「自社製品がセキュアであることを証明できる」ようになることが重要だ。これが、現在のデジタル製品の製造元として世界の市場から求められている本質であるからだ。

著者プロフィール

武田一城（たけだ かずしろ）　株式会社ベリサーブ

1974年千葉県生まれ。セキュリティ分野のマーケティングスペシャリスト。次世代ファイアウォールをはじめ、さまざまな新規事業の立ち上げに従事。セキュリティに限らず、IT全般の動向にも詳しく、インターネットや書籍の執筆実績が多数あり。NPO法人日本PostgreSQLユーザ会理事。日本ネットワークセキュリティ協会（JNSA）のワーキンググループや情報処理推進機構（IPA）の委員会活動、各種シンポジウムや研究会、勉強会での講演をはじめ製品セキュリティの啓発に向け精力的に活動している。