このユニットの結論
いまのシステムは、自分たちで書いたプログラムより、世の中の部品（ライブラリ、基盤のソフト）の方が多い。
何を使っているかを機械的に集め（部品表）、公表された弱点と自動で突き合わせ、当たったら「直す・一時的に守る・受け入れる」のどれかを期限と理由つきで決めて記録する。部品の数は人が覚えられる量を超えています。だから仕組みで保ちます。
1. 何の話か
このユニットは、システムが使っている部品の安全を、どう保ち続けるかの話です。
09-04 自動テストと自動配布 で学んだ自動の流れは、自分たちのプログラムを確かめます。しかし、プログラムは世の中の部品を何百と組み合わせて動きます。部品のどれか 1 つに弱点（脆弱性）が公表されると、それを使っているすべての場所が影響を受けます。部品の安全は、作るときだけでなく、使い続ける間ずっと保つものです。
2. なぜ必要か
仕組みがないと、
- 弱点が公表されても、自分たちが使っているかどうかを答えるのに何日もかかる
- 直接使っている部品だけを見て「影響なし」と答え、部品の部品（間接の依存）に当たるものを見落とす
- 修正版が出るまで何もせず、一時的に守る手を打たない
- 保守の終わった部品が本番で動き続けていることに、誰も気づかない
ということが起きます。弱点の公表は、こちらの都合に関係なく、ある日突然来ます。
3. このユニットで分かること
- 部品表（SBOM）を機械的に集める理由
- 弱点が公表されたときの 3 つの対応
- 受け入れを放置と区別する方法
4. 部品表を機械的に集める
人が手で書いた一覧は、作った瞬間から古くなります。部品は配布のたびに変わるからです。そこで、配布物から部品の一覧を自動で生成します。世界で共有されている考え方では、この一覧を SBOM（ソフトウェア部品表）と呼びます。
部品表に必要なのは、部品の名前と版、依存の関係（どの部品がどの部品を使っているか。直接か間接か）、使っている場所（どのシステムのどの配布物か）、集めた日です。自動の流れに組み込めば、配布のたびに最新になります。人が管理する一覧（DEV-005 使用ソフトウェア・依存関係一覧）は、部品表に「責任者」「更新の方針」を足した台帳として、部品表と突き合わせて保ちます。
5. 弱点が公表されたときの 3 つの対応
| 対応 | 内容 | 選ぶ場面（一般的な例） | 記録すること |
|---|---|---|---|
| 直す | 部品の版を上げる、または置き換える | 修正版があり、上げても業務が止まらないと確かめられる | 上げた版、確かめた方法、完了日 |
| 一時的に守る | 該当の機能を止める、通信の経路を制限する、検知を強化する | 修正版がまだない、または上げると業務が止まる恐れがある | 守り方、守っている間の危険、修正版が出たあとの期限 |
| 受け入れる | 当たる部品はあるが、使い方からして影響がないと判断する | 弱点の条件に当たる機能や設定を使っていない | 影響がない理由、判断した人、見直しの時期 |
3 つのどれかを、期限と判断した人とともに記録します（DEV-006 ソフトウェア部品表（SBOM）・脆弱性対応記録）。受け入れを放置と区別するのは、理由と見直しの時期の有無です。理由のない受け入れは放置です。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件の部品と弱点に関する記載
- システムに SYS-09 開発・CI/CD基盤、SYS-10 AI開発エージェント、SYS-11 監視・ログ基盤 がある
- Vendor B クラウドブリッジの担当範囲に CI/CD、監視 が含まれる。Vendor A は新基幹アプリケーション、Vendor C は FIN-CORE、会計連携
- 成果物に DEV-005 使用ソフトウェア・依存関係一覧、DEV-006 ソフトウェア部品表（SBOM）・脆弱性対応記録、SEC-005 セキュリティ評価報告書 がある
- P-012 石井 稔 — セキュリティ責任者
- セキュリティ例外承認は、AIへ最終委任しない事項
アステリア案件で使われた部品、公表された弱点への対応、対応の期限は、正本に記録がありません。記録なし
6. THINK — 「その部品は使っていないので影響なし」
ある部品の弱点が公表され、セキュリティの責任者が各社に影響を問い合わせました。新基幹の開発の取りまとめ役が、次のように答えました。
「その部品は、私たちのプログラムでは直接使っていません。影響なしです。」
問題
この回答で、影響なしと結論づけてよいでしょうか。
判断例を開く
判断
「直接使っていない」は、「使っていない」ではありません。
確認すること:
- 部品表で、間接の依存（使っている部品が、その部品を使っている）を調べたか
- 部品表は最新の配布物から集めたものか（古い部品表なら、答えも古い）
- 弱点の条件（版、機能、設定）と、自分たちの使い方を照らしたか
- 新基幹以外のシステム（連携基盤、監視、開発の道具）は調べたか
- 「影響なし」を記録し、判断した人と理由を残したか
部品表が機械的に集められていれば、この確認は数分で終わります。なければ、「直接使っていない」という記憶に頼った回答が、数週間後に覆ります。
7. よくある失敗
- 部品の一覧を手作業で作り、配布のたびに古くなる
- 直接の依存だけを見て、間接の依存を見落とす
- 修正版が出るまで何もせず、一時的に守る手を打たない
- 受け入れの理由を残さず、放置と区別がつかない
8. 成果物との接続
- DEV-006 ソフトウェア部品表（SBOM）・脆弱性対応記録：機械的に集めた部品表と、弱点ごとの対応の記録
- DEV-005 使用ソフトウェア・依存関係一覧：部品ごとの責任者と更新の方針を持つ台帳。部品表と突き合わせて保つ
9. AI WORKFLOW — 弱点の条件と使い方を照らさせる
AIは、公表された弱点の説明文から「影響を受ける条件」を抜き出し、自分たちの使い方と照らす点検の下書きに役立ちます。
指示例:
「次の弱点の公表文を読み、影響を受けるための条件（部品の版、使っている機能、設定）を箇条書きにしてください。添付の『使い方の説明』と照らして、条件ごとに該当するか・しないか・判断できないかを示してください。対応方針を提案したり、深刻さを評価し直したりしないでください。」
10. REVIEW — AIの照合を確認する
- AIが抜き出した条件が、公表文に実際に書かれているか
- 「判断できない」とされた条件を、開発者が実際の使い方を見て確かめたか
- 使い方の説明を AI に渡してよいか（構成情報の扱い）を事前に確かめたか
11. 人間が判断すること
- 対応の種類（直す・一時的に守る・受け入れる）と期限
- 受け入れの理由と、見直しの時期
- 修正版を急いで入れる危険と、弱点を残す危険の比較
セキュリティ例外承認は、AIへ最終委任しない事項です（正本の方針）。
12. 判断演習
あなたの職場で使っている道具（表計算ソフト、ブラウザ、業務システムのどれか）に弱点が公表された、と想像してください。
「使っているか」を誰がどうやって確かめるか、「直す・一時的に守る・受け入れる」のどれを選ぶか、その理由と期限を書いてください。そのうえで、「間接の依存」に当たるものが身の回りにないか、1 つ考えてみてください。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
部品の安全は仕組みで保つ。部品表を機械的に集め、弱点と自動で突き合わせ、直す・一時的に守る・受け入れるを期限と理由つきで記録する。理由のない受け入れは放置。