委託すれば、任せて安心？——委託先・再委託先・OSS・SBOM・サプライチェーン攻撃を午後の問われ方で読む｜支援士解説3の10

この記事の重要度：Aランク（午後の大問・設問でよく問われる重要な分野）

この記事で分かること：

• サプライチェーンから届く四つのリスクと、委託先・再委託先を選ぶ・契約する・確かめる・終える流れ
• OSS・依存ライブラリ・外部スクリプトのリスク、SBOMで分かることと分からないこと、作る工程と配布経路の保護
• 解答欄に書く「原因」と「対策」の型

シラバスとの対応：小項目3-10「サプライチェーンの情報セキュリティの推進」。製品・クラウドの選定と評価制度は支援士解説2の2、開発の工程（ビルド・配布）は支援士解説2の8、監査の進め方は支援士解説1の5、脆弱性への対応は支援士解説3の6で扱います。

---

自組織の対策を固めても、委託先や取引先、使っている部品の対策が甘ければ、そこから攻撃されます。保守の委託先の接続から侵入される、預けた情報が委託先で漏れる、使っているライブラリや読み込んでいるスクリプトが改ざんされる、依存しているサービスが止まって業務も止まる。午後の問題では、こうした「自組織の外から届くリスク」に対し、契約に何を書くか、再委託先まで何を求めるか、部品をどう把握するかが問われています。

この記事では、架空の自治体が申請システムの開発・運用を委託する場面を例に、リスクの経路、依存関係の把握、選定と契約、再委託、OSSとSBOM、作る工程と配布経路、契約後の確認、事故と終了を順に整理します。

1. 自組織の外から届くリスクを分ける

サプライチェーンは、製造業だけの言葉ではない

サプライチェーンは、製品やサービスを提供するための供給のつながりです。ITでは、機器の製造元、販売事業者、開発会社、部品の提供者、運用保守会社、クラウドサービス、再委託先などが関係します。

契約書の相手方と、実際にデータを扱う人や、プログラムを作る人が一致するとは限りません。外部から購入した製品に、さらに別の組織が作った部品が入っている場合もあります。

サプライチェーン・リスク管理では、このつながりの中で生じる問題が、自組織の情報や業務へどう影響するかを把握し、対策を組み合わせます。NIST SP 800-161 Rev.1（2024年11月更新版）も、組織の各階層で、供給網全体のサイバーセキュリティリスクを識別・評価・低減する考え方を示しています。NIST SP 800-161 Rev.1、概要

経路1：委託先の接続が、侵入経路になる

保守事業者の端末やアカウントが侵害され、その接続を通じて利用組織へ入られるケースです。委託先との接続だからと広い権限を与えていると、影響も広がります。

ここでは、接続元端末の管理、強い認証、接続先と操作の制限、利用時間、作業の承認、ログの確認が関係します。契約書に侵入防止を要求することと、実際の接続で不要な操作を拒否できることを、両方確かめます。

経路2：委託した情報が、外部で漏れる

データ入力や問い合わせ対応を委託し、相手方の環境へ情報を渡している場合です。自組織のネットワークへ侵入されなくても、委託先に保存された情報が流出すれば問題になります。

渡す情報を必要な範囲に絞り、利用目的、保存先、閲覧者、持出し、返却・消去を定めます。自組織のファイアウォールを強化するだけでは、相手方にあるコピーの保護を代替できません。

経路3：製品・部品・更新へ、不正な変更が混入する

利用組織が正規の製品や更新を導入したつもりでも、その製造・開発・配布の途中で不正な機能が加えられている場合があります。

プログラムの入手先、開発工程、ビルド環境、署名に使う鍵、配布先の管理を考えます。ビルドは、ソースコードなどから配布・実行するソフトウェアを作る工程です。ソースコードを点検していても、ビルド時に別の内容が混入すれば、納品物は点検したものと一致しません。

また、不正な混入と、通常の開発で生じた脆弱性は同じではありません。どちらも影響しますが、部品の更新だけで足りるのか、開発環境の侵害調査まで必要かが変わります。

経路4：依存先が止まり、自組織の業務も止まる

外部サービスが停止し、予約受付や認証、連絡ができなくなるケースです。自組織の機器が無事でも、業務を続けられない場合があります。

サプライチェーンを通じた影響には、攻撃者が自組織へ侵入する場合だけでなく、依存先の停止が波及する場合もあります。さらに、事故やサービス終了による停止も、供給への依存を管理する上での検討対象です。すべての停止をサプライチェーン攻撃と呼ぶわけではありません。

何時間まで待てるか、代替手段は何か、復旧後にデータをどう整合させるかを考えます。機密性だけでなく、完全性と可用性も対象です。

【図1】供給のつながりから、何が起きるかを分ける

午後での問われ方

• 平成31年度春期 午後II問2：出題趣旨は、攻撃者が、対策の不十分な取引先にまず侵入し、そこから大企業の重要な情報を狙うようになったことを背景に挙げ、自社だけでなく取引先を含めた対策を考えさせています。
• 令和5年度春期 午後II問1：企業グループで、各社のWebサイトの脆弱性診断を親会社が管理するようになった場面が題材でした。診断の開始までに時間がかかる課題への対策として、解答例は「グループ各社で資産管理システムを導入し、Webサイトの情報を管理する」です。診断を委託している専門業者（B社）への問合せの費用がかさむ課題には、同じ問合せを繰り返さないよう、「B社への問合せ窓口をA社の診断部門に設置し、窓口が蓄積した情報をA社グループ内で共有する」ことが示されています。

記述の型

• サプライチェーン攻撃が成立する理由：「子会社や取引先は対策が遅れていることが多く、親会社とのアクセス制限も不十分なことがあり、踏み台にされる」
• グループの把握：「グループ各社の資産を管理し、必要な情報を親会社が把握できるようにする」

2. 会社名の一覧を、依存関係の見取り図にする

何を任せ、何が届き、何につながるか

委託先一覧に会社名と契約金額が載っていても、その企業で問題が起きたときの影響は分かりません。本稿では、次の情報を対応付けることを提案します。

