午前I問題
ソフトウェアサプライチェーンにおけるセキュリティリスクの説明として、適切なものはどれか。
ア）自社が開発したソースコードに含まれるロジックの欠陥のみを指し、外部から取得したライブラリは対象外である。
イ）ビルドツールやCI/CDパイプライン、利用するOSSライブラリなど、ソフトウェアが完成するまでに関与するすべての要素が攻撃対象となり得るリスクである。
ウ）サプライチェーン攻撃は物流業や製造業のみに存在するリスクであり、ソフトウェア開発には適用されない概念である。
エ）商用ソフトウェアのみが対象であり、OSS（オープンソースソフトウェア）を利用しない限り発生しないリスクである。
午前I の解答・解説を見る
正解： イ）
解説：
- ア）不正解。サプライチェーンリスクは自社コードに限定されず、外部から取得するライブラリ・コンポーネント・ビルド環境なども含む広範な概念である。
- イ）正解。ソフトウェアサプライチェーンは、依存ライブラリの取得元、ビルドツール、CI/CDパイプライン、パッケージレジストリなど、開発から配布までの一連のプロセスに関与する要素全体を指す。近年はSolarWinds事件やCodecov事件のように、ビルドプロセスやCI/CD環境を侵害して不正なコードを混入させる攻撃が増加している。
- ウ）不正解。サプライチェーン攻撃の概念はソフトウェア開発にも適用され、実際に近年最も注目される攻撃パターンの一つである。
- エ）不正解。商用ソフトウェアもOSSコンポーネントを内包していることが多く、また商用ソフトウェア自体の配布経路（アップデートサーバなど）が侵害される事例もあるため、OSS利用の有無に関わらずリスクは存在する。
午前II問題
SBOM（Software Bill of Materials）に関する記述のうち、最も適切なものはどれか。
ア）SBOMはソフトウェアの実行速度やメモリ使用量などのパフォーマンス指標を記録した文書であり、脆弱性管理には利用できない。
イ）SBOMはソフトウェアに含まれるコンポーネント（ライブラリ、パッケージ、バージョン情報等）を一覧化した部品表であり、CycloneDXやSPDXといった標準形式で表現される。
ウ）SBOMの作成はソースコードを保有するベンダーのみが可能であり、利用者側で生成・検証することはできない。
エ）SBOMには依存関係のバージョン情報を含めることができないため、脆弱性データベースとの突合には別途手作業での棚卸しが必須である。
午前II の解答・解説を見る
正解： イ）
解説：
- ア）不正解。SBOMはパフォーマンス指標ではなく、ソフトウェアを構成するコンポーネントの一覧（部品表）である。含まれるコンポーネント名・バージョン・ライセンス・依存関係などの情報を用いて、既知の脆弱性（CVE）との突合が可能であり、脆弱性管理の基盤情報として活用される。
- イ）正解。SBOMは直接・間接を問わずソフトウェアに含まれる構成要素を一覧化した文書であり、代表的な標準形式にCycloneDX（OWASP策定）とSPDX（Linux Foundation策定）がある。米国大統領令14028を契機に、政府調達ソフトウェアへのSBOM添付が求められるなど普及が進んでいる。
- ウ）不正解。SBOMはビルドツールやパッケージマネージャの依存関係情報から自動生成できるため、ソースコード開発者だけでなく利用者側（SCAツール等を用いて）でも生成・検証が可能である。
- エ）不正解。SBOMにはコンポーネントのバージョン情報が含まれるのが標準的であり、これをCVEデータベースやOSV等の脆弱性情報源と機械的に突合することで、手作業の棚卸しを削減できる点がSBOM活用の主要なメリットである。
午後問題
D社は自社の基幹業務システムをWebアプリケーションとして開発・運用しているソフトウェアベンダーである。同システムは多数のOSSライブラリに依存しているが、これまで依存パッケージの脆弱性管理は開発者個人の裁量に任されており、組織的な管理体制が存在しなかった。
ある日、業界内で広く利用されているログ出力ライブラリに深刻なリモートコード実行（RCE）の脆弱性が公表され、CVSS基本値が最高レベルと評価された。D社のセキュリティ部門はE氏を中心に緊急対応チームを立ち上げたが、次の課題に直面した。
- どの製品・システムが当該ライブラリを直接的または間接的に利用しているか、正確に把握できていない
- ライブラリはアプリケーションに直接組み込まれているものだけでなく、他の依存ライブラリが内部で利用している「推移的依存（transitive dependency）」としても含まれている可能性がある
- 影響範囲の特定に3日を要し、その間に一部の公開サーバが実際に攻撃を受けた形跡が確認された
この事態を受け、E氏は再発防止策として、SBOMの導入とSCA（Software Composition Analysis）ツールの活用を含む恒久対策を提案することにした。
設問1
E氏が今回のインシデント対応において影響範囲の特定に3日を要した根本的な原因を、「推移的依存」という語を用いて40字以内で述べよ。また、この課題を解決するために平時から準備しておくべき対策を1つ挙げよ。
設問1の解答・解説を見る
正解例：
- 原因：どの製品が推移的依存を含め当該ライブラリを利用しているか把握する仕組みがなかったため。（39字）
- 対策：全製品についてSBOMを事前に生成・管理し、コンポーネントの依存関係（直接・推移的依存を含む）を常時把握できる体制を整備しておく。
解説： 推移的依存とは、自社が直接組み込んだライブラリがさらに内部で利用している別のライブラリのことで、開発者が意識せずに取り込んでいるケースが多い。今回のようなライブラリ単位の脆弱性が公表された際、直接依存だけでなく推移的依存まで含めて洗い出す必要があるが、事前にSBOMが整備されていなければ、緊急時に手作業でソースコードや依存関係定義ファイル（package.json、pom.xml等）を1件ずつ確認することになり、対応が大幅に遅延する。SBOMを平時から生成・一元管理しておくことで、緊急時に脆弱性のあるコンポーネント名・バージョンをキーに即座に影響製品を検索できる。
解説・採点基準（計15点）：
| 採点項目 | キーワード | 配点 |
|---|---|---|
| 原因の指摘 | 「推移的依存を含めた利用状況を把握する仕組みがない」旨 | 6点 |
| 原因の指摘（補足） | 「直接依存だけでなく間接的な依存も対象」という認識 | 2点（原因に含まれていれば加点） |
| 対策の提示 | SBOMを平時から生成・管理する旨 | 5点 |
| 対策の具体性 | 「依存関係を常時把握」「緊急時に迅速検索可能」等の効果への言及 | 2点 |
40字を超過している場合や、原因が「担当者不足」など体制論のみで技術的根拠（推移的依存の把握不足）に触れていない場合は原因欄を0〜2点とする。
設問2
E氏はSBOMの導入に加えて、SCA（Software Composition Analysis）ツールをCI/CDパイプラインに組み込むことを提案した。SCAツールをパイプラインに組み込むことで得られる効果を、SASTとの違いに触れながら60字以内で述べよ。
設問2の解答・解説を見る
正解例： SASTは自社コードの脆弱性を検出するのに対し、SCAは依存OSSの既知脆弱性・ライセンス違反を自動検出し、混入を早期に防止できる。（59字）
解説： SAST（Static Application Security Testing）は自社が記述したソースコードそのものの脆弱性（バグやロジック欠陥）を静的解析で検出するのに対し、SCA（Software Composition Analysis）は利用している依存パッケージ・OSSコンポーネントを解析し、既知の脆弱性データベース（CVE、OSV等）やライセンス条項との突合を行う。両者は検出対象が異なるため、CI/CDパイプラインには双方を組み込むことが望ましい。SCAをビルド時に組み込むことで、脆弱性のあるバージョンのライブラリを取り込んだ時点で検知し、本番環境へのデプロイ前に修正できる（シフトレフト）。
解説・採点基準（計15点）：
| 採点項目 | キーワード | 配点 |
|---|---|---|
| SASTとの対比 | 「SASTは自社コード、SCAは依存パッケージ（OSS）」の区別に言及 | 6点 |
| SCAの検出内容 | 「既知の脆弱性」または「ライセンス」への言及 | 5点 |
| 効果 | 「早期発見」「デプロイ前に防止」「シフトレフト」等への言及 | 4点 |
「SCAとSASTは同じもの」「SCAはソースコードのロジック欠陥を検出する」など対象の混同がある場合はSASTとの対比欄を0点とする。60字超過は減点対象とはしないが、簡潔さも評価観点とする。
重要キーワード
| 用語 | 説明 |
|---|---|
| ソフトウェアサプライチェーン攻撃 | ビルドツール・CI/CD・依存ライブラリなど、ソフトウェア開発・配布プロセスの一部を侵害して不正コードを混入させる攻撃 |
| SBOM（Software Bill of Materials） | ソフトウェアに含まれるコンポーネントの一覧を記載した部品表。CycloneDX・SPDXなどの標準形式がある |
| SCA（Software Composition Analysis） | 依存OSSコンポーネントを解析し、既知の脆弱性やライセンス条項との適合性を検査するツール・手法 |
| 推移的依存（transitive dependency） | 直接組み込んだライブラリが内部でさらに利用している間接的な依存関係 |
| CVE（Common Vulnerabilities and Exposures） | 公開された既知の脆弱性に一意の識別番号を付与する共通識別子 |
| シフトレフト | セキュリティ検査を開発ライフサイクルの早い段階（コミット・ビルド時）に組み込む考え方 |
まとめ
- 午前I視点： サプライチェーンリスクは自社コードに限らず、ビルド環境・CI/CD・依存ライブラリを含む開発から配布までの全プロセスが対象になるという広い定義を理解する。
- 午前II視点： SBOMはコンポーネントの部品表であり、CycloneDX・SPDXという標準形式名、および脆弱性管理・ライセンス管理への活用方法をセットで押さえる。
- 午後視点： 推移的依存を含めた依存関係の可視化にはSBOMの平時からの整備が不可欠。SASTが自社コード、SCAが依存パッケージを対象とする違いを、CI/CDパイプラインへの組み込みタイミングと合わせて説明できるようにする。