午前I問題
ソフトウェア開発におけるサプライチェーンリスクに関する記述のうち，適切なものはどれか。
ア）自社開発のソースコードのみをセキュリティ検査の対象とすれば，利用しているOSSライブラリの脆弱性リスクは考慮しなくてよい イ）ソフトウェアサプライチェーン攻撃とは，開発・配布プロセスの一部（ビルドツールや依存ライブラリ等）を侵害し，最終製品の利用者に被害を及ぼす攻撃手法である ウ）OSSライブラリは無償で公開されているため，商用ソフトウェアと比較して脆弱性が発見されるリスクは存在しない エ）依存関係にあるライブラリの脆弱性は，自社開発コードの脆弱性と異なり，製品全体のセキュリティに影響を及ぼすことはない
午前I の解答・解説を見る
正解： イ
解説：
- ア）不正解。現代のソフトウェアは多数のOSSライブラリに依存しており，自社コードのみの検査では依存ライブラリの脆弱性を見落とし，製品全体のリスクを見誤ることになる。
- イ）正解。ソフトウェアサプライチェーン攻撃は，SolarWinds事件やlog4j脆弱性の悪用に代表されるように，開発・配布プロセス中の一部（依存ライブラリ，ビルドツール，パッケージリポジトリ等）を侵害することで，最終的に多数の利用者に被害を波及させる攻撃手法である。
- ウ）不正解。OSSは誰でもソースコードを閲覧できる分，脆弱性が発見・公表されやすい面もあり，「脆弱性が発見されるリスクは存在しない」は誤り。むしろ利用実態の把握が難しいことがリスクとなる。
- エ）不正解。依存ライブラリの脆弱性（例：log4jのRCE脆弱性）が製品全体に重大な影響を及ぼした事例は多数あり，「影響を及ぼすことはない」は明確な誤り。
午前II問題
SBOM（Software Bill of Materials，ソフトウェア部品表）に関する記述のうち，最も適切なものはどれか。
ア）SBOMは製品の販売価格やライセンス費用を一覧化した財務文書であり，セキュリティ管理を主目的とするものではない イ）SBOMは，ソフトウェア製品を構成するコンポーネント（OSSライブラリ等）とそのバージョン・依存関係を記載した目録であり，脆弱性管理やライセンス管理に活用される ウ）SBOMの標準フォーマットとしてSPDXやCycloneDXが存在するが，これらは相互に互換性がなく，一方から他方への変換は技術的に不可能である エ）SBOMは一度作成すれば製品のライフサイクルを通じて更新する必要はない
午前II の解答・解説を見る
正解： イ
解説：
- ア）不正解。SBOMは財務文書ではなく，ソフトウェアの構成要素を可視化しセキュリティ・ライセンス管理に活用する技術文書である。
- イ）正解。SBOMはソフトウェア製品に含まれるコンポーネント（OSSライブラリ，商用コンポーネント等）の名称・バージョン・依存関係・ライセンス情報等を記載した部品表であり，既知の脆弱性（CVE等）が含まれるコンポーネントの特定やライセンスコンプライアンスの確認に活用される。
- ウ）不正解。SPDXとCycloneDXは代表的なSBOM標準フォーマットであり，両者間の相互変換をサポートするツールが存在する。「変換は技術的に不可能」は誤り。
- エ）不正解。ソフトウェアは新たなバージョンリリースや依存ライブラリの更新によって構成が変化するため，SBOMはライフサイクルを通じて継続的に更新することが推奨される。
午後問題
V社はIoT機器メーカーであり，自社製品の組込みソフトウェアに多数のOSSライブラリを利用している。近年，取引先の大手企業から「納品する製品についてSBOMの提出」を求められたことを契機に，SBOMの生成・管理プロセスを整備することになった。開発担当のEさんは以下の方針を検討している。
- SBOM生成：ビルドプロセスにSBOM自動生成ツールを組み込み，製品リリースのたびにCycloneDX形式のSBOMを生成する
- 脆弱性監視：生成したSBOMをもとに，既知の脆弱性データベース（NVD等）と突合し，利用中のコンポーネントに新たな脆弱性が公表された場合にアラートを受け取る仕組みを導入する
- 運用課題：ある製品のSBOMを確認したところ，同一のOSSライブラリについて，直接利用しているバージョンとは別に，他のライブラリが依存する形で異なるバージョンが混在していることが判明した
設問1
製品リリースのたびにビルドプロセスへSBOM自動生成ツールを組み込むことのセキュリティ上の利点を，手作業でのSBOM作成と比較して50字以内で述べよ。
設問1の解答・解説を見る
正解例： 手作業による記載漏れや更新遅延を防ぎ，実際のビルド構成と一致した正確なSBOMを常に最新の状態で維持できる（50字）
解説・採点基準（計15点）：
| 採点項目 | キーワード | 配点 |
|---|---|---|
| 正確性への言及 | 「記載漏れの防止」「実際の構成と一致」 | 6点 |
| 最新性への言及 | 「更新遅延の防止」「常に最新の状態」 | 6点 |
| 手作業との比較の明確さ | 手作業の課題（漏れ・遅延）との対比が明示されている | 3点 |
手作業でのSBOM作成は，依存ライブラリの追加・更新のたびに記載更新が必要となり，人為的ミスや更新漏れが発生しやすい。ビルドプロセスへの自動組み込みにより，実際にビルドされた構成を正確かつリアルタイムに反映したSBOMを継続的に維持でき，脆弱性管理の精度が向上する。
設問2
同一のOSSライブラリについて，直接利用しているバージョンとは別に，他のライブラリが依存する形で異なるバージョンが混在していることが判明した。この状況が脆弱性管理にもたらすリスクを，「推移的依存」という語を用いて60字以内で述べよ。
設問2の解答・解説を見る
正解例： 推移的依存によって混在する旧バージョンに脆弱性が存在する場合，直接依存の対応のみでは見落とされ，脆弱性が放置されるリスクがある（63字→短縮：推移的依存で混在する旧バージョンの脆弱性は，直接依存の対応だけでは見落とされ放置されるリスクがある（52字））
解説・採点基準（計15点）：
| 採点項目 | キーワード | 配点 |
|---|---|---|
| 推移的依存の説明 | 「推移的依存」を用いてバージョン混在の原因を説明 | 6点 |
| 見落としリスクへの言及 | 「直接依存のみの対応では見落とされる」等 | 6点 |
| 具体性 | 「脆弱性の放置」等，結果として生じる問題への言及 | 3点 |
SBOMには自社が直接指定する「直接依存」だけでなく，依存ライブラリがさらに依存する「推移的依存（間接依存）」のコンポーネントも含まれる。同一ライブラリでも直接依存と推移的依存とでバージョンが異なるケースは珍しくなく，直接依存のみを脆弱性対応の対象とすると，推移的依存側に混在する旧バージョンの脆弱性が見落とされ，放置されるリスクがある。SBOMによる完全な可視化と依存関係全体の脆弱性突合が重要となる。
重要キーワード
| 用語 | 説明 |
|---|---|
| SBOM | Software Bill of Materials。ソフトウェアを構成するコンポーネントとその依存関係・バージョン・ライセンス情報を記載した部品表 |
| ソフトウェアサプライチェーン攻撃 | 開発・配布プロセスの一部（依存ライブラリ，ビルドツール等）を侵害し，最終製品の利用者に被害を及ぼす攻撃手法 |
| SPDX / CycloneDX | 代表的なSBOMの標準フォーマット。相互変換をサポートするツールが存在する |
| 推移的依存（間接依存） | 直接利用するライブラリがさらに依存する別のライブラリ。直接依存とは異なるバージョンが混在することがある |
| 脆弱性データベース（NVD等） | 公開された脆弱性情報（CVE）を集約したデータベース。SBOMと突合して既知脆弱性の有無を確認する際に利用される |
| ライセンスコンプライアンス | 利用するOSSライブラリのライセンス条項を遵守すること。SBOMはライセンス管理の観点でも活用される |
まとめ
- 午前I視点： ソフトウェアサプライチェーン攻撃の定義と，依存ライブラリの脆弱性が製品全体に影響を及ぼす具体的なリスクを理解する
- 午前II視点： SBOMの目的（脆弱性管理・ライセンス管理）と標準フォーマット（SPDX・CycloneDX）の相互運用性を正確に把握する
- 午後視点： SBOM自動生成の利点と，推移的依存によるバージョン混在が脆弱性管理の見落としにつながるリスクを説明できる力を養う