開発から導入までの確認点

正規の更新サイトから取得したファイルでも、開発・ビルド・配布の途中が侵害されていれば安全とは限りません。逆に、脆弱性情報に製品名が載っただけでは、自社で攻撃が成立すると断定できません。ソフトウェアが作られて届く経路と、脆弱な処理が利用される条件を整理しましょう。

脆弱性・脅威・リスクを区別する

用語	意味と確認点
脆弱性	攻撃に利用され得る弱点。実装の欠陥だけでなく設定・運用上の弱点もある
脅威	弱点を利用して害を生じさせる主体・行為・事象
影響	弱点が利用された場合に失う機密性・完全性・可用性など
リスク	攻撃成立の可能性と影響を踏まえた危険の評価

弱点が存在することと、外部からその弱点を利用できることは別です。製品・版、機能の有効化、到達可能性、認証の要否、実行権限、攻撃後のアクセス範囲を順に見ます。条件が欠けている場合は不明として調査し、使っていないと推測だけで除外しません。

サプライチェーンとは何か

ソフトウェアのサプライチェーンは、原材料に相当する部品やコードの取得から、開発・ビルド・署名・配布・導入・運用に至る供給の連鎖です。ビルドはソースコードや依存部品から実行可能な成果物を作る処理で、その環境や設定も攻撃対象になります。

サプライチェーン攻撃では、利用者が信頼する供給元や更新経路が利用されます。直接自社へ侵入する場合と違い、同じ成果物を使う多数の利用先に影響が広がることがあります。委託先の管理だけでなく、部品・ビルド・署名鍵・配布先それぞれの信頼を確認します。

事例：委託先から届く販売管理アプリ

架空のC社は委託先V社が開発する販売管理アプリを利用しています。V社は外部ライブラリLを組み込み、ビルド基盤で実行ファイルを生成します。署名した更新ファイルを配布サーバに置き、C社の管理者が検証環境で確認して本番へ反映します。

攻撃者が配布ファイルだけを差し替える場合と、V社のビルド基盤を侵害して署名される前の成果物へ不正処理を混ぜる場合では、必要な検査が異なります。配布時の署名検証は重要ですが、署名より前に混入した不正処理の内容まで自動的に保証しません。

開発から導入までの確認点

1. 依存部品：証跡部品名・版・取得元を管理／防御・対処承認済み部品と脆弱性情報を照合
2. ビルド：証跡設定・実行者・成果物の記録／防御・対処権限分離とビルド環境の保護
3. 配布：証跡署名・取得元・成果物識別／防御・対処配布経路と署名鍵を保護
4. 導入：証跡検証結果と反映した版／防御・対処署名確認・動作検証・切戻し準備

架空の配布経路です。各段階で守る対象が変わります。

脆弱性情報から影響範囲を確かめる

脆弱性情報は対象製品・版と成立条件を資産台帳へ対応付けます。資産台帳は「サーバ名」だけでなく、製品、版、依存部品、設置場所、責任者、利用機能などを追えると調査に役立ちます。導入時に記録しても更新で変わるため、実際に動いている構成と合わせます。

SBOM（Software Bill of Materials）はソフトウェアの構成部品を一覧にした情報です。どのライブラリ・版が含まれるかを調べる手掛かりになり、同じ部品を複数製品が使っている影響を追えます。ただしSBOMがあるだけで脆弱性がない、攻撃が不成立、一覧が実環境と一致しているとは保証されません。

調査項目	C社での判断
製品と版	販売管理アプリとLの該当版を使っているか
機能	弱点のある機能が有効・呼出可能か
到達	外部、社内、委託先のどこから操作できるか
権限	悪用に認証が必要か、成功後に何を実行できるか
実利用	台帳・SBOMと稼働中の構成が一致するか

CVSS（共通脆弱性評価システム）が示す技術的な深刻度は優先度を考える材料です。自社の業務影響、公開状況、攻撃の確認、代替策の有無なども加えて対応します。高い点数を放置してよいという意味ではなく、点数だけでは現場で何から対処するかを決め切れないということです。

パッチ、緩和策、恒久対策の違い

パッチは欠陥を修正する更新です。緩和策は機能停止・経路制限などによって攻撃の成立や影響を抑える暫定的な措置です。パッチを適用できない期間は緩和策の対象・期間・残る危険を記録し、修正後に不要な制限を戻す判断まで用意します。

「検証が必要なので待つ」だけでは、攻撃可能な状態を放置します。一方、検証せず更新して停止させると別の業務被害を生みます。脆弱な経路を先に制限し、検証環境で業務・データ互換性・連携・切戻しを確かめる順序を、攻撃の進行状況と停止許容に合わせて選びます。

修正と緩和を区別する

目的と処理する場所を対応付けて読みます。

適用完了の報告だけでなく、稼働中の版・設定・対象台数を確認します。停止した検証環境だけが更新され本番に旧版が残る、冗長構成の片側だけ更新されるなど、報告と実態のずれがないか点検します。

