サイバーレジリエンスの製品実装とSBOM: 装置に組み込むレジリエンス設計とサプライチェーン管理

1. CIRCIAの報告項目を「逆算」する報告書が製品設計を規定する

CIRCIAは報告義務を規定する法律ですが、その報告内容を仔細に見ると、製品設計に対する要求が浮かび上がってきます。報告書に求められる情報は、単なる「被害報告」ではありません。マルウェア（悪意のあるソフトウェア）への対応情報や、回復のための手がかりを含む、詳細な技術情報です。

具体的には、以下の項目が求められます。

• 脆弱性と防御策:
  どこに弱点があり、どんな防御策が導入されていたか
• ソフトウェアのバージョン:
  製品に使われているソフトウェアの正確な構成情報
• セキュリティ管理の枠組み:
  どのようなセキュリティ管理体制が敷かれていたか
• 侵害の兆候（IoC）:
  攻撃の痕跡を示す技術的な証拠

これを「逆算」すると、製品が平時から記録・管理しておくべき情報が明確になります。ソフトウェアの構成を報告するにはSBOM（部品表）が必要です。しかも、脆弱性を特定するにはSBOMに基づく常時監視が必要。侵害の兆候を記述するには、改ざんされないログが必要です。

さらに重要なのは、この報告が産業界全体にフィードバックされるという点です。CISAは報告された情報をもとに、MITRE ATT&CK（攻撃事例の手法に基づいたデータベース）の更新やマルウェア管理情報の改訂を行い、産業界全体の防御力向上に還元しています。正確な報告は「義務」であると同時に、自社を含む業界全体の安全を高める「投資」でもあるのです。

2. SBOM（ソフトウェア部品表）の実務「うちの製品に何が入っているか」を把握する

2.1 SBOMとは何か——製造業の「部品表」のソフトウェア版

SBOM（Software Bill of Materials）は、製品に含まれるソフトウェア部品の一覧表です。

製造業の皆様は、ハードウェアのBOM（部品表）には馴染みが深いでしょう。ある装置に使われているボルト、基板、モーターの型番と数量、そしてサプライヤーの情報がBOMに記載されています。SBOMはその「ソフトウェア版」です。装置に搭載されているOS、ミドルウェア、ライブラリ、オープンソースコンポーネントのすべてを、名称・バージョン・供給元・依存関係（どの部品の中にどの部品が入っているか）を一覧化したものです。

なぜ今、SBOMがこれほど求められるのか。背景にあるのは、サプライチェーン攻撃の深刻化です。2020年のSolarWinds事件や2021年のLog4Shell脆弱性は、自社が直接開発したコードではなく、サプライチェーンの奥深くに埋め込まれたサードパーティ部品の欠陥が攻撃の起点でした。SBOMがなければ、「自社の製品にその部品が含まれているか」すら回答できません。

これは、ハードウェアのリコール対応と同じ構造です。もしBOMがなければ、「このロットのベアリングに欠陥があった」と判明しても、「どの装置に使われているか」を特定できません。さらに現在、欧州のサイバーレジリエンス法（CRA）などの規制により、SBOMの提供は「製品を市場に出すためのパスポート（必須条件）」へと変わりつつあります。SBOMは、ソフトウェアの世界でこの「トレーサビリティ（追跡可能性）」を確保し、有事の際の対応スピードを劇的に高めるための経営基盤なのです。

2.2 SBOMの粒度: 最小・推奨・詳細の三段階

SBOMにも「どこまで詳しく記載するか」という粒度の設計が必要です。NTIA（米国電気通信情報管理局）が定めた最小要素を基本に、各規制が求める水準を踏まえると、以下の三段階で整理できます。

表1: SBOMの粒度レベルと各規制の要求水準

ここで注目すべきは粒度の選択基準です。CIRCIA法自体はSBOMの形式や粒度を細かく規定していませんが、Section 2242(c)(4)(B)が求める「悪用された脆弱性と導入されていた防御策、攻撃に使われた戦術・技術・手順（TTP）」を正確に報告するためには、製品の構成情報を詳細に把握しておくことが実務上不可欠です。ハッシュ値（デジタル指紋）は、ソフトウェア部品が改ざんされていないことを暗号学的に証明するもので、製造業で言えば部品ロットごとに付与されるシリアル番号と品質証明書に相当します。インシデント発生時に「この部品は正規品か、改ざんされていないか」を即座に確認するための基盤となります。

2.3 VEX: SBOMの「ノイズ」を制御し、本当に危険な脆弱性に集中する

SBOMを導入した現場が最初にぶつかる壁があります。脆弱性スキャナ（ソフトウェア部品の欠陥を自動検出するツール）がSBOMに基づいて検査を行うと、数百件もの脆弱性がリストアップされることは珍しくありません。

しかし、そのすべてが自社製品において直ちに危険なわけではないのです。

たとえば、製品に搭載しているOpenSSL（暗号化ライブラリ）のバージョンに既知の脆弱性が見つかったとします。しかし、自社製品ではそのOpenSSLの中の該当機能をまったく使っていない場合、その脆弱性は「存在はするが、悪用のしようがない」状態です。これは、装置に取り付けられている非常停止ボタンのカバーにわずかな傷があるようなもので、機能上の問題はありません。

ところが、SBOMだけではこの「危険かどうか」の判断ができません。部品表には「何が入っているか」は書いてあっても、「その欠陥がこの製品で実際に悪用できるか」までは書いていないからです。

この問題を解決するのが VEX（Vulnerability Exploitability eXchange: 脆弱性悪用可能性交換情報）です。

VEXは、特定の脆弱性が自社製品に対して以下の4つのうちどの状態にあるかを宣言する文書です。

• 影響あり（Affected）:
  対処が必要
• 影響なし（Not Affected）:
  この製品では悪用できない
• 調査中（Under Investigation）:
  現在確認中
• 修正済み（Fixed）:
  パッチ適用済み

VEXによって「影響なし」と宣言できれば、顧客や規制当局に対する不要な報告や対応——いわば「誤報」——を大幅に削減でき、真に対処すべき脆弱性にリソースを集中できます。

実務上、SBOMとVEXはセットで運用することが大前提です。SBOMが「製品の部品表」であるなら、VEXは「その部品表に紐づく脆弱性の影響度評価書」です。CIRCIAの報告で「脆弱性と防御策」を72時間以内に報告する際、VEXが平時から整備されていれば、対応速度は格段に上がります。

2.4 SBOMの更新フローと優先順位の付け方

SBOMは「一度作って終わり」ではありません。ソフトウェアのリリースや部品の更新ごとにSBOMを更新し、新たに公開される脆弱性との突合を継続的に行う必要があります。これは、ハードウェアのBOMを設計変更のたびに更新し、リコール情報と照合するのと同じ考え方です。

実務上の更新フローは、以下のサイクルで運用します。

1. ビルド時の自動生成:
   ソフトウェアの構築（ビルド）工程にSBOM生成ツールを組み込み、ビルドごとにSBOMを自動で作成する。手作業での管理は人的ミスと遅延の原因になります。
2. 脆弱性データベースとの自動照合:
   生成されたSBOMを、NVD（米国の脆弱性データベース）やCISAのKEV（悪用が確認された脆弱性カタログ）と自動で照合する。新たな脆弱性が検出された場合、VEXのステータス判定フローに入ります。
3. 優先順位の判定:
   検出された脆弱性を、深刻度スコア（CVSS）だけで判断するのではなく、「実際に悪用されているか」（KEVカタログの該当有無）、「自社製品での悪用可能性」（VEX評価）を加味して、実際のリスクに基づいた優先順位を付けます。
4. パッチ適用とSBOM再生成:
   修正パッチの適用後、SBOMを再生成し、VEXステータスを「修正済み」に更新します。

3. サプライヤー管理契約の押さえどころと受領運用

自社製品のレジリエンス（回復力）は、組み込まれているサードパーティ製部品の品質に依存します。ハードウェアの品質管理で「受入検査」を行うように、ソフトウェア部品にも受入検査と継続的な品質管理が必要です。

3.1 契約に盛り込むべき条項

サプライヤーとの契約では、最低限以下の3点を押さえます。

• SBOM提供義務:
  納入するソフトウェアのSBOMを、初回納入時および更新時に提供すること。フォーマットはSPDXまたはCycloneDX形式（いずれも国際的に広く使われている標準形式）を指定します。
• 脆弱性通知義務:
  サプライヤーが自社部品に影響する脆弱性を認知した場合、合意した期間内（例: 72時間以内）に通知すること。通知には、影響を受けるバージョン、脆弱性のID（CVE番号）、推奨される対応策を含めること。
• 導入前検査への協力:
  装置メーカーが受領した部品に対して脆弱性スキャンやセキュリティテストを実施する場合、必要な技術情報の提供に協力すること。

3.2 IEC 62443-4-1における根拠

これらの契約要件は、国際規格IEC 62443-4-1が求める要件と整合しています。

ここで正確に押さえておきたいのは、IEC 62443-4-1:2018におけるSBOM関連要件の所在です。Practice 8（Security Guidelines: セキュリティガイドライン）は、製品のセキュリティに関するユーザー向けドキュメント（堅牢化ガイド、安全な運用手順など）の提供を規定するものであり、「SBOM」という用語はPractice 8には明記されていません。

SBOMの実質的な根拠となるのは、以下の二つの要件です。

• SM-9（Practice 1: セキュリティ管理）:
  製品に含まれるすべての外部提供部品（サードパーティソフトウェア、オープンソースソフトウェア等）のセキュリティリスクを特定し、管理するプロセスの採用を求めています。これは、開発者が内部的にSBOMに相当する部品リストを構築・維持し、その脆弱性を追跡・管理する義務を意味します。
• SUM-3（Practice 7: セキュリティアップデート管理）:
  依存関係にある部品のセキュリティアップデートに関するドキュメントの提供を求めています。

2018年に発行されたIEC 62443-4-1に「SBOM」という単語がないのは、SBOMという枠組みがサイバーセキュリティ規制の文脈で世界的に広まったのが規格発行後の近年であるためです。現在の実務では、SM-9の要件を満たしつつユーザーに適切な脆弱性情報を提供するためのベストプラクティスとして、SBOMフォーマットが活用されています。

4. 製品実装装置・機器レベルのレジリエンス設計

ここからは、装置・機器の具体的な設計要件に踏み込みます。第4回で解説した「72時間以内の報告」と「正確なエビデンスの提出」を支える技術基盤を、一つずつ解説します。

4.1 安全なアップデート: 「修理中に壊さない」仕組み

脆弱性が発見された際に、修正パッチ（修正プログラム）を安全かつ迅速に適用できることは、レジリエンスの根幹です。しかし、製造現場の装置では「アップデート中に装置が止まる」「アップデートに失敗して起動しなくなる」ことは許容できません。

ここで採用される設計パターンがA/Bパーティション方式です。装置のストレージ（記憶領域）を二つの区画に分け、一方で稼働を続けながら、もう一方に新しいソフトウェアを書き込みます。書き込みが完了してから切り替えることで、アップデート中のダウンタイム（停止時間）を最小化できます。途中で電源が落ちても、稼働中の区画は影響を受けません。

さらに重要なのがロールバック（巻き戻し）機能です。アップデート後に動作異常が検出された場合、前のバージョンに自動的に戻る仕組みです。これは、製造ラインの「変更管理」と同じ発想です。新しい治具を導入して不良が出たら、すぐに元の治具に戻せる体制を確保しておくのと同じです。

アップデートパッケージには必ず暗号署名（デジタルの「封印」）を付与し、装置側でその署名を検証してから適用します。これにより、悪意のある偽のソフトウェアが注入されることを防ぎます。

4.2 ファームウェア署名と鍵管理: 「偽物を排除する」仕組み

ファームウェア署名は、装置にインストールされるソフトウェアが「正規品」であることを暗号学的に保証する仕組みです。製造業で言えば、正規部品にのみ付与される「真贋証明書」のデジタル版です。

セキュリティブートチェーンの設計では、装置の起動プロセスの各段階で「次の段階のソフトウェアが本物か」を検証します。ハードウェアの「信頼の起点」→ ブートローダー（起動プログラム）→ OS → アプリケーションという連鎖で、各段階の真正性を保証します。一段でも検証に失敗すれば、起動を停止します。

署名に使う暗号鍵の管理には、専用のハードウェアを使うことが望ましいです。

表2: ファームウェア署名と鍵管理の実装パターン

ここで絶対に避けるべきは、署名鍵をソフトウェアの中に平文（暗号化されていない状態）で保管することです。これは、金庫の暗証番号を金庫の扉に貼り付けているようなものです。

4.3 デバイスID／プロビジョニング: 「この装置は本物か」を証明する仕組み

工場出荷時に、各装置に一意のID（識別子）と暗号証明書を安全に書き込む「プロビジョニング」は、装置の身元を保証する基盤です。

ネットワークに接続しようとする装置が「本物か」を確認するために、X.509証明書（インターネットの世界で広く使われているデジタル身分証明書の規格）を用います。各装置に固有の秘密鍵と証明書をTPM内に格納し、ネットワーク接続時に相互認証を行います。

これは、工場への入構管理と同じ発想です。正規のIDカードを持った作業者だけが入構でき、偽造IDでは入れない仕組み。装置のネットワークでも同じことを行い、なりすまし装置の接続を防止します。

4.4 ログの設計: 「改ざんされない記録」を残す

第4回で解説したCIRCIA報告の根幹は、「何が起きたか」を技術的に証明できるログ（記録）です。しかし、攻撃者は自らの足跡を消すためにログを削除・改ざんしようとします。したがって、ログの「記録」だけでなく「保護」と「転送」まで含めた設計が必要です。

記録すべき項目（IEC 62443-4-2 CR 2.8、CR 2.9、CR 2.11に基づく）

認証の成功・失敗、アクセス制御イベント、設定変更（ファームウェア更新を含む）、通信エラーおよび不正な要求、システムの起動・停止。各イベントには、タイムスタンプ（時刻の記録）、発生元の装置ID、イベントの種類、結果（成功/失敗）を含みます。

保護の設計

ログの改ざんを防ぐ方法は大きく二つ。一つはWORM（Write Once Read Many: 一度書いたら書き換えられない）領域にログを保存する方法。もう一つは、ログをリアルタイムで外部のセキュアなサーバーへ転送する方法です。実務上は両方を併用します。ローカルのWORM領域はネットワーク断時のバッファとして機能し、ログの消失を防ぎます。

時刻同期

複数の装置にまたがる攻撃の全容を解明するには、すべてのログの時刻が正確に一致している必要があります。装置が独自に時刻を保持するのではなく、NTP（ネットワーク時刻同期プロトコル）で共通の時計に合わせる機能は必須です。この機能が無ければスピーディーな対応は困難となります。これは、工場内の全ての計測器の校正を統一することと同じ考え方です。

転送の設計

OT（制御系）環境では、セキュリティゾーニング（ネットワークの区画分け）の制約があります。ログの転送先はDMZ（非武装地帯: 外部と内部の緩衝地帯）に配置したログ集約サーバーとし、制御ネットワークから直接インターネットには出さない設計とします。

4.5 リソース制約機器への対応: 「小さな装置」はどうするか

すべての装置が前述の機能をフル搭載できるわけではありません。PLC（プログラマブルロジックコントローラ）、センサー、レガシー機器など、処理能力やメモリに制約がある機器では、セキュリティブートやログの暗号化転送を機器自体に実装することが困難な場合があります。

この場合の現実的な解決策がセキュリティゲートウェイ（関所）アプローチです。

リソース制約機器の直近に、セキュリティ機能を集約したゲートウェイ装置を配置します。このゲートウェイが、配下の機器のログ収集・暗号化転送、ファームウェアアップデートの検証・配信、ネットワーク通信の監視・フィルタリングを代行します。

これは、製造ラインの「検査工程の集約」と似た発想です。各工程に検査装置を置く代わりに、ラインの要所に検査ステーションを設け、複数工程の検査を集約する方法です。

IEC 62443-4-2は、機器自体がセキュリティ要件を満たせない場合、「補償的なセキュリティ対策」によってシステムレベルでの要件充足を認めています。ゲートウェイアプローチは、この補償的対策の代表的な実装パターンです。

ただし、ゲートウェイ自体は高いセキュリティ要件を満たす必要があります。関所が突破されれば、その先のすべてが危険にさらされるからです。

表3: リソース制約機器における設計要件の実装方式比較

5. IEC 62443が「すべての土台」である理由規格と規制の統合的関係

ここまで解説した設計要件は、CIRCIAが独自に生み出したものではありません。CIRCIAやEO 14028が製品に求める内容は、IEC 62443の技術要件とNIST Cybersecurity Framework（CSF）の管理策をベースに、「法規制として何を義務化すべきか」を検討した結果です。

この関係を正しく理解しておくことは、個別の規制にバラバラに対応する非効率を避けるために極めて重要です。

表4: 設計要件と各規制・規格のマッピング

ここで、表4の「脆弱性管理」の行に記載したPractice 6（Security Defect Management: セキュリティ欠陥管理）について補足します。

Practice 6は、脆弱性の発見 → 影響度の評価 → 修正パッチの開発・配布 → 顧客への開示——というサイクル全体を規定するPracticeです。本稿で解説したSBOMとVEXの運用プロセスは、このPractice 6が求めるサイクルを実務に落とし込んだものに他なりません。

整理すると、SM-9（Practice 1）がSBOMの「構築」を、Practice 6がSBOMに基づく「脆弱性対応プロセス」を、SUM-3（Practice 7）が「アップデートの配布と文書化」を、それぞれ規定しています。これら三つのPracticeが一体として機能することで、CIRCIAやCRAが求める「脆弱性情報の迅速な報告と修正」が実現されます。

つまり、IEC 62443-4-1に準拠した開発プロセスを構築していれば、自ずとCIRCIAや欧州CRAが求める「SBOMの構築・維持・提供」と「脆弱性の管理・開示」を満たすことができるのです。規格ごとに個別対応するのではなく、IEC 62443をコアに据えた統合的アプローチこそが、開発現場の負荷を軽減する最適解です。

重要なのは、IEC 62443が「技術的にどう実装すべきか」を規定し、NISTフレームワークが「組織としてどう管理すべきか」を規定し、CIRCIAやCRAが「法的に何を義務化するか」を規定しているという三層構造です。第3回で解説した「IEC 62443を共通言語とする」アプローチは、この構造を理解した上で、製品設計という最も具体的なレイヤーで実践することに他なりません。

なお、IEC 62443-4-1は2018年版に基づいていますが、SBOMという用語が世界的に普及する以前に策定された規格であるため、SM-9やSUM-3の要件をSBOMフォーマットで実装するのが現在のベストプラクティスです。規格の文言にSBOMが明記されていないことと、実務上SBOMが不可欠であることは矛盾しません。

6. 実務チェックリスト装置メーカーが今すぐ始めるべき5つのアクション

最後に、本稿の内容を踏まえ、装置メーカーが優先的に取り組むべきアクションを整理します。

表5: 製品レジリエンス設計の実務チェックリスト

まとめと次回の展望

本稿では、CIRCIAの報告要求を「製品設計への逆算」として読み解き、SBOMとVEXを核としたサプライチェーン管理、そして装置レベルのレジリエンス設計を具体的に解説しました。

ここまでの連載で、規制の全体像（第1〜2回）、IEC 62443という共通言語（第3回）、インシデント報告の実務（第4回）、そして報告を支える製品設計（本稿）と、一気通貫で整理してきました。

さて、これらの一般的な技術要件を踏まえた上で、開発現場が次に直面するのは「業界ごとの固有ルール」です。IEC 62443という「共通言語」は理解した。では、自社が属する業界では、具体的にどこまで何を求められるのか？

次回の第6回では、半導体製造装置におけるデファクトスタンダードとなりつつあるSEMI E187 / E188に焦点を当てます。TSMCが調達要件に組み込んだことで急速に「必須化」が進むこの規格が、IEC 62443の要件とどう対応し、装置メーカーの出荷プロセスをどう変えるのかを解説します。本稿で解説した設計要件が、半導体という具体的な業界でどう「翻訳」されるか——その実例をお示しします。

ICS研究所からのご案内

自社製品のレジリエンス設計や、SBOM/VEX運用のプロセス構築に課題をお持ちの企業様は、ぜひICS研究所にご相談ください。

IEC 62443に基づいた製品セキュリティ体制（PSIRT）の構築支援、SBOM管理・脆弱性管理の実務導入コンサルティング、そして人材教育のためのeラーニングプログラム「eICS」を通じて、貴社の製品がグローバル市場で「選ばれる装置」となるための包括的なサポートを行います。