• 業務：どのサービス・作業を任せているか。
• 情報：何を渡し、相手方が何を生成・保存するか。
• 権限と接続：どの環境へ、どの操作ができるか。
• 製品と部品：どの製品・版・構成を利用しているか。
• 依存関係：再委託先、クラウド、共通サービス等との関係。
• 責任者と期限：社内担当、相手方の窓口、契約・保守の期間。

一つのシステムでも、開発、監視、認証、データ保管で相手が違います。逆に、複数のシステムが同じクラウドや認証サービスへ依存していることもあります。

契約の線と、データ・接続の線は別

架空の例として、市がA社へ運用を委託し、A社がB社へ夜間監視を再委託しているとします。データはC社のクラウドに保存されています。

市とA社の契約があるからといって、市がB社やC社へ直接、任意の調査や設定変更を命じられるとは限りません。一方、B社がログを閲覧するなら、B社の情報管理は、市に影響します。

そこで、A社を通じて必要な要求と確認を行う契約上の経路と、実際に情報が流れる経路を両方把握します。組織名の箱を描くだけでなく、矢印が契約、データ提供、保守接続のどれなのかを区別します。

確認の深さは、危険性と影響で変える

公開資料の印刷を依頼する相手と、住民情報を保存し、管理者権限で保守する相手へ、同じ質問票だけを配るのは適切とは限りません。

取り扱う情報の重要性、権限の強さ、接続の範囲、停止時の業務影響、代替の難しさを評価します。高いリスクの委託先には、より詳しい証跡、技術的な検証、短い見直し間隔などを検討します。

ただし、重要度を付けた後も、新しい情報を渡す、権限を増やす、別サービスへ移す、といった変更で前提は変わります。選定時の評価を永久に有効とはしません。

多社へ分けても、依存が分散しているとは限らない

二社へ発注していても、両社が同じデータセンターや共通基盤を使っていれば、その停止で同時に影響を受けるかもしれません。

本稿では、重要なサービスについて、契約先の数だけでなく、共通の依存先を確認することを勧めます。一方、分散すれば常に安全というわけでもありません。運用の複雑さや、データの同期、復旧手順の違いも評価します。

【図2】契約の相手と、実際の処理先を分けて把握する

3. 選定時に、認証の有無と案件への適合を分ける

選定条件は、任せる業務から決める

委託先の評価では、情報管理の体制、作業者の管理、開発・保守の手順、事故対応、サービス継続、再委託の管理などを確認します。

例えば、夜間に重大なアラートを受ける業務なのに、問い合わせ窓口が平日の昼だけなら、要求とのずれがあります。認証を持っているかという質問だけでは、この問題を見つけられません。

何を満たす必要があるか、何で確認するか、満たさない場合に代替策を認めるかを、選定前に決めます。契約後になって初めて必要条件を伝えると、費用や実現可能性で調整が必要になります。

第三者認証は、確認する対象と範囲がある

ISMS認証は、定めた適用範囲の情報セキュリティマネジメントシステムに関する認証です。個々の製品に脆弱性がないことや、全ての拠点・再委託先が同じ範囲で評価されたことを意味しません。ISMS-AC「ISMS適合性評価制度の概要」、同「ISMS認証について」、認証範囲

証明書や審査に関する資料を見る際は、対象組織、事業・拠点、対象期間、有効性、除外事項などを確認します。今回使うサービスや作業場所が含まれるかを照合することが重要です。

第三者の監査報告も、対象期間と範囲、例外事項、利用組織側に必要な対策を読みます。「報告書がある」という事実と、今回の要求が満たされているという判断は別です。

例えば、提供者側が設備を守っていても、利用者側の管理者IDや公開設定は発注側の担当かもしれません。責任分界を見ずに、評価済みだから設定確認は不要とすると、対策の空白が生じます。

質問票の回答は、根拠とセットで読む

「アクセス管理を実施している」という回答なら、対象のアカウント、承認手順、担当交代時の解除、点検記録などを確認します。

すべての内部資料を提出させる必要はありません。他の顧客の秘密や個人情報を含む場合には、対象を絞った資料、マスキング、閲覧による確認、第三者報告などを組み合わせます。目的は書類の量を増やすことではなく、要求に対する判断材料を得ることです。

回答が不明な項目を、都合よく「問題なし」と扱わないことも大切です。未確認の内容、想定する影響、追加確認の担当と期限を記録し、権限を持つ者が採用の可否や条件を判断します。

評価・認証制度の読み方は支援士解説2の2で扱います。

午後での問われ方

• 令和3年度春期 午後II問2：利用部門が使うクラウドサービスをIT部門が統制する場面で、規格又は認証の例として、解答例には「ISAE3402/SSAE16」と「ISMS認証」が挙げられています。
• 令和2年度10月 午後II問2：マルチクラウドを使う環境のリスク評価で、クラウドサービスのセキュリティ対策を確かめる方法として、解答例は「セキュリティ対策についての第三者による監査報告書で確認するという方法」です。利用者が自ら検査できない相手は、第三者の評価で確かめます。

記述の型

• 委託先の認証の確認：「今回の業務・拠点が認証の範囲に含まれるかと、個別の要求への対応を確認する」
• 直接検査できない相手：「第三者による監査報告書や認証で、セキュリティ対策を確認する」

4. 契約の言葉を、確認できる要求事項にする

仕様書と契約を、同じ内容にそろえる

仕様書には厳しい要求があるのに、契約書や利用約款では対応対象外になっていると、事故時に認識が食い違います。提案内容、仕様書、契約書、サービスの約款、運用手順の関係と優先順位を確認します。

責任分界は、誰がどの範囲を担当するかという分担です。製品の修正プログラムを作る人、適用を判断する人、実際に適用する人、結果を確認する人は同じとは限りません。

委託先が修正を提供しても、発注側が適用を承認しなければ進まない運用なら、その判断に必要な情報と連絡方法も決めます。「双方で対応する」という一文だけでは、先に誰が動くかが分かりません。

要求事項は、対象・行為・時期・証跡で具体化する

次は本稿の設計例です。完成した契約条文として一律に転用するのではなく、対象業務と契約の条件に合わせて調整します。

「適切にアクセス管理する」という要求を、次のように分解します。

• 対象：本番環境へ接続する保守用アカウント。
• 行為：個人を識別し、承認した対象と操作に限って利用を許可する。
• 時期：発行時、作業時、担当交代時、契約終了時に必要な処理を行う。
• 証跡：申請、承認、接続・操作、利用停止の記録を残す。
• 確認：発注側が必要な記録を確認できる方法を用意する。
• 未達時：不要な権限を制限し、是正の期限と完了報告を定める。

この形なら、注意喚起のメールを送っただけでは、権限解除の完了とは言えないことが分かります。

契約で検討する主な事項

対象業務に応じて、次の論点を整理します。

• 情報の範囲と目的：提供する情報、目的外利用・第三者提供の扱い。
• 作業体制：責任者、作業場所、作業者、教育と変更時の連絡。
• 保護策：アクセス制御、通信・保存の保護、ログ、脆弱性管理、バックアップ。
• 再委託：承認や通知の条件、必要な要求の引継ぎ、履行の確認。
• 報告：通常の実績報告、事故の疑い・脆弱性・重大な変更の通知。
• 調査と監査：資料提供、検査、証拠保全、他の顧客情報への配慮。
• 継続と終了：復旧、移行支援、返却・消去、終了後に残る義務。
• 未履行への対応：是正要求、利用制限、解除や損害賠償等の条件。

秘密保持契約、NDAは、このうち秘密情報の取扱いを定めるものです。サービス停止、復旧支援、更新プログラムの提供まで、NDAだけで全て取り決められるわけではありません。

SLAの数字には、測り方と対象を付ける

SLA（Service Level Agreement）は、提供するサービスの水準についての合意です。稼働率、問い合わせへの応答、復旧等を定める場合があります。

例えば「障害に30分以内で対応」とだけ書くと、受領の連絡なのか、調査開始なのか、復旧完了なのかが曖昧です。対象となる時間帯、起算点、重大度、除外条件、測定方法、未達時の扱いを確認します。この30分は説明用の仮の値であり、標準値ではありません。

また、料金の減額が定められていても、住民向け業務が代わりに復旧するわけではありません。補償と、被害を小さくするための運用・復旧は分けて考えます。

事故報告を、調査の完了待ちにしない

本稿の提案として、契約上の報告は、対象となる事象、認知の基準、初報の期限と連絡手段、続報、最終報告を分けます。

最初から原因と被害件数の確定を求めると、初報が遅れるおそれがあります。分かっている事実、不明点、現在の措置、次の報告予定を伝える運用にします。法令上の報告期限と、発注者・受注者間の通知期限は同じとは限らず、それぞれを確認します。

【図3】要求事項を、実施と確認ができる形にする

記述の型

• 契約に定める事項：「責任の範囲、求める安全管理の対策、再委託の条件、報告の内容と頻度、委託元による確認の方法、事故時の報告、契約終了後の情報の返却・消去」
• 事故の報告：「調査の完了を待たず、発生や疑いの段階で速やかに報告させる」

5. 再委託先まで、要求と確認をつなぐ

元請との契約だけでは、実作業の条件が分からない

再委託は、受託した業務の全部又は一部を、受託者がさらに別の相手へ委託することです。専門業務を分担するために行われることがありますが、関係者と接続・情報の流れが増えます。

まず、契約や規程上、再委託を認める範囲と手続を確認します。認める場合には、相手、業務、情報、場所、接続、期間、対策、監督方法等を明らかにします。再々委託など、先へ連なる場合の扱いも必要です。

「再委託先は元請が責任を持つ」とするだけでは、発注者が必要な条件を確認できるとは限りません。どの情報を元請から受け取り、変更時にどう判断するかを決めます。

同等の対策を求めることと、同じ製品を買わせることは別

再委託先に、委託元との契約で必要となるセキュリティ要求を引き継がせます。ただし、必ず同じ製品や同じ組織体制を使わせる意味ではありません。

例えば、アクセスを許可する人を限定し、その操作を追跡できることが必要なら、異なる製品でも要求を満たす場合があります。一方、対象データを扱うのに、組織が小さいという理由だけで必要な保護を省くことはできません。

対象業務に該当する要求を明確にし、代替策を認める場合には、その効果と残るリスクを評価します。元請が都合よく要件を省略してよいという意味ではありません。

承認・契約・実際の確認を分ける

発注者が再委託を承認したことは、再委託先の全ての作業が常に適切であるという証明ではありません。

元請が必要な条項を再委託契約に含めること、その対策を実際に行わせること、実施状況を確認して発注者へ報告することをつなげます。元請と再委託先の契約、作業者の教育、権限設定、事故連絡が実際に対応しているかを見るわけです。

発注者から再委託先への直接の監査・立入り等が必要なら、実行できる契約上の根拠と経路を設けます。直接契約がない相手へ、当然に何でも要求できるとは考えません。

担当会社が変わるときも、変更管理の対象

再委託先の交代、作業場所の変更、クラウドやデータ保管場所の変更で、選定時の前提が変わる場合があります。何を事前承認とし、何を通知とし、緊急時にはどう対応するかを決めます。

旧担当者のアカウント停止と、新担当者の権限発行、データの移管、連絡先の更新まで確認します。会社名を台帳で書き換えるだけでは、旧接続やコピーが残る可能性があります。

【図4】再委託先まで、要求と履行確認をつなぐ

午後での問われ方

• 令和7年度春期 午後問1：システム開発企業のサプライチェーンリスク対策が題材でした。委託先が再委託を行う場合に備えて、委託先との契約に明記すべき事項として、解答例は「L社の業務委託先に要求する対策と同等のセキュリティ対策を再委託先にも要求させること」です。

記述の型

• 再委託の契約事項：「自組織が委託先に要求する対策と同等のセキュリティ対策を、再委託先にも要求させる」
• 再委託の管理：「委託先の企業を、再委託先まで含めて一覧として管理し、再委託は事前の承認を条件にする」

6. OSS・依存ライブラリ・外部スクリプト

自分たちのコードだけでは、構成は分からない

今のソフトウェアは、自分たちで書いたコードだけでなく、多くのOSS（オープンソースソフトウェア）のライブラリを組み合わせて作られています。ライブラリは、さらに別のライブラリを使っていることが多く、直接は使っていないつもりの部品（推移的な依存関係）にも、脆弱性や不正なコードが入り込みます。部品の側に脆弱性があれば、自分たちのコードに問題がなくても攻撃されます。

部品のリスクと、その対策

• 既知の脆弱性：使っているライブラリに脆弱性が公表される。部品の一覧（SBOM）と、部品を脆弱性の情報と照合するSCA（ソフトウェア構成分析）のツールで、使っているかを速く調べる。SCAは開発のときだけでなく、運用中も続ける。リリースの後に、新しい脆弱性が見つかるから
• 悪意のあるコードの混入：公開されている部品そのものに、不正なコードが入れられる。よく似た名前の部品を登録して取り違えを狙う手口もある。取り込む部品の版を固定し、取得元と、提供されているハッシュ値や署名を確かめる。組織内に、確認した部品だけを置く保管場所を用意する方法もある
• 保守の停止：保守されなくなった部品は、脆弱性が見つかっても修正されない。採用の前に、更新の状況と保守の体制を確かめる
• ライセンス：部品ごとに利用の条件が違う。SBOMにライセンスの情報を残し、条件に反していないかを確かめる

実行時に外から読み込むもの

Webページが、利用者のブラウザで動くスクリプトを提供元のサーバから読み込んでいると、提供元のサーバが改ざんされたとき、自組織のサイトの利用者が被害を受けます。こうした部品は、自組織のソースコードの中にないので、部品の一覧に載らないことがあります。対策は、スクリプトを確認したうえで自組織のサーバに置く、不要なら読み込みをやめる、連携している外部サービスを資産として管理する、などです。読み込んだ内容が改ざんされていないかを、ブラウザに確かめさせる仕組みもあります（SRI：Subresource Integrity）。読み込むスクリプトのハッシュ値をHTMLに書いておき、届いた内容のハッシュ値が一致しなければ、ブラウザはそのスクリプトを実行しません。提供元が内容を更新したら、ハッシュ値も書き直す必要があります。

午後での問われ方

• 令和7年度春期 午後問1（5.と同じ問題）：システムが、古いブラウザに対応するためのスクリプトを提供元の会社のサーバから読み込んでいたところ、提供元のサーバが乗っ取られてスクリプトが改ざんされ、利用者が悪意のあるサイトに転送されました。影響を受けない配置の方法として、解答例は「スクリプトPをダウンロードしておき、システムQのサーバ上に配置する方法」、実際の対応は「スクリプトPを読み込む箇所をソースコードから削除する」です。管理の見直しとして「連携している外部サービスを管理対象に含める」ことも示されています。
• 令和6年度春期 午後問1：非常に多くのシステムで使われているライブラリに、修正版も暫定対策もない深刻な脆弱性が公表され、攻撃にも悪用されていました。開発を委託した会社に、そのライブラリを使っているかを問い合わせると、システムの構成を詳しく分析しなければならず、回答に時間がかかるとされました。部品の一覧（SBOM）があれば、この時間を短くできます（この一文は問題文ではなく、本稿の補足です）。
• 令和4年度秋期 午後I問3：出題趣旨は、OSSを用いた開発が一般化する一方で、悪意あるプログラムや脆弱性をもつプログラムがOSSに混入する可能性が高まっていることを背景に挙げ、インシデントハンドリングの体制と手順を問うています。

採点講評で指摘されたつまずき

• 令和7年度春期 午後問1では、スクリプトの配置の方法を問う設問で、正答率はやや高かったものの、JavaScriptが正しく動作しない配置の方法を答える解答が散見されたとされています。システムの構成を理解したうえで答えることが求められています。

記述の型

• 外部スクリプトの改ざんの影響を受けない方法：「スクリプトをダウンロードして、自組織のサーバに配置する」
• 外部から読み込むものの把握：「連携している外部サービスを、資産の管理対象に含める」
• SCAを運用中も続ける理由：「リリースの後に、新たな脆弱性が発見されることがあるから」

7. SBOMを、使っているソフトウェアの調査に使う

自社で書いたコードだけでは、構成は分からない

ソフトウェアには、外部のライブラリ、フレームワーク、OSの部品などが組み込まれます。ライブラリは、特定の機能を利用できるようまとめたプログラム部品です。

さらに、その部品が別の部品を利用することがあります。自分たちが直接選んだ部品への依存を直接依存、その先の部品への依存を推移的依存と呼びます。

例えば、架空の予約アプリが帳票出力部品を使い、その帳票出力部品が画像処理部品を使う場合です。画像処理部品の問題でも、利用する機能や構成によっては予約アプリへ影響します。開発者が直接選んでいない部品だから無関係、とは言えません。

SBOMは、ソフトウェアの部品構成を表す

SBOM（Software Bill of Materials）は、ソフトウェアを構成する部品と、その関係などを表す情報です。ソフトウェア部品表、部品構成表とも呼ばれます。

部品名、バージョン、供給者、識別子、依存関係などを機械で扱える形にすると、脆弱性情報との照合や対象製品の調査に利用できます。実際に必要な項目と範囲は、採用する仕様・版や用途に合わせて定めます。

経済産業省の「ソフトウェア管理に向けたSBOMの導入に関する手引」ver2.0（2024年8月）は、脆弱性管理の手順に加え、導入範囲や契約上の要求・責任・費用等も扱っています。部品表を作ることと、組織で使う仕組みを整えることを一緒に考えます。経済産業省、同手引の改訂概要

SPDXとCycloneDXは、情報を交換する形式

SBOMの表現に利用される標準として、SPDXやCycloneDXがあります。これらは構成情報等を記述・交換するための仕様であり、脆弱性検査に合格したという認証マークではありません。SPDX公式「Overview」、CycloneDX公式「Getting Started」

同じ形式名でも、仕様の版、出力する項目、依存関係の深さ、生成ツールの対象によって内容は異なります。受け取る側のツールで読み込めるかだけでなく、必要な部品が把握できるかも確認します。

製品の版と、実際に稼働する場所を対応付ける

SBOMに部品が載っていても、そのSBOMがどの製品・リリースを表すか不明なら、影響するシステムを絞れません。

架空の例を考えます。予約アプリ2.4には画像処理部品1.6、予約アプリ2.5には画像処理部品1.8が含まれます。画像処理部品1.6に脆弱性が公表されたとします。

必要なのは、2.4のSBOMを検索することだけではありません。本番環境、検証環境、待機系のどこで2.4が動き、どこへ2.5が適用済みかを、資産・構成管理の情報と照合します。最新のSBOMだけを保存し、旧版が残る場所を把握していないと、取り残しを見つけられません。

部品が含まれることと、悪用できることは別

脆弱な版の部品を含むことが分かったら、製品が影響を受ける条件を調べます。問題の機能を使うか、必要な設定が有効か、外部から到達できるか、供給者の修正が含まれるかなどです。

名前が一致しただけで、直ちに全システムが侵害されたとは言えません。逆に、一覧に見つからないことだけで無関係とも断定できません。生成範囲の不足、部品名の違い、古いSBOM等の可能性があります。

VEX（Vulnerability Exploitability eXchange）は、特定の製品が特定の脆弱性から影響を受けるかなどの評価を伝えるための情報です。SBOMの構成情報を補います。CycloneDX公式「VEX」

影響なしという情報を受け取っても、発行者、対象製品と版、対象の脆弱性、理由、更新時点を確認します。別の版や別の構成へ無条件に広げません。調査中と、影響なしも区別します。

SBOMを受け取る契約で決めたいこと

本稿の実務上の確認例です。

• どの製品・成果物を対象にするか。どの段階の構成情報を提供するか。
• 形式・仕様の版、必要な項目、依存関係の範囲、把握できない範囲。
• 納品時と更新時の提供時期、製品のリリースとの対応。
• 脆弱性情報の監視、影響調査、回答、修正の担当と期限。
• 共有先、閲覧権限、保管、機密情報・権利・費用の扱い。
• 契約終了後の保守や問い合わせが必要な場合の条件。

オープンソースソフトウェア、OSSだけを対象にすればよいとは限りません。商用部品や組込みの部品も、対象製品の構成として必要な場合があります。第三者製品の詳細を把握できないなら、その限界と、供給者への照会・回答経路を明らかにします。

一覧の提出から、修正結果の確認まで

実務では、構成情報を受け取る、資産と結び付ける、脆弱性情報と照合する、影響を評価する、修正・代替策を判断する、結果を確認する、という流れになります。

SBOMを更新しても、動いているソフトウェアが更新されたとは限りません。逆に、修正を適用してもSBOMが古いままなら、後日の調査で誤った判定をします。実際の状態と構成情報をそろえることが重要です。

【図5】SBOMを、影響調査と修正結果の確認へつなぐ

午後での問われ方

• 令和7年度春期 午後問1（5.と同じ問題）：SBOMを作成すると将来、脆弱性管理がしやすくなる理由として、解答例は「利用しているソフトウェアやそのバージョンが明確になり、脆弱性の影響有無を容易に把握できるから」です。この問題のSBOMの作成機能は、リポジトリの中のソースコードとライブラリを一覧にするものだったので、実行時に外から読み込むスクリプトは載りません（6.）。

採点講評で指摘されたつまずき

• 令和7年度春期 午後問1では、脆弱性管理でSBOMを使う利点を問う設問で、SBOMの利用方法が説明できておらず、SBOMの定義を書いただけの解答が散見されたとされています。何の役に立つかまで書きます。

記述の型

• SBOMの利点：「利用しているソフトウェアやそのバージョンが明確になり、脆弱性の影響の有無を容易に把握できる」
• SBOMの限界：「実行時に外部のサーバから読み込むスクリプトは、SBOMに含まれないことがある」
• SBOMの維持：「リリースのたびに作成し、実際に稼働している版と対応付ける」

8. 納品物だけでなく、作る場所と届ける経路を見る

セキュリティ・バイ・デザインを、委託仕様にも反映する

セキュリティ・バイ・デザインは、企画・設計などの早い段階からセキュリティを組み込む考え方です。納品直前に検査を追加するだけでは、権限構造やデータの置き方を大きく直す必要が生じる場合があります。

例えば、開発委託の要求として、保護する情報、攻撃や誤操作の想定、認証・認可、記録、更新方法を設計時に確認します。試験で何を確かめるか、誰が未解決の問題を判断するかも決めます。

NISTのSSDFは、安全なソフトウェア開発の実践を開発ライフサイクルへ組み込むための枠組みです。調達側と供給側の共通の言葉としても利用できます。本稿ではSP 800-218のSSDF Version 1.1を参照します。NIST SP 800-218、概要

コード、ビルド、配布を一続きに見る

リポジトリは、ソースコードや変更履歴などを管理する場所です。ここへの書込みを制限し、重要な変更のレビューや承認を行います。

CI/CDは、コードの統合、テスト、リリース等を継続的に進めるための仕組みです。自動化されていても、設定や権限が不適切なら、不正なコードが速く配布されるおそれがあります。

本稿の対策例として、開発者や自動処理の認証情報を保護し、必要最小限の権限にします。外部から取り込む部品の供給元と版を確認し、ビルド環境を管理し、成果物を変更できる人を限定します。承認したソースや部品と、配布物との対応を追える記録も必要です。

来歴情報（provenance）は、成果物がどのソース・材料・工程等から作られたかを追うための情報です。情報が存在するだけでなく、信頼できる方法で生成・保護されているかを考えます。CycloneDX公式「Security Use Cases and Examples」、Provenance

ハッシュと署名が確認するもの

ハッシュ値は、データから計算した値です。信頼できる正しい値と比較すれば、受け取ったデータの変更を検出する助けになります。ただし、攻撃者がファイルと掲載されたハッシュ値の両方を差し替えた場合、両者が一致しても正規の配布物とは確認できません。

デジタル署名の検証では、対応する秘密鍵による署名であることや、署名後のデータの変更を確かめます。信頼する署名者・鍵との対応、鍵の失効等も含め、適切に検証する必要があります。

それでも、署名されたプログラムに欠陥がないことは保証しません。署名前のビルド環境が侵害されたり、署名鍵を悪用されたりすれば、不正な内容に有効な署名が付くことがあります。署名の検証と、作成・署名工程の保護を組み合わせます。NIST SP 800-218、PO.5・PS.1・PS.2

更新を受け取る側にも、確認することがある

利用側では、正規の入手先、署名・整合性、対象製品と版、更新内容、適用条件を確認します。重要な更新では、検証環境、段階的な適用、戻す手順、適用後の監視を用意します。

ただし、慎重にすることを理由に、重大な脆弱性への対応を無期限に止めてよいわけではありません。悪用の状況、影響、暫定策、業務停止のリスクを合わせて判断します。判断の方法は支援士解説3の6で扱います。

外部から読み込む部品も、変更の入口になる

Webページが外部サービスからスクリプトを読み込む場合、自分たちのサーバーを更新していなくても、相手側の配布内容の変更が利用者へ影響することがあります。

外部へ依存する必要性、対象の版、変更の把握、配布元の信頼性、停止・変更時の影響を確認します。自組織へコピーして配布する方法に変えても、その後の脆弱性修正を自組織で追わなければ、別の問題が残ります。配布方式を変えると、更新を担う役割も変わります。

【図6】作る工程、署名する工程、受け取る側を守る

開発の工程（ソースコードの管理、ビルド、CI/CD）の守り方は支援士解説2の8で扱います。

午後での問われ方

• 令和7年度春期 午後問1（5.と同じ問題）：サプライチェーンのリスク対策として作成中のセキュリティガイドライン案（仕様と機能を精査し、不要な機能やセキュリティ上の欠陥がないことを設計書から確かめる項目）に取り入れた考え方として、解答例は「企画・設計工程からセキュリティ対策を組み込むという考え方」（セキュリティ・バイ・デザイン）です。

記述の型

• セキュリティ・バイ・デザイン：「企画・設計工程からセキュリティ対策を組み込む」
• 署名の確認で分かること：「配布物が、署名鍵を持つ者が署名した後に改ざんされていないこと」（署名の前の工程の侵害は見抜けない）

9. 契約後は、実施状況と変更を追い続ける

対策済みという回答を、要求事項へ対応付ける

履行確認は、契約で求めたことが実施されているかを確かめる作業です。資料の提出数だけでは判断できません。

例えば、月次報告に「セキュリティ対策実施」とある場合、求めた脆弱性の調査、未適用の修正、権限の点検、バックアップの結果、重大な変更等を確認できるかを見ます。項目は委託内容に合わせて選びます。

証跡は、実施した事実や経緯を確認するための記録です。いつ、何を対象に、誰が何を行い、どの結果になったかが分かる必要があります。別サービスの記録や、対象期間外の報告で代用していないかも確認します。

定期点検と、変更時の評価を使い分ける

定期点検は、継続的な実施や取り残しを確認する機会になります。ただし、次回まで待てない変更もあります。

• 取扱情報を増やす、又は機密性の高い情報を追加する。
• 保守権限や接続範囲を広げる。
• 再委託先、利用サービス、保管場所を変える。
• 製品の保守終了や、主要部品のサポート終了が近づく。
• 事故や重大な脆弱性、監査上の問題が判明する。

このような場合は、影響と新しい要求、必要な承認、契約変更の要否を評価します。作業者が独断で許可するのではなく、判断する責任者へつなぎます。

外から見える評価の限界

外部から確認できる公開サーバー等の情報は、評価の一材料になります。しかし、特定のIPアドレスの問題が、今回の契約対象と関係するかは確認が必要です。共有基盤や別事業の資産が含まれる場合があります。

外から良く見えることも、内部の権限管理やデータの取扱いまで適切である証明にはなりません。点数だけで採否を決めず、対象との対応、根拠、相手方の説明、改善状況を見ます。

指摘は、改善の完了まで追う

問題が見つかったら、内容、影響、暫定措置、改善担当、期限、完了の確認方法を決めます。

例えば、不要な保守アカウントが残っていたなら、まず利用を制限し、削除・停止の結果を確認します。その後、退職や担当交代の通知が届かなかった理由を調べ、元請・再委託先・発注側の手続を直します。

「次から気を付ける」という回答だけでは、今ある問題は消えません。期限を過ぎた場合や、対策できない場合のエスカレーション先も決めます。残るリスクを受け入れるなら、その権限を持つ者が、理由・条件・見直し時期を明確にして判断します。

監査の権利と、実際に確認できる方法

監査の進め方は支援士解説1の5で扱います。

契約に監査条項があっても、対象範囲や実施手順が未調整なら、必要な時期に確認できないことがあります。

共用クラウドへ利用者が自由に立ち入る方法は、他の利用者の保護と両立しない場合があります。第三者報告、限定した資料、遠隔での説明、必要な追加確認など、対象に合う方法を合意します。

それで足りない重大な不確実性が残るなら、利用範囲を限定する、別のサービスを選ぶなどの判断が必要です。立入りができないから全て問題なし、又は必ず不適切、と両極端に決めません。

【図7】委託先管理は、選定から終了まで続く

記述の型

• 契約後の管理：「委託先の契約の順守状況を、報告と定期的な監査で確認する」
• 変更時の評価：「担当会社・拠点・システムの変更のたびに、要求事項への影響を評価する」

10. 事故と契約終了のときに、業務と情報を守る

事故時は、委託先の復旧報告を待つだけにしない

委託先から侵害の疑いを連絡された場合、発注側では、どの情報と接続、どの業務に影響するかを確認します。

本稿の運用例として、元請の窓口へ情報を集約し、接続を制限する担当、業務の停止・継続を判断する担当、証跡を保全する担当、住民等への説明を検討する担当を決めます。状況に応じた権限と手順が必要です。

相手側がサービスを再開しただけで、自組織も再接続してよいとは限りません。原因への対処、侵害された認証情報の扱い、データの完全性、監視の条件、業務再開の承認を確認します。

法令上の報告・通知と契約上の連絡を区別し、発注側と受注側のどちらが何を行うかを整理します。責任の議論が終わるまで被害拡大防止を待つ、という順序にしないことが重要です。

サービスが止まったときの代替を、事前に試す

予約受付を外部サービスへ依存しているなら、一時的に電話等で受け付けることが可能か、重複予約をどう避けるか、復旧後にどう登録するかを決めます。これは架空の業務例であり、どの業務にも同じ代替手段を勧めるものではありません。

バックアップが提供されても、その形式を読み込めず、必要な設定や鍵も入手できないなら、移行に使えない可能性があります。何を出力し、どの環境で復元・利用できるかを確認します。

ベンダーロックインは、特定の事業者や製品への依存により、他へ移行することが難しくなる状態です。独自形式、契約条件、移行費用、技術的な制約などが関係します。依存の利点もあるため、排除だけを目的にせず、終了時の選択肢と負担を把握します。

契約終了は、情報を消す前に引き継ぐ

終了時には、移行先で必要なデータ・設定・記録を受け取り、利用できることを確認します。その上で、旧委託先の権限、接続、共有先、貸与物、データを整理します。

本稿の確認例は次のとおりです。

• データの形式、項目、対象期間、暗号鍵等の必要情報。
• 未完了の障害・脆弱性・改善事項、構成情報と連絡先。
• 旧委託先や再委託先のアカウント、APIキー、証明書、保守経路の停止・変更。
• 作業端末、媒体、複製、再委託先にある情報の返却・消去。
• 保存義務等で残す記録の範囲、保管者、利用制限、消去時期。

本番データだけ削除しても、バックアップや検証用コピーが残る場合があります。直ちに個別消去できないサービスでは、残存期間、復元時の扱い、アクセス制限、最終消去の方法を契約前に確認します。

完了証明にも、対象と方法が必要

消去証明書があっても、何のデータを、どの保存先から、どの方法で、いつ処理したかが分からなければ、判断材料として不十分です。

必要に応じた根拠を確認し、残る情報があれば理由と期限を記録します。契約終了日だけで判断せず、情報、権限、サービス、業務の引継ぎがそれぞれ終わったかを確かめます。

事故が起きたときの対応は支援士解説4の3で扱います。

記述の型

• 事故時の確認：「委託先の復旧報告を待つだけでなく、自組織の情報への影響、再開の条件、残る作業を確かめる」
• 契約終了時：「情報の返却・消去を、対象と方法を示した証明で確認し、委託先のアカウントと接続経路を止める」

11. 対策の要求を、実行できる契約と適正な取引にする

セキュリティの要求にも、費用と作業が伴う

監視時間の延長、ログの保管、追加の脆弱性検査、SBOMの継続提供などには、設備・人員・運用の費用がかかります。

必要な要求を選定・見積りの段階で示し、責任と負担を協議します。契約後の追加要求なら、変更の必要性、範囲、費用、実施時期、既存の業務への影響を調整します。受託者が独断で実施を省くことも、発注者が何でも無償で追加できると考えることも適切ではありません。

取適法は、中小受託取引適正化法の通称で、中小の受託事業者との取引の適正化を図る法律です。

公正取引委員会の説明資料は、取引先へサイバーセキュリティ対策を要請する際の、内容・費用負担等と独占禁止法・取適法上の考え方を扱っています。要請方法によっては問題となるため、対策の目的が正当であることと、取引条件の妥当性を分けて確認します。公正取引委員会「サプライチェーン全体のサイバーセキュリティ向上のための取引先とのパートナーシップの構築に向けて」を踏まえた想定事例について（解説）

法令の適用は、契約相手と取引内容で確かめる

関係する法令は支援士解説3の11で扱います。

取引関連法規は、すべての発注者・受注者へ同じ条件で適用されるとは限りません。民間企業間の委託と自治体の調達を、同じ規定だけで説明しないことが必要です。

例えば取適法は、取引の類型や当事者の規模等によって適用関係を確認します。本稿では個々の契約への適用可否までは判定しません。自組織の契約担当・法務と、適用する法令、調達手続、契約条件を確認します。公正取引委員会「よくある質問コーナー（取適法）」

契約の名称が同じでも、何の完成を約束するか、どの事務をどの範囲で行うかは異なります。製品の売買、開発の請負、運用支援、クラウドの利用約款などに合わせて、納入・検収・報告・修正・責任の条件を整理します。

相手に要求するだけでなく、実施を支える

本稿の提案として、共通の要求事項や報告様式を整理し、対象業務に関係しない質問を減らします。発注側の承認が必要なら回答期限を設け、事故時には相手が使える連絡窓口を用意します。

必要な対策を下げるためではありません。要求の意味が伝わり、実施・確認できるようにするためです。発注側の承認待ちで修正が止まるなら、委託先への督促だけでは解決しません。双方の作業を一つの運用として設計します。

12. 午前II（科目A-2）で正誤を見分けるポイント

• 「サプライチェーン攻撃は、標的の組織を直接攻撃する手法である」→ 誤り。取引先や委託先、使っている製品・部品を経由する
• 「委託先がISMS認証を取得していれば、今回の業務の範囲も認証されている」→ 誤り。認証の範囲を確かめる
• 「再委託先にも、委託先に求めるのと同等の対策を求めさせる」→ 正しい
• 「SBOMは、ソフトウェアを構成する部品・版・依存関係などの一覧である」→ 正しい
• 「SBOMを受け取れば、そのソフトウェアに脆弱性がないことが証明される」→ 誤り。構成の情報であり、安全の証明ではない
• 「SCAは、使っているOSSを脆弱性の情報と照合する」→ 正しい
• 「デジタル署名を検証すれば、ビルドの前に混入した不正なコードも検出できる」→ 誤り。署名の後の改ざんを検出する
• 「SPDXとCycloneDXは、SBOMの形式である」→ 正しい
• 「契約が終了したら、委託先に渡した情報の扱いは委託先に任せればよい」→ 誤り。返却・消去を証明で確かめる

理解度チェック

本文の理解を確かめるためのオリジナル問題です。実際の過去問ではありません。

問1　認証を持つ委託先

開発委託先がISMS認証を取得しています。選定時の確認として適切なのはどれでしょうか。

• ア：認証があれば、全製品に脆弱性がないと判断する。
• イ：今回の業務・拠点が認証範囲に含まれるかと、個別要求への対応を確認する。
• ウ：再委託先も全て同じ認証範囲に含まれると判断する。
• エ：契約後の履行確認を全て省略する。

正解：イ。 認証の対象と、今回の業務が対応しているかを確認します。

アは管理体制の認証を製品の無欠陥保証と混同しています。ウは範囲を確認せず広げています。エは選定時の評価を、継続的な実施確認の代わりにしています。

問2　再委託への要求

夜間監視を再委託する提案がありました。必要な対応として適切なのはどれでしょうか。

• ア：元請が責任を持つと言ったため、作業範囲の確認は不要とする。
• イ：会社名を把握すれば、権限や情報の確認は不要とする。
• ウ：必要な要求を再委託先にも引き継がせ、実施状況の確認と報告を契約に含める。
• エ：元請と同じ製品を買えば、全ての要求を満たしたと扱う。

正解：ウ。 認める範囲と手続を確認した上で、要求と履行確認を先までつなぎます。

アは実態が不明のままです。イは情報と権限のリスクを確認できません。エは対策の目的と、使用する製品を混同しています。

問3　SBOMと脆弱性

ある部品の脆弱な版が、納品されたSBOMに記載されていました。次の判断として適切なのはどれでしょうか。

• ア：記載があるので、全端末が既に侵害されたと確定する。
• イ：SBOMを受領済みなので、修正は不要とする。
• ウ：部品名を一覧から削除して対応を終える。
• エ：対象製品・版と稼働場所を特定し、影響条件と供給者情報を確認して対応を判断する。

正解：エ。 構成情報を影響評価と対応へつなげます。

アは含有と侵害の事実を混同しています。イは情報の取得を対策の完了と混同しています。ウは実際のソフトウェアを変更せず、管理情報を不正確にしています。

問4　署名された更新

正規の署名が付いた更新プログラムに、不正な処理が混入していました。考えられるリスクと対策の組合せとして適切なのはどれでしょうか。

• ア：署名が有効なら不正な処理は存在しないので、調査を終える。
• イ：署名前のビルド環境や署名鍵の侵害も調べ、作成・署名工程の管理を確認する。
• ウ：署名の検証は常に無意味なので、今後は全て省略する。
• エ：更新ファイルと同じ場所にあるハッシュ値との一致だけで、全て安全と判断する。

正解：イ。 署名が検証できることと、内容が安全であることは別です。

アは保証する範囲を広げすぎています。ウは改ざん等の確認に役立つ対策まで捨てています。エは、基準値の信頼性や作成工程の問題を確認していません。

問5　外部スクリプト

自組織のWebサイトが、利用者のブラウザで動くスクリプトを提供元の会社のサーバから読み込んでいる。提供元のサーバが改ざんされた場合の影響を受けないようにする方法として、最も適切なものはどれか。

• ア：スクリプトを確認したうえでダウンロードし、自組織のサーバに配置して読み込む
• イ：提供元の会社に、セキュリティ対策を口頭で依頼する
• ウ：自組織のサーバのパスワードを変更する
• エ：SBOMを作成したので、追加の対応は不要とする

正解：ア。提供元のサーバから毎回読み込む構成をやめれば、提供元の改ざんの影響を受けません。エは、外から読み込むスクリプトがSBOMに載らない場合を見落としています。

実務と国・自治体では

実務では、仕様書の項目を増やすだけで確認する人がいない、保守用の接続が常時・全権限のまま残る、SBOMが納品時のフォルダに眠る、自動更新だから更新管理は要らないと考える、といった落とし穴があります。任せる範囲と、確かめる方法を一緒に決め、契約・承認・実際の確認を分けて記録します。大きな会社だから安全、小さな会社だから危険と、規模だけで決めつけないことも大切です。

政府機関等の統一基準は、委託の前・期間中・終了時の対策と、開発・運用保守を委託する場合の追加の対策を求めています。自治体向けのガイドラインも、委託契約の項目と履行の確認を例文で示し、機器等の調達ではサプライチェーンのリスクに対応する選定基準と仕様書の手引書が示されています。資料の位置付けは支援士解説1の1で整理しています。

まとめ

• 自組織の外から届くリスクは四つ。 接続からの侵入、預けた情報の漏えい、製品・部品への不正な混入、依存先の停止。
• 委託先は、選ぶ・契約する・確かめる・終える。 求めることは確認できる形で契約に書き、再委託先にも同等の対策を求めさせる。
• 部品は、使っているかをすぐ調べられるようにする。 SBOMとSCAを運用中も続け、外から読み込むスクリプトや連携サービスは資産として管理する。
• 作る工程と配布経路も守る。 署名は、署名の後の改ざんを見抜く仕組み。工程そのものの侵害にも備える。

さらに深く学ぶなら

この記事の範囲を超えて、仕組みをもっと深く知りたい人向けの本です（試験対策の本ではありません）。

• ソフトウェア透明性（Chris Hughesほか／翔泳社）：SBOMを含むソフトウェアサプライチェーンのセキュリティを、脅威と対策の両面から学べる

関連記事

• 前提：その製品、安全に使えますか？｜支援士解説2の2（製品・クラウドの選定と評価制度）
• あわせて読む：脆弱性対応の優先順位はどう決める？｜支援士解説3の6（脆弱性への対応）
• あわせて読む：本番と分ければ開発環境は安全？｜支援士解説2の8（開発の工程の保護）
• 次に読む：監査で何を確かめ、どう改善する？｜支援士解説1の5（監査の進め方）

2026年10月改訂：午後の出題例と記述の型を加え、OSS・依存ライブラリ・外部スクリプトの節を新設し、評価制度・開発工程・監査の詳細は関連する回へ移して、構成を見直しました。