ICS/OTは製品寿命が長く、複数ベンダー部品の組み合わせで稼働します。そのため、自社が直接選定していないコンポーネント由来のSADP脆弱性が、現場リスクの中心になりがちです。加えて契約や責任分界、情報流通の遅れが重なると「影響有無が判断できない」状態が発生します。
部品階層が深いほど、どの型番・版数・構成が該当するか特定が困難です。SBOMや版数管理が不十分だと、CVEと自社資産を突合できず初動が遅れます。さらにOTでは停止コストや検証環境不足により、パッチ適用の意思決定そのものが重いプロセスになります。
Siemensが示す「透明性向上」は、単なる情報公開ではなく、顧客の判断材料を早く整った形で出す設計だと捉えるべきです。情シス・OT担当者が困るのは「結局、自社設備に影響があるのか」「いつまでに何をするのか」が曖昧な点です。ここが明確になるほど、過剰対策や不要停止を減らせます。
特に重要なのは影響評価（Affectedness）の粒度です。影響を受ける製品型番、ファーム/ソフト版数、成立条件（機能有効化やポート開放など）が提示されれば、資産台帳との突合が現実的になります。加えて、サプライヤー修正→製品取り込み→顧客適用というタイムラインと責任分界が見えると、保全計画や経営判断の合意形成が進みます。
透明性が上がっても、受け取る側が活用できなければ効果は限定的です。まず機器の型番・版数・設置場所・接続状況を揃え、脆弱性情報と「突合できる」状態を作ります。SBOMが理想ですが、短期的には機種別の版数と構成差分の管理だけでも初動は大きく改善します。
次に、一次受付（セキュリティ）と影響評価・適用計画（OTエンジ）と現場展開（保全）を分離します。情報量の多いSADP脆弱性を現場へ直送すると判断が止まりやすいため、要約・優先度付け・回避策の翻訳が不可欠です。優先度はCVSSだけでなく、外部到達性、横展開可能性、安全影響、停止許容度を掛け合わせて決めます。
今後は「透明性を提供できるベンダーを選ぶ」こと自体がリスク低減策になります。調達時点で通知チャネルやSLA、SBOM提供、修正方針、EOL時の扱いを要件化すると、運用コストを抑えられます。あわせて、検証環境（ステージングやデジタルツイン）と変更管理を整備し、「適用できない」を減らすことが最短の防御になります。
透明性は目的ではなく、検証と適用を回すための燃料です。SADP脆弱性が常態化する中、情報流通と運用設計の品質がOTセキュリティ成熟度を左右します。