ハッシュと署名が保証する範囲

ハッシュの一致は、信頼できる期待値と比較した場合に内容の差異を検出する手掛かりになります。ファイルと期待ハッシュを同じ侵害済みサーバから取れば、攻撃者が両方を差し替えられるため真正性の根拠として弱くなります。

電子署名は秘密鍵で作成し対応する公開鍵で検証します。信頼する鍵と配布物を結び付ければ、署名後の改変や署名者の確認に役立ちます。ただし署名鍵の侵害、承認済みビルドへの混入、正規の開発者による不正などは別の管理が必要です。暗号計算の詳細は暗号・PKI・TLSの記事で扱います。

text

配布物：release.bin
確認1：取得元と対象の製品・版
確認2：信頼する鍵による署名検証
確認3：部品情報と脆弱性の確認
確認4：検証環境で業務・通信・権限の動作確認
確認5：承認記録と本番に反映された版

委託先管理と内部不正への備え

責任を委託先へ渡しても、自社の業務被害を引き受ける主体は自社です。契約・運用で、構成情報の提供、脆弱性通知、修正版提供、対応期限、アクセス経路、証拠の保管、緊急時の連絡を定めます。自社側は受領情報を使って確認し、管理者の操作を任せ切りにしません。

内部不正は、正規に持つ権限を業務目的に反して使う場合もあります。開発者がコードの変更から本番配布まで一人で承認できると、外部侵入を防いでも不正混入を見逃します。権限の最小化、レビュー、承認と実施の分離、改変しにくい履歴、独立した確認を組み合わせます。

守る場所	具体的な管理
依存部品	取得元・版・承認・SBOMの管理
ソースとビルド	レビュー、実行権限、構成変更記録
署名鍵	アクセス制限、保管、使用記録、侵害時の切替
配布と導入	署名検証、検証結果、承認、反映版の確認
委託先接続	作業期間・対象の制限、権限失効、操作記録

不審な更新を導入した疑いがある場合、更新経路の停止や対象の隔離、配布物・署名・ログの保全、影響範囲の確認が必要です。侵害された鍵や基盤をそのまま使って再配布すると、再度混入される可能性が残ります。具体的な初動と復旧はインシデント対応の記事で扱います。

演習1：該当製品だけで断定しない

条件：脆弱性は機能Fにあり、自社でFが有効か不明。

問い：影響なしと判断する前に何を確認するか。

解答例：稼働中の版と、機能Fの有効化・呼出し経路など攻撃成立条件を確認する。

根拠と誤答の確認：製品名の一致は調査対象を示します。「外部公開していない」だけでは社内や委託先からの到達を除外できません。

演習2：SBOMの限界

条件：SBOMにライブラリLが記載されている。

問い：SBOMだけで安全と言えるか。

解答例：言えない。実構成との一致、該当版の脆弱性、利用機能と成立条件を別に確認する必要がある。

根拠と誤答の確認：一覧は確認のための情報です。安全性の検証結果そのものではありません。

演習3：署名前の混入

条件：攻撃者がビルド基盤を侵害し、不正処理を含む成果物が正規鍵で署名された。

問い：署名検証だけで不正を発見できるか。

解答例：できない。正規の署名は検証できても、署名前の成果物の内容が安全とは保証されないため。

根拠と誤答の確認：署名が偽造されたという条件ではありません。侵害箇所と署名時点の前後を区別します。

演習4：ハッシュの取得元

条件：ファイルと期待ハッシュを同じ侵害された配布サーバから取得する。

問い：一致しても真正性の根拠が弱い理由は何か。

解答例：攻撃者がファイルと期待ハッシュの両方を差し替えられるため。

根拠と誤答の確認：計算ミスやハッシュ衝突を仮定する必要はありません。期待値の信頼が問題です。

演習5：適用までの期間

条件：修正版の検証に2日必要。攻撃はインターネットから機能Fへ届くと成立する。

問い：検証中に行う緩和策を答える。

解答例：機能Fへの外部到達を制限する、または業務影響を確認してFを一時停止する。

根拠と誤答の確認：条件に直接働きかける必要があります。「社員教育」だけでは外部からの機能利用を止めません。

演習6：一人で配布できる権限

条件：開発者がコード変更、署名、本番反映を単独で行える。

問い：不正混入を見逃しにくくする管理策を答える。

解答例：変更を独立した担当者がレビュー・承認し、署名と本番反映の権限を必要範囲に分離する。

根拠と誤答の確認：作業ログだけでは未然の承認を代替しません。記録の独立確認も組み合わせます。

参照資料とこの記事の範囲

事例・図・演習は教材用に独自に作成しました。技術仕様とIPAの公開資料を照合し、特定年度の問題本文を前提にせず学べる構成にしています。

脆弱性とサプライチェーン対策｜更新・配布・委託先の信頼を点検する