基幹システム刷新におけるリリース前脆弱性診断の省略提案と再委託先の管理
C社（従業員2,300名、全国12拠点の物流会社）は、稼働から18年となる基幹の輸配送管理システムを刷新する。調達形態はパッケージ製品のカスタマイズで、受注生産部分が全体の約35%を占める。一次請けのX社が設計・開発を、Y社が運用保守を担当する。X社は開発工数の約4割を海外の再委託先Z社に割り当てる予定で、契約書には再委託の事前承諾とセキュリティ要件の一部が記載されているが、Z社の名称・所在国は明示されていない。リリース予定は3か月後である。X社からの見積にはWebアプリケーション診断とプラットフォーム診断が含まれていたが、コスト削減のため「診断はリリース後に1回だけ実施する」とする変更提案が出ている。また、C社のセキュリティ担当が確認したところ、設計書にはOSSの利用一覧がなく、X社は「脆弱性情報は都度確認している」と口頭で説明している。検収条件には「機能要件を満たすこと」としか記載されておらず、セキュリティに関する合格基準は未定義である。C社の情報セキュリティ部は3名体制で、開発プロジェクトに専任で張り付ける余力はない。
1. 脆弱性診断をリリース後の1回だけに変更する提案を受け入れるべきか。判断と理由、および受け入れる場合に必要となる条件を示せ。
Read the worked answer
結論：そのまま受け入れるべきではない。
理由
- リリース後に発見した脆弱性は、稼働中のシステムを止めずに修正・再テストする必要があり、結果として修正コストと手戻りが大きくなる。設計工程に戻る修正は、リリース前の数倍の工数になる。
- プラットフォーム診断はOS・ミドルウェアの設定不備を見るもので、認可制御の欠陥やSQLインジェクションといった実装上のロジック脆弱性は検出できない。リリース後1回では検出範囲が不足する。
- 受注生産部分が35%あり、パッケージ標準機能の範囲外＝独自実装に脆弱性が集中しやすい。
現実的な代替案（リスクベース）
- 全機能一律ではなく、認証・権限管理・外部連携API・個人情報を扱う画面に絞ってリリース前に診断を実施する。
- 残りの機能はリリース後30日以内に診断し、修正完了までの間はWAFと監視で緩和する。
受け入れる場合の必須条件 ①経営層による残留リスクの正式な受容と記録、②WAF・ログ監視など暫定緩和策の実施、③リリース後診断の期限と、発見時の修正完了条件を契約に明記（未完了なら検収しない）、④診断費用は削減対象から除外する。
2. 再委託先Z社に関して、C社が契約上・管理上講ずべき措置を具体的に述べよ。
Read the worked answer
契約上の措置
- 再委託の特定と事前承諾：Z社の名称、所在国、担当工程、取扱データの範囲を書面で特定し、変更時は再承諾を要する条項とする。
- バックツーバック：C社がX社に課したセキュリティ要件（アクセス制御、暗号化、インシデント通知、再委託先の監督、監査立入り、データの返還・消去）をZ社まで及ぼす。
- 越境移転の適法性：個人情報を含むデータを外国にある第三者に扱わせる場合、個人情報保護法第28条の本人同意または基準適合体制の整備が必要。第25条の委託先監督義務もX社を通じて履行させる。
- 監査権と報告義務：C社がZ社へ直接またはX社同席で立入調査できる権限、定期報告の頻度を定める。
管理上の措置
- Z社のセキュリティ体制を質問票とリモート確認で事前評価し、結果を調達判断に反映する。
- 開発環境を分離し、本番データを開発系に持ち込ませない（テストデータはマスキング）。
- 退職者・異動者のアカウント削除、ソースコードの持ち出し制限、USB等の媒体管理を確認する。
- 3名体制のC社は全量監査が難しいため、重要度の高い項目に絞ったチェックリストと、X社の自己点検結果の提出＋抜取り確認で実効性を確保する。
3. 検収基準に組み込むべきセキュリティ要件と、OSSの脆弱性管理の進め方を示せ。
Read the worked answer
検収基準に組み込む項目
- リリース前に合意した範囲の脆弱性診断が完了していること。
- 診断で検出された脆弱性のうち、CVSS基本値が高いもの（例：7.0以上）が残存していないこと。残存する場合は、リスク評価と受容の承認、緩和策が提示されていること。
- **SBOM（ソフトウェア部品表）**の提出：利用OSSの名称・バージョン・ライセンス・既知脆弱性の有無。
- 脆弱性対応手順書の提出と、運用保守（Y社）への引き継ぎが完了していること。
OSSの脆弱性管理の進め方
- 口頭説明では検証できないため、ビルド時に自動生成されるSBOMを成果物とする。
- 依存関係のスキャンをCIに組み込み、CVE／JVN等信息源の監視と、深刻度に応じた修正SLA（例：Criticalは7日以内）を契約に定める。
- ライセンス（GPL等のコピーレフト）の確認も併せて行う。ライセンス違反は法務リスクとして別途評価が必要。
- 検収後も、運用保守フェーズで誰が脆弱性情報を監視し、誰がパッチ適用を判断するかをRACIで明確にする。C社の3名体制では、X社・Y社の責任分界を契約で固定することが実効性の担保になる。