これは何か
ソフトウェア部品表（SBOM）・脆弱性対応記録は、システムを構成するソフトウェアの部品を、機械的に集めた一覧（部品表）として持ち、公表された弱点（脆弱性）がその部品に当たるかを突き合わせ、当たったときの対応（直す・一時的に守る・受け入れる）を記録した成果物です。
DEV-005 使用ソフトウェア・依存関係一覧 が「人が管理する台帳」なら、この成果物は「機械が集める部品表と、弱点への対応の記録」です。部品の数は人が手で数えられる量を超えます。だから自動で集め、自動で突き合わせ、人は対応の判断と記録に集中します。世界で共有されている考え方では、部品表を SBOM（Software Bill of Materials）と呼びます。
なぜ作るか
- 部品の弱点が公表されたとき、影響の有無と範囲を数時間で答える
- 対応の判断（直す・一時的に守る・受け入れる）と、その理由・期限を記録に残す
- 直接使う部品だけでなく、部品が使う部品（間接の依存）まで見えるようにする
- 取引先や監査から「何を使っているか」を求められたときに、根拠のある一覧を出す
誰が使うか・いつ作るか
- 作る人：開発・CI/CD 基盤を担当する会社（部品表を自動で集める仕組み）と、各システムの開発の取りまとめ役（対応の判断）。セキュリティの責任者が全体を見る
- 使う人：セキュリティの担当、各ベンダーの開発者、運用の担当、監査に対応する人
- 一般的には、自動の流れ（DEV-003 自動テスト・自動配布構成）に部品表の生成と弱点の突き合わせを組み込み、配布のたびに更新します。対応の記録は、弱点が公表されるたびに追記します
- アステリア案件で部品表が作られたか、弱点の公表にどう対応したかは、正本に記載がありません。未確定
CASE FACTFROZEN正本に記載されたアステリア案件の事実
部品と弱点に関係する記載
- システムに SYS-09 開発・CI/CD基盤、SYS-10 AI開発エージェント、SYS-11 監視・ログ基盤 がある
- Vendor B クラウドブリッジの担当範囲に CI/CD、監視 が含まれる。Vendor A は新基幹アプリケーション、Vendor C は FIN-CORE、会計連携
- 成果物に DEV-005 使用ソフトウェア・依存関係一覧、SEC-005 セキュリティ評価報告書 がある
- P-012 石井 稔 — セキュリティ責任者
- セキュリティ例外承認は、AIへ最終委任しない事項
アステリア案件で使われた部品、公表された弱点への対応、対応の期限は、正本に記載がありません。未確定
主な項目
一般的には、2 つの部分で構成します。
部品表（自動で集める）
- 部品の識別：名前、版、提供元、種類（基盤、ライブラリ、道具、外部サービス）
- 依存の関係：どの部品がどの部品を使っているか（直接・間接）
- 使っている場所：どのシステムの、どの配布物に含まれるか
- 生成の記録：いつ、どの版の配布物から集めたか
脆弱性対応記録（人が判断し記録する）
- 弱点の識別：公表の識別子、公表日、深刻さの公表値
- 影響の判定：部品表との突き合わせの結果。当たる場所、使い方によって影響があるか
- 対応の判断：直す（版を上げる）、一時的に守る（機能の停止、通信の制限、検知の強化）、受け入れる（影響がない理由）。判断した人と日付
- 期限と状態：対応の期限、完了日、確認した人
教材用サンプル成果物の読み方を学ぶための例
教材用サンプル — 突き合わせの結果と対応の記録
この成果物は学習用サンプルです。FROZEN正本に記載されたCASE FACTと、成果物の読み方を学ぶための教材用サンプル値を区別して表示しています。
次の表は、記録の書き方を学ぶための例です。部品名は種類だけを書いた架空の例で、実在の製品や弱点を示すものではなく、アステリア案件の記録でもありません。
| 部品（教材上の例） | 版 | 依存 | 使っている配布物 | 集めた日 |
|---|---|---|---|---|
| 帳票を作る部品 Y | 2.8 | 直接 | 新基幹（請求の画面） | 今月 3 日の配布 |
| 日付を扱う部品 Z | 1.4 | 間接（Y が使用） | 新基幹（請求の画面） | 今月 3 日の配布 |
| 通信を扱う部品 W | 5.1 | 直接 | 連携基盤（取り込み処理） | 今月 1 日の配布 |
| 弱点（教材上の例） | 当たる部品 | 影響の判定 | 対応 | 期限 | 判断した人 | 状態 |
|---|---|---|---|---|---|---|
| 公表-A（深刻さ 高） | 部品 Z 1.4 | 当たる。請求の画面で日付の入力を受けている | 直す：部品 Y を 2.9 に上げ、Z を 1.5 にする | 公表から 7 日 | 新基幹の開発の取りまとめ役 | 完了（5 日目） |
| 公表-B（深刻さ 中） | 部品 W 5.1 | 当たるが、該当の機能は使っていない | 受け入れ：理由を記録し、次の定期更新で版を上げる | 次の定期更新 | セキュリティの責任者 | 受け入れ済み |
| 公表-C（深刻さ 高） | 部品 W 5.1 | 当たる。修正版がまだ提供されていない | 一時的に守る：該当の通信の経路を制限し、検知を強化。修正版が出たら直す | 修正版の提供から 3 日 | セキュリティの責任者 | 対応中 |
読み方
- 部品表が自動で集められ、配布のたびに更新されているか（手作業の一覧は必ず古くなる）
- 間接の依存が含まれているか
- 弱点ごとに「影響の判定」が、使い方まで見て書かれているか（当たる部品があっても、使っていない機能なら影響は違う）
- 対応が 3 種類（直す・一時的に守る・受け入れる）のどれかで、理由・期限・判断した人があるか
- 期限を過ぎて「対応中」のものが放置されていないか
書き方
- 自動の流れに、配布物から部品表を集める処理を組み込む
- 公表された弱点の情報と部品表を自動で突き合わせ、当たる候補を担当者に知らせる
- 候補ごとに影響を判定し、対応を決め、期限と判断した人を記録する
- 期限の管理を定例の会議で見る
- 受け入れた弱点は、定期的に（たとえば四半期ごとに）見直す
何を書いてはいけないか
- 弱点を突く具体的な手順（記録は守るための文書であり、攻撃の手引きではない）
- 「対応済み」だけで、何をしたか・誰が判断したかのない記録
- 受け入れの理由のない「受け入れ」（理由がなければ、それは放置）
- 実在の製品名を、案件の正式な採用として書くこと（正本に記載がない）
どこを見るか
- 部品表の自動生成と更新日
- 間接の依存の網羅
- 影響の判定の根拠
- 対応の種類・理由・期限・判断した人
- 期限切れの対応中
赤信号
- 弱点が公表されてから、影響の有無を答えるのに何日もかかる
- 部品表が手作業で、最後に更新されたのが稼働前
- 「受け入れ」の理由が書かれておらず、放置と区別がつかない
- 深刻さの高い弱点が、期限を過ぎても対応中のまま
よくある失敗
- 直接使う部品だけを見て「影響なし」と答え、間接の依存に当たる部品を見落とす
- 修正版が出るまで何もせず、一時的に守る手（経路の制限、検知の強化）を打たない
- 対応を各社がばらばらに行い、全体でどの弱点が残っているかを誰も把握していない
関係するUnit・成果物・危機演習
- Unit：09-08 使っている部品の安全をどう保つか、09-04 自動テストと自動配布、14-04 システムは完成しない、13-02 障害の重大度を判断する
- 成果物：DEV-005 使用ソフトウェア・依存関係一覧、DEV-003 自動テスト・自動配布構成、SEC-005 セキュリティ評価報告書、SEC-006 脅威モデル
- 危機演習：この成果物を直接の題材にする危機演習はありません
AI WORKFLOW
AIは、公表された弱点の説明文から「影響を受ける使い方の条件」を抜き出し、自分たちの使い方と照らす点検の下書きに役立ちます。
「次の弱点の公表文を読み、影響を受けるための条件（部品の版、使っている機能、設定）を箇条書きにしてください。添付の『使い方の説明』と照らして、条件ごとに該当するか・しないか・判断できないかを示してください。対応方針を提案したり、深刻さを評価し直したりしないでください。」
REVIEW
- AIが抜き出した条件が、公表文に実際に書かれているか
- 「判断できない」とされた条件を、開発者が実際の使い方を見て確かめたか
- 使い方の説明を AI に渡してよいか（構成情報の扱い）を事前に確かめたか
人間が判断すること
- 対応の種類（直す・一時的に守る・受け入れる）と期限
- 受け入れの理由と、見直しの時期
- 修正版を急いで入れることで業務が止まる危険と、弱点を残す危険の比較
セキュリティ例外承認は、AIへ最終委任しない事項です（正本の方針）。
いつ使うか
この教材では STAGE 09｜120人で安全に開発する の文脈で扱います。 アステリア案件での正式な作成・使用時期（月）は正本に記載がないため、未確定としています。
最後の問い
ある部品の弱点が公表された日に、この記録を見た担当者は、「影響するシステムはどれで、いつまでに、誰が、どう直すか。直せない場合に何で守るか」を、その日のうちに決められますか？