IoTセキュリティ SBOMスキャナ

2026.09.29

IoT機器メーカーが直面する脆弱性管理の実務～CVE対応から報告までのフロー～

By 富樫葵

IoT機器メーカーにおける脆弱性管理とは、自社製品に影響する脆弱性情報(CVE等)を継続的に監視し、深刻度を判断したうえで対応・報告までを一連の業務として運用する仕組みを指します。
IoT機器は出荷後も長期間稼働するため、影響有無を確認し、必要に応じて修正・通知・報告まで対応することが求められます。

【結論】

CVE対応は「収集→影響特定→優先順位付け→対応」という4ステップで仕組み化できる
CVSSスコアとSBOM(部品構成表)を組み合わせると、影響製品の特定とトリアージを効率化しやすくなる
報告は社内、顧客・取引先への報告に加え、必要に応じて外部機関・規制当局への届出・法定報告を行えるよう整理しておく
CRAやJC-STARなどでは、脆弱性対応プロセスの整備・文書化が求められている

本記事では、IoT機器メーカーが脆弱性管理を実務としてどう回すか、CVE対応の具体的な手順から報告フローの整備方法までを解説します。

IoT機器メーカーに脆弱性管理の実務フローが必要なのはなぜか？
1. なぜ今、IoT機器メーカーに脆弱性管理が求められるのか？
2. 脆弱性管理とCVE対応はどう違うのか？
CVE対応の実務フローはどう組み立てるのか？
脆弱性対応の結果を誰に・どう報告すべきか？
脆弱性管理を仕組み化するにはどうすればよいか？
CRA・JC-STARは脆弱性管理にどう関わるのか？
よくある質問
まとめ
IoT機器メーカーの脆弱性管理を検討中の方へ

1. IoT機器メーカーに脆弱性管理の実務フローが必要なのはなぜか？

IoT機器メーカーに脆弱性管理の実務フローが必要な理由は、出荷後も長期間稼働する機器が多く、新たな脆弱性が発見され続けるためです。

加えて、脆弱性対応プロセスの整備を求める規制・適合性評価・ラベリング制度が広がり始めています。

1.1. なぜ今、IoT機器メーカーに脆弱性管理が求められるのか？

背景として、次の3点が挙げられます。

出荷後5年、10年と長期間稼働する機器が多く、組み込んだソフトウェア部品の脆弱性が後から見つかるケースが多い
サプライチェーンを経由した攻撃が増えており、自社製品が組み込んでいるOSS(オープンソースソフトウェア)の脆弱性が侵入の起点になる場合がある
サイバーレジリエンス法(CRA)やJC-STARなど、脆弱性対応プロセスを求める規制・適合性評価・ラベリング制度が広がっている

特にIoT機器は、PCやサーバーのように利用者側で定期的にOSアップデートが行われるとは限らず、メーカー側からの働きかけがなければ脆弱性が放置されやすい機器でもあります。

だからこそ、発見から報告までを属人的な対応に頼らず、仕組みとして継続できる状態にしておくことが重要になります。

1.2. 脆弱性管理とCVE対応はどう違うのか？

CVE対応とは、公表された個別の脆弱性1件ごとに自社製品への影響有無を確認し対処する「点」の作業です。
脆弱性管理とは、CVE対応を継続的に回すための体制・ルール・ツールを含めた「仕組み」全体を指します。
CVE対応だけを場当たり的に行っていると、対応漏れや報告の遅れが生じやすくなります。

ここで、CVEとCVSSについて補足します。

CVE(Common Vulnerabilities and Exposures)とは、製品やベンダーを横断して脆弱性を識別できるよう、個々の脆弱性に世界共通の識別番号(CVE ID)を割り当てる仕組みです。

CVE IDの採番は、CVEプログラムの運営を担うMITREや、CVEプログラムから認定されたCNA(CVE採番機関)と呼ばれる世界中の500以上の組織が分担して行っています。
（出典：CVE.org「CNA登録数に関するニュース(2026年6月2日時点で519のCNAが参加)」）

CVSS(Common Vulnerability Scoring System)とは、脆弱性の深刻度を共通の評価基準に基づいて数値化する仕組みです。

CVSSスコアはCVEプログラム自体が一律に算出するものではなく、NVD(米国NISTが運営する脆弱性情報データベース)やIPA、製品ベンダーなどが、それぞれ評価・公表する場合があります。

国内のJVN iPediaでは、IPAが算出した評価値やNVDが公表した評価値を確認できます。
同じCVEでも、評価主体やCVSSのバージョンによってスコアが異なる場合がある点には注意が必要です。

次章では、CVE対応を仕組みとして回すための実務フローを整理します。

2. CVE対応の実務フローはどう組み立てるのか？

CVE対応は、脆弱性情報の収集、自社製品への影響特定、CVSSによる優先順位付け、パッチ適用・回避策の実施という4つのステップで組み立てます。

2.1. ステップ1：脆弱性情報をどう収集するか？

脆弱性情報の収集元としては、NVD(米国NISTが運営する脆弱性データベース)、JVN iPedia(IPAが運営する脆弱性対策情報データベース)、JVN(IPAとJPCERT/CCが共同運営する脆弱性対策情報ポータル)、利用しているOSSやチップベンダーが発行するセキュリティアドバイザリなどがあります。

CVE番号が付与された情報源に加え、次のような経路からも脆弱性関連情報が寄せられます。

セキュリティ研究者からの報告
顧客、販売店、保守会社からの申告
開発部門による自己発見
脅威インテリジェンス
ペネトレーションテスト、ファジング、脆弱性診断
CERT、業界団体、規制当局からの通知

担当者が都度サイトを巡回して確認する方法では見落としが生じやすいため、メール通知やRSS、脆弱性管理ツールを使って自動的に情報が届く仕組みを整えておくことが望まれます。

2.2. ステップ2：自社製品への影響をどう特定するか？

新しいCVEが公表された際に最も時間がかかるのが、自社製品への影響有無の特定です。

あらかじめSBOM(ソフトウェア部品構成表)で使用コンポーネントとバージョンを一覧化しておけば、CVE公表時に該当バージョンが自社製品に含まれるかどうかを照合しやすくなります。

SBOMが整備されていない場合、開発者への聞き取りや設計書の確認に時間がかかり、対応の初動が遅れる原因になります。

SBOMは影響調査の初動を大幅に効率化できますが、SBOM上の製品名やバージョンの一致だけで影響の有無を確定できるとは限りません。

バックポート、独自修正、静的リンク、ビルドオプション、実行時設定、脆弱な機能の到達可能性などを追加確認する必要があります。
必要に応じて、VEXや製品ベンダーのアドバイザリも参照します。

2.3. ステップ3：CVSSで優先順位付け(トリアージ)をどう行うか？

CVSS(Common Vulnerability Scoring System)とは、脆弱性の深刻度を0.0から10.0までの数値で表す共通の評価指標です。

公表される脆弱性は年間で膨大な件数にのぼるため、すべてに同じ優先度で対応することは現実的ではありません。

CVSSスコアを対応順位の判断材料の一つとして使うことで、限られた人員でも一定の基準でトリアージしやすくなります。

CVSS v3.xの深刻度区分の目安は、次のとおりです。

深刻度	スコア範囲	対応目安
Critical(緊急)	9.0～10.0	最優先で緊急対応を検討する
High(重要)	7.0～8.9	早期に対応計画を確定する
Medium(警告)	4.0～6.9	定期メンテナンスに組み込んで対応する
Low(注意)	0.1～3.9	影響範囲を確認のうえ計画的に対応する
None(なし)	0.0	CVSS上の深刻度なし(対応要否は個別判断)

Critical、High、Medium、Lowの区分とスコア範囲は、FIRSTが管理するCVSS仕様で定義されています。
NVDはCVSSを用いた脆弱性評価情報を提供しています。

本記事では主にCVSS v3.xの区分を基準としていますが、2023年に公開されたCVSS v4.0でも同じ区分・スコア範囲が採用されています。

一方、表右列の「対応目安」はNVD公式のルールではなく、一般的な運用例として示したものです。
（出典：NVD「Common Vulnerability Scoring System」）
（出典：FIRST「Common Vulnerability Scoring System (CVSS)」）
（出典：FIRST「CVSS v4.0 Specification」）

CVSSは脆弱性の技術的な深刻度を表す指標であり、組織や製品固有のリスクそのものを表すものではありません。

実際の対応優先度は、CVSSに加えて、悪用状況、インターネットからの到達性、製品の設置台数、顧客への影響、安全性への影響、回避策、更新の難しさなどを考慮して判断します。

CVSSの基本的な仕組みについては、以下の記事もあわせてご覧ください。

CVSSについて解説した記事はこちら

2.4. ステップ4：パッチ適用・回避策の実施はどう進めるか？

対応には、修正版の提供、設定変更、通信制限、該当機能の停止、認証強化、交換、リコールなどが含まれます。

パッチが提供されている場合は、動作確認やリグレッションテストによって更新の安全性と適用後の動作を検証し、速やかに適用します。

パッチがまだ提供されていない脆弱性では、通信経路の制限や該当機能の一時停止といった回避策を検討します。
特に、修正策がない段階で悪用されるゼロデイ脆弱性では、迅速な暫定対策が重要です。

IoT機器の場合、現地に設置された機器への配信手段によって対応スピードが大きく変わるため、OTA(Over-The-Air)更新の仕組みは開発段階から次のような点を検討しておくことが望まれます。

更新パッケージの電子署名検証
署名鍵の保護、ローテーション、失効
ダウングレード防止
更新途中の電源断からの復旧
段階配信とロールバック
オフライン機器への更新手段
更新後のバージョン確認

3. 脆弱性対応の結果を誰に・どう報告すべきか？

報告は、社内、顧客・取引先への報告に加え、必要に応じて外部機関・規制当局への届出・法定報告を行うことを想定し、宛先ごとに報告内容の粒度を整理しておくことが重要です。

報告先	主なタイミング	報告内容の目安
経営層・社内	深刻度が高いと判明した時点	影響範囲、対応スケジュール、リスクの概要
顧客・取引先	契約・SLAに基づくタイミング	CVE番号、影響製品・バージョン、対応状況
外部への届出・法定報告	公表調整が必要な場合や、法令上の報告要件に該当する場合	脆弱性の詳細、影響製品、対策状況など

外部への届出・法定報告は一つの制度に限られません。
国内ではIPA・JPCERT/CCの届出制度、CRA対象製品ではCRAに基づく報告など、適用される制度に応じて対応します。

3.1. 社内報告で押さえるべきポイントは何か？

経営層への報告では、技術的な詳細よりも、事業への影響範囲と対応スケジュール、必要な意思決定事項を簡潔にまとめることが求められます。

一方、開発・品質保証部門への報告では、対象コンポーネントやバージョン、再現条件など技術的な詳細が必要になります。

同じ内容を粒度の異なる読み手に一律で共有すると、経営層には情報が多すぎ、現場には情報が不足するというミスマッチが起きやすい点に注意が必要です。

3.2. 顧客・取引先への報告はどこまで必要か？

顧客・取引先への報告範囲は、契約書やSLA(サービス品質保証)に定められた通知義務の有無によって異なります。

報告する場合は、CVE番号、影響を受ける製品・バージョン、想定される影響、対応スケジュールをセットで明記すると、顧客側の判断がしやすくなります。

契約上の定めがない場合でも、深刻度の高い脆弱性については、信頼関係の維持という観点から自主的な情報提供を検討する企業もあります。

3.3. IPA・JPCERT/CCへの届出は必要か？

IPA・JPCERT/CCは、メーカーが検知・対応したすべてのCVEについて日常的に報告する相手ではありません。

ただし、自社製品に脆弱性を発見した場合や、外部の研究者などから指摘を受け公表タイミングの調整が必要な場合には、IPAが届出を受け付け、JPCERT/CCが製品開発者との調整を行う脆弱性関連情報の届出制度を利用できます。

この制度は、経済産業省告示に基づき指定された業務として運営されています。
JPCERT/CCが製品開発者と公表日を調整し、対策情報がJVN(Japan Vulnerability Notes)に公表されて一般に周知されます。

法令上ただちに義務付けられるものではありませんが、脆弱性の公表タイミングを関係者間で調整できる点は、自社だけで抱え込むより有効な選択肢になり得ます。

ただし、契約、個人情報保護法、業法、インシデント報告制度など、別の報告義務が適用される場合があります。
（出典：IPA「脆弱性関連情報についての届出」）

4. 脆弱性管理を仕組み化するにはどうすればよいか？

脆弱性管理の属人化を防ぐには、役割分担を明確にすることと、ツールを活用して監視・照合作業を自動化することの両方が必要です。

4.1. 体制・役割分担はどう決めるべきか？

小規模な体制であっても、次のような役割を明確にしておくと、担当者の異動や退職があっても対応を継続しやすくなります。

脆弱性情報監視担当：情報源を巡回・確認し、関連しそうなCVEを一次スクリーニングする
トリアージ判断者：CVSSスコアや自社製品への影響度をもとに対応優先度を判断する
パッチ適用・検証担当：修正パッチの動作確認と適用を行う
報告担当：社内・顧客・規制当局への報告文書を作成し、宛先ごとの粒度を調整する

人員が限られる企業では、1人が複数の役割を兼任する形でも運用は可能です。
重要なのは役割そのものを明文化し、担当者が不在でも誰かが代われる状態にしておくことです。

これらの役割は、PSIRT(Product Security Incident Response Team)と呼ばれる製品セキュリティ専門の機能としてまとめて整理されることもあります。
PSIRTが担う業務を整理すると、次のとおりです。

脆弱性受付
影響判定
製品責任者との調整
法務、広報、品質保証との連携
顧客通知
規制報告
修正後の再評価
対応記録と再発防止

4.2. ツール活用で属人化を防ぐには？

SBOMを自動生成・管理するツールを使えば、使用コンポーネントの棚卸しやCVEとの照合作業を自動化し、手作業を大幅に減らせます。

ただし、独自コンポーネントや静的リンク、バイナリ解析が必要なケースなど、ツールだけでは検出しきれない部分に人手の確認が必要になる場合もあります。

あわせて、外部の視点でファームウェアや通信、認証まわりの脆弱性を定期的に診断してもらうことで、社内の監視だけでは気づきにくい設定不備を補うこともできます。

ツールと診断を組み合わせることで、担当者個人の知識や経験への依存を減らせます。

4.3. 協調的脆弱性開示(CVD)の窓口はどう整備するか？

社外から脆弱性の報告を受け付けるには、あらかじめ協調的脆弱性開示(CVD)の窓口を整備しておく必要があります。
窓口整備で検討すべき項目は、次のとおりです。

脆弱性報告用メールアドレスまたはフォーム
security.txtなどの報告先情報
受付確認の目安
報告内容の機密保持
重大度判定と担当者の割当
報告者との公表日調整
CVE採番の要否
修正後のセキュリティアドバイザリ公開

CVDの窓口を整備しておくことは、CRAが求める脆弱性対応プロセスの一部としても位置づけられます。

5. CRA・JC-STARは脆弱性管理にどう関わるのか？

サイバーレジリエンス法(CRA)は、脆弱性対応プロセスの整備を求める規制です。
CRAの主要規定は2027年12月11日から適用されますが、脆弱性・インシデントの報告義務を定めるArticle 14は先行して2026年9月11日から適用されます。

CRA Article 14では、積極的に悪用されている脆弱性に加え、製品のセキュリティに影響する重大なインシデントも報告対象となります。
報告対象ごとの期限は、次のとおりです。

報告対象	早期警告	通知	最終報告
積極的に悪用された脆弱性	認識後24時間以内	認識後72時間以内	修正・緩和策が利用可能になってから14日以内
製品に影響する重大インシデント	認識後24時間以内	認識後72時間以内	インシデント通知から1か月以内

CRA Article 14に基づく報告は、EUの単一報告プラットフォームを通じて、メーカーの所管CSIRTおよびENISAに行います。
これは、IPA・JPCERT/CCが運用する日本国内の脆弱性関連情報の届出制度とは別の制度です。

CRAでは、影響を受ける利用者への通知も求められます。
また、2027年12月11日より前に市場投入された製品も、Article 14の報告対象になり得ます。

一方、JC-STAR★1では、セキュリティアップデートの優先順位を決める方針や、脆弱性情報の収集・トリアージ・分析・対策・アップデートという一連のプロセスを文書化していることが評価項目に含まれています。

単に脆弱性に対応しているというだけでなく、収集から報告までの流れを説明できる状態にしておくことが、CRA・JC-STARいずれの対応にもつながります。

それぞれの制度の詳細な要件やスケジュールは以下の記事で解説していますので、あわせてご確認ください。
JC-STARとCRAの違いについて解説した記事はこちら
 サイバーレジリエンス法(CRA)とは？日本のIoTメーカーが今から準備すべきこと

JC-STARとCRAの違いについて解説した記事はこちら

サイバーレジリエンス法（CRA）とは？日本のIoTメーカーが今から準備すべきこと

（出典：European Commission「Cyber Resilience Act」）
（出典：European Commission「CRA Reporting obligations」）
（出典：EUR-Lex「Regulation (EU) 2024/2847 (Cyber Resilience Act) Article 14」）
（出典：IPA「セキュリティ要件適合評価及びラベリング制度(JC-STAR)★1評価ガイド」）

CRA、JC-STAR、国内の届出制度、CVE、CVSSは、それぞれ次のように位置づけが異なります。

制度・用語	位置づけ
CRA	EU市場に関する法的規制
JC-STAR	日本の製品セキュリティ適合性評価・ラベリング制度
IPA/JPCERT/CC届出	国内の脆弱性情報の調整・公表制度
CVE	脆弱性を識別・カタログ化する仕組み
CVE ID	個々の脆弱性に付与される識別子
CVSS	脆弱性の深刻度を評価する指標

6. よくある質問

6.1. CVEとCVSSの違いは何か？

CVE(Common Vulnerabilities and Exposures)は、公開された脆弱性を識別・カタログ化する仕組みです。
各脆弱性にはCVE IDと呼ばれる固有の識別子が付与されます。

CVSSとは、その脆弱性の深刻度を数値化するための共通の評価指標です。

CVEが「どの脆弱性か」を特定する仕組みであるのに対し、CVSSは「どの程度深刻か」を判断するための指標という違いがあります。

6.2. 脆弱性が見つかったら公表すべきか？

自社製品に脆弱性が見つかった場合、パッチや回避策が用意できていない段階での性急な公表は、悪用のリスクを高めるおそれがあります。

公表時期は、悪用状況、影響範囲、利用者の安全、修正・緩和策の有無、報告者との調整、適用される法令を踏まえて判断します。
協調的脆弱性開示(CVD)による調整を基本としますが、利用者保護や法令上の報告が優先される場合があります。

IPA・JPCERT/CCの届出制度を活用すれば、対策情報が整うまでのタイミングを関係者間で調整しながら進められます。

公表の要否や時期は個別の状況によって判断が分かれるため、社内だけで抱え込まず、必要に応じて専門家や届出制度の窓口に相談することをお勧めします。