本書の目的
Claude Mythosなどの自立型のセキュリティ診断や攻撃が可能なAIが出回り、ITセキュリティ対策が変容しつつあります。本ポストでは、クラウドエンジニアである私や私の友人たちが考えている対策の優先度や危機感を共有します。あくまで個人の感じた内容で記載していますので、網羅性や客観性が欠けていると思います。共有したいのは、今やらないことをきっちり諦めないと、やるべきことが間に合わないのではという危機感です。高性能AIの普及速度を踏まえると全てを同時に着手してもX-Dayに間に合わせるのが困難であり、リソース分散により全てが中途半端になると考えています。
本書では、各リスクシナリオの対策を以下の2パターンに厳選して分類します：
| 分類 |
定義 |
| 🔴 すぐやる（3ヶ月以内）
|
最も効果が高く、依存関係を含めて3ヶ月以内に実行可能なもの。これだけで防御力が質的に変わる |
| ⚪ 今はやらない
|
重要だが、上記に集中するためあえて後回しにする。リソース分散を防ぐための意思決定 |
脅威認識：なぜ「すぐやる」必要があるのか
構造変化の本質
個々の脅威（脆弱性スキャン、エクスプロイト作成、ラテラルムーブ）は古典的ですが、AIによる速度と物量がブレークスルーしています。リアル軍事の世界で高価なミサイルが安価なドローン群に置き換わっているのと似たような構造変化が、サイバー空間で起きています。
-
脆弱性調査とエクスプロイト作成の能力が「悪い意味で民主化」されています — 従来は高度な技術者のみが可能だった攻撃が、AIにより低コスト・大量に実行可能になっています
- Mythos以前から状況証拠的にこの傾向は既に始まっており、Mythosはその延長上にあります
-
本気でやられたら侵入を防ぐことは非常に困難です → 侵入前提（Assume Breach）で防御を設計する必要があります
対策の基本方針
-
攻撃面を減らす（ASM: Attack Surface Management）— 圧倒的に重要です
-
侵入されても被害を局所化する — 権限最小化、セグメンテーション、検知＋遮断
-
検知〜対応を高速化する — EDR/GuardDuty + Runbook + 自動遮断
-
情報資産の流出を防ぐ — ソースコード・構成情報の公開リスク最小化
全体まとめ：すぐやる対策 一覧
以下の16対策を3ヶ月以内に実行します。各対策の詳細は、後述の各リスクシナリオセクションを参照してください。AWSを長く使っているとすでに実施済みのものも多くあると思います。既存の保護についてもこの際しっかり点検したいところです。AIによる攻撃は、手法は古典的で、スピードと量がブレークスルーしているだけのものが多いとの理解から、意外に従来の基本的な保護が効果を発揮するとの考えです。基本が大切です。
| # |
対策 |
シナリオ |
実行期間 |
依存関係 |
| 1 |
攻撃面の削減（IF棚卸し・廃止着手） |
① |
即日〜3ヶ月 |
なし |
| 2 |
WAFマネージドルール + Bot Control |
① |
即日〜2週間 |
なし |
| 3 |
EDR（CrowdStrike等）展開 |
① |
1〜2ヶ月 |
→6 |
| 4 |
GuardDuty全面有効化 |
① |
即日〜1週間 |
→6 |
| 5 |
IAM最小権限化（重点アカウント） |
① |
1〜3ヶ月 |
なし |
| 6 |
Runbook整備 |
① |
2〜4週間 |
←3,4 |
| 7 |
Air Gapバックアップ |
① |
2〜4週間 |
←6 |
| 8 |
AI利用ポリシー策定 |
② |
1〜3週間 |
→9 |
| 9 |
セキュリティ教育 |
② |
1ヶ月 |
←8 |
| 10 |
承認済みAI基盤提供 |
② |
2〜3ヶ月 |
←8 |
| 11 |
自社資産流出防止 |
② |
2〜4週間 |
なし |
| 12 |
AI生成コードレビュー義務化 |
③ |
即日〜2ヶ月 |
なし |
| 13 |
IaC変更管理強化 |
③ |
2〜4週間 |
なし |
| 14 |
本番環境アクセス制限 |
③ |
1〜2ヶ月 |
なし |
| 15 |
依存関係自動スキャン（KEV/EPSS） |
④ |
即日〜2週間 |
→16 |
| 16 |
CI/CDパイプラインセキュリティ |
④ |
1〜2ヶ月 |
←15 |
依存関係図
[即日着手]
IF棚卸し(1) ─────────────────────── 攻撃面の把握と段階的廃止
WAF(2) ───────────────────────────── 独立して即効
GuardDuty(4) ──┐
EDR(3) ────────┼──→ Runbook(6) ──→ バックアップ(7)
│ ↑
│ 検知ツール導入とセットで対応手順整備
│
ポリシー(8) ──┬──→ 教育(9)
└──→ 承認済AI基盤(10)
資産流出防止(11) ──────────────── 独立して即効
レビュー義務化(12) ──────────── 独立して即効
IaC管理強化(13) ──────────────── 独立して即効
スキャン(15) ──→ CI/CDセキュリティ(16)
[1〜3ヶ月で完了]
IAM最小権限化(5) ──────────────── 段階的に実施
本番アクセス制限(14) ────────── 1〜2ヶ月
なぜ「今はやらない」対策を明示するのか
今はやらない対策 一覧
| # |
対策 |
シナリオ |
後回しにする理由 |
| 1 |
IF削減の本格移行（Verified Access） |
① |
棚卸し・廃止可能分は着手しますが、本格移行は3〜6ヶ月の大規模作業です。WAF+EDRで当面の防御を確保してから全面移行します |
| 2 |
ネットワークセグメンテーション |
① |
既存環境のリファクタリングが大規模です。EDRによるラテラルムーブ遮断で当面は代替可能です |
| 3 |
パッチ適用自動化 |
① |
CI/CDパイプライン整備に時間がかかります。加えてOSSリポジトリ乗っ取り事案が多発しており、すぐに当てることもリスクです。WAF仮想パッチで時間を稼ぎつつ中期で整備します |
| 4 |
AIセキュリティテスト |
① |
発見しても対応プロセスが追いつかない現状では、まず検知・遮断の基盤を固めるのが先です。AIとセキュリティ双方の高度な知見も必要です |
| 5 |
脅威インテリジェンス（外部フィード） |
① |
GuardDuty内蔵分で当面は十分です。外部フィード統合は運用負荷が増えます |
| 6 |
デコイ・欺瞞戦術 |
① |
検知精度向上には有効ですが、EDR+GuardDutyで基本的な検知は既にカバーされます。致命的事態の「防止」には直接寄与しないため中期で追加します |
| 7 |
自律閉塞メカニズム |
① |
設計が複雑で3ヶ月内の完了が不確実です。EDRの自動遮断機能で当面代替可能であり、Runbookに「手動閉塞の判断基準」を含めることで初期対応はカバーします |
| 8 |
DLP導入 |
② |
効果は高いですが導入・チューニングに3ヶ月超かかります。まずポリシー+教育+代替基盤で人的抑止を固めてから追加します |
| 9 |
監査ログ・モニタリング |
② |
承認済み基盤のログで当面カバーできます。全社的なAI利用監視はDLPと合わせて中期で整備します |
| 10 |
シフトレフト / セキュアバイデザイン |
③ |
長期的には重要ですが、既存システムの即時リスク低減には寄与しません。対策12（レビュー義務化）で当面の品質担保は確保されます |
| 11 |
カナリアリリース |
③ |
パイプライン構築に時間がかかります。レビュー義務化+Policy as Codeで「危険な変更を出さない」を先に固めます |
| 12 |
AI自動化のガードレール |
③ |
ガードレール設計が複雑で3ヶ月では完了しません。まずは人間ゲートで対応します |
| 13 |
CI/CDパイプラインの新規導入 |
③ |
未導入の場合は中期で整備します。既存パイプラインがある場合は対策16でセキュリティ強化を先行します |
| 14 |
SBOM管理本格運用 |
④ |
運用負荷が極めて高く費用対効果が悪いです。自動スキャンで「今危険なもの」を捕まえる方が効率的です |
| 15 |
OSS集約管理（CodeArtifact） |
④ |
開発者体験への影響が大きく合意形成に時間がかかります。スキャン+パイプラインセキュリティで当面カバーします |
| 16 |
署名検証（Sigstore/Cosign） |
④ |
完全なSLSA準拠は長期目標です。基礎的な分離とスキャンを先に固めます |
なぜ明示するのか
「やらない」と決めることは、「やる」と決めることと同じくらい重要です。
-
リソースの集中: 限られた人員で16対策を3ヶ月で完了させるため、残りは意図的に後回しにします
-
判断の透明性: 後回しにした理由を明記することで、状況変化時に優先度見直しが容易です
-
完遂の確実性: 手を広げすぎて全て60%で止まるより、重要な16対策を100%で完了させる方が防御力は高いと考えます
見直しタイミング: 3ヶ月後（「すぐやる」対策の完了確認後）に、「今はやらない」対策の優先度を再評価します。
リスクシナリオ①：自律型AIによるネットワーク侵害
概要
自律型AIは、脆弱性の発見からエクスプロイト作成、侵入、ラテラルムーブまでを人間の介入なしに実行します。従来は数日〜数週間かかっていた「脆弱性公開→攻撃開始」のリードタイムが、数分〜数時間に短縮されています。防御側のパッチ適用サイクルでは到底追いつけない速度であり、WAFによる仮想パッチや自動遮断による「時間稼ぎ」が不可欠です。
実際の事例
🔴 すぐやる対策
1. 攻撃面の削減（ASM観点でのIF削減着手）
| 項目 |
内容 |
| 何をやるか |
使われていないIF・脆弱な社内向けIF（SSH等）の棚卸しと廃止を即時着手。3ヶ月以内に廃止可能なものから実行。Verified Accessへの本格移行は中期で継続 |
| なぜ今か |
まずは攻撃面を減らすことが圧倒的に重要。WAFで守れないものをなくせば、人的リソースをWAF/EDRに集中できる。IF削減はASMの文脈で最も効果が高い |
| 依存関係 |
なし（棚卸し→廃止は段階的に実施可能） |
| 実行期間 |
即日（棚卸し開始）〜3ヶ月（廃止可能分の完了）。Verified Access本格移行は3ヶ月以降も継続 |
2. WAFマネージドルール導入 + Bot Control
| 項目 |
内容 |
| 何をやるか |
AWS WAFマネージドルール + Bot Controlを全外部向けサービスに適用 |
| なぜ今か |
即日有効化可能で、ゼロデイ公開〜パッチ適用の間の「時間を稼ぐ」数少ない手段。自律型AIの攻撃速度に対して人間のパッチ適用は間に合わない |
| 依存関係 |
なし（単独で即効果） |
| 実行期間 |
即日〜2週間 |
3. EDR（CrowdStrike等）展開
| 項目 |
内容 |
| 何をやるか |
EDR（CrowdStrike Falcon等）を開発端末・EC2・コンテナ環境に導入 |
| なぜ今か |
WAFを突破された場合の第2防衛線。ラテラルムーブの検出＋自動遮断が可能で、GuardDuty（検出のみ）より実効性が高い。総合的な費用対効果が高い |
| 依存関係 |
→ Runbook整備（遮断後の対応フロー必須） |
| 実行期間 |
1〜2ヶ月 |
4. GuardDuty全面有効化 + Runtime Monitoring
| 項目 |
内容 |
| 何をやるか |
全リージョンでGuardDuty有効化。ECS/EKS Runtime Monitoring、S3保護、RDS保護も有効化 |
| なぜ今か |
C2通信・異常API呼出し・クリプトマイニングなど、EDRがカバーしないAWSレイヤーの異常を検知。即日有効化可能。導入しやすく費用対効果が最も高い
|
| 依存関係 |
→ Runbook整備（検知後の対応プロセス必須。SOARなしでもまず人間が判断するフローを整備する） |
| 実行期間 |
即日〜1週間（有効化）、2〜4週間（チューニング） |
5. IAM最小権限化（重点アカウント）
| 項目 |
内容 |
| 何をやるか |
ミッションクリティカル環境のIAMポリシーを棚卸し、IAM Access Analyzerで未使用権限を削除。IP制限付与 |
| なぜ今か |
クレデンシャル漏洩時の被害抑制に直結（IP制限により被害軽減事例あり）。自律型AIが権限昇格を自動試行する前提で、昇格先の権限自体を削る |
| 依存関係 |
なし（既存アプリの動作確認は必要だが段階的に実施可能） |
| 実行期間 |
1〜3ヶ月（段階的） |
6. Runbook整備（インシデント対応）
| 項目 |
内容 |
| 何をやるか |
EDR/GuardDutyアラート発報時の初動対応手順を文書化。オフラインバックアップも確保 |
| なぜ今か |
EDR・GuardDutyを入れても「検知したがどうすればいいかわからない」では意味がありません。対策3・4の効果を発揮するための前提条件です |
| 依存関係 |
対策3・4と同時並行で整備（検知ツール導入と対応手順はセット） |
| 実行期間 |
2〜4週間（初版） |
| 含むべき内容 |
封じ込め手順 / エスカレーションフロー / 証拠保全 / 外部通報判断基準 / 復旧手順 |
7. Air Gapバックアップ（AWS Backup Vault Lock）
| 項目 |
内容 |
| 何をやるか |
AWS Backup Vault Lockを使用したAir Gapバックアップの設定。ミッションクリティカルなデータ・システムを対象に、改ざん不可能なバックアップを確保 |
| なぜ今か |
侵入前提の防御において、最悪のケース（ランサム感染・全面暗号化）からの復旧手段を確保する最後の砦です。バックアップがなければRunbook（対策6）の復旧手順が機能しません |
| 依存関係 |
←対策6（Runbook）と補完関係 |
| 実行期間 |
2〜4週間 |
⚪ 今はやらない対策
| 対策 |
後回しにする理由 |
| IF削減の本格移行（Verified Access） |
棚卸し・廃止可能分は着手しますが、本格的なVerified Access移行は3〜6ヶ月の大規模作業です。WAF+EDRで当面の防御を確保してから全面移行します |
| ネットワークセグメンテーション |
既存環境のリファクタリングが大規模です。EDRによるラテラルムーブ遮断で当面は代替可能です |
| パッチ適用自動化 |
CI/CDパイプライン整備に時間がかかります。加えて、3rd Party/OSSツールのリポジトリ乗っ取り事案が多発しており、すぐに当てることもまたリスクです。WAF仮想パッチで時間を稼ぎつつ、KEV/EPSSベースで高リスクパッチのみ確実に適用する運用を中期で整備します |
| AIセキュリティテスト |
発見しても対応プロセスが追いつかない現状では、まず検知・遮断の基盤を固めるのが先です。また、AIとセキュリティ双方の高度な知見が人間側に必要で、現時点では実行が困難です |
| 脅威インテリジェンス |
GuardDutyに内蔵されている分で当面は十分です。外部フィード統合は運用負荷が増えます |
| デコイ・欺瞞戦術 |
検知精度向上には有効ですが、EDR+GuardDutyで基本的な検知は既にカバーされます。致命的事態の「防止」には直接寄与しないため中期で追加します |
| 自律閉塞メカニズム |
設計が複雑で3ヶ月内の完了が不確実です。EDRの自動遮断機能で当面代替可能であり、Runbookに「手動閉塞の判断基準」を含めることで初期対応はカバーします |
リスクシナリオ②：社員のAI利用に起因する情報漏洩
概要
社員が業務効率化のために外部AIサービスにデータを入力することで、意図せず機密情報が流出するリスクです。IT部門が把握していないAIツールの利用（シャドーAI）が急速に広がっており、ポリシーの不在が最大の脆弱性となっています。また、生成AIはソースコードから脆弱性を分析する能力が高く、ソースコードの流出自体が直接的な攻撃の起点になり得ます。
実際の事例
🔴 すぐやる対策
8. AI利用ポリシーの策定・展開
| 項目 |
内容 |
| 何をやるか |
データ分類（Confidential/Restricted/Internal/Public）に応じたAI利用ルールを策定し全社展開 |
| なぜ今か |
コストゼロで即時リスク低減が可能です。ルールが存在しない状態では「知らなかった」が通ってしまいます。技術的対策の前提としても必須です |
| 依存関係 |
→ 教育（対策9）とセットで効果倍増 |
| 実行期間 |
1〜2週間（策定）、1週間（展開） |
9. セキュリティ教育（AI利用リスク特化）
| 項目 |
内容 |
| 何をやるか |
AI利用の具体的リスク事例を用いたハンズオン形式の教育（1回60分程度） |
| なぜ今か |
ポリシーだけでは読まない・理解しない社員がいます。具体事例で「自分ごと」にさせることが重要です。1ヶ月以内に初回実施可能です |
| 依存関係 |
対策8（ポリシー）が教育コンテンツのベースになる |
| 実行期間 |
1ヶ月以内に初回実施 |
10. 承認済みAI基盤の提供
| 項目 |
内容 |
| 何をやるか |
エンタープライズ向けAI基盤サービス（Amazon Bedrock / Amazon Q等）、データが外部に出ないエンタープライズAI基盤を提供 |
| なぜ今か |
「禁止」だけではシャドーAIが増えます。安全な代替手段を提供することで、外部AIへのデータ流出動機を根本から断ちます。素のAI Agentはリスクが高いため、機能を絞ったマネージドサービス的な導入がカウンターになります |
| 依存関係 |
対策8（ポリシー）で「承認済み基盤以外の利用制限」を定める必要あり |
| 実行期間 |
2〜3ヶ月（PoC → 本番） |
11. 自社資産流出防止の強化
| 項目 |
内容 |
| 何をやるか |
GitHubリポジトリの公開範囲見直し、ソースコード・構成情報の公開リスク最小化。生成AIが読める形で公開されている情報の棚卸し |
| なぜ今か |
生成AIはソースコードを読んで脆弱性を分析するのが得意です。「ソースコードが漏れたけどOK」は通用しない時代です。公開情報からも構成を推測されて武器化される恐れがあります |
| 依存関係 |
なし |
| 実行期間 |
2〜4週間 |
⚪ 今はやらない対策
| 対策 |
後回しにする理由 |
| DLP導入 |
効果は高いですが導入・チューニングに時間がかかります（3ヶ月超）。まずポリシー+教育+代替基盤で人的抑止を固めてから技術的制御を追加します |
| 監査ログ・モニタリング |
承認済み基盤のログで当面カバーできます。全社的なAI利用監視はDLPと合わせて中期で整備します |
リスクシナリオ③：AI利用によるプロダクション環境の破損・停止
概要
AI生成コードの無検証デプロイや、AIツールに過度な権限を与えた状態での運用により、本番環境の障害・データ損失が発生するリスクです。AIが生成するコードは「構造的に正しく見える」ため表面的なレビューでは問題を発見しにくく、かつ人間がレビュー不可能な量の変更が一度に行われるケースが増加しています。
実際の事例
🔴 すぐやる対策
12. AI生成コードのレビュー・テスト義務化
| 項目 |
内容 |
| 何をやるか |
下記5施策を段階的に導入し、AI生成コードの品質を担保します |
| なぜ今か |
AI生成コードは「もっともらしいが微妙に間違っている」パターンが多いです。かつ人間がレビュー不可能な量の変更が一度に行われるケースが増加しており、従来のレビュープロセスでは対応できません |
| 依存関係 |
なし |
| 実行期間 |
即日〜2ヶ月（段階的） |
具体施策：
| # |
施策 |
解決する問題 |
実行期間 |
| 12-1 |
PRサイズ制限の導入 — 500行超の差分は分割必須。AI生成であっても「論理的に独立した変更単位」に分ける |
AIが一度に大量書き換えを行い、人間がレビュー不能になる問題 |
即日 |
| 12-2 |
大規模書き換えの事前設計レビュー（ADR）義務化 — ロジックを根本的に書き換える場合は、コード着手前に「変更の必然性」を設計文書で承認する |
そもそもその書き換えが必要だったのか判断できない問題 |
1〜2週間 |
| 12-3 |
AIコードレビューツールのCI/CD統合 — セキュリティ・ロジックエラー・パフォーマンスを自動検出し、重大問題はマージブロック |
人間が400行超の差分で品質低下する構造的限界への対処 |
2〜4週間 |
| 12-4 |
テストカバレッジ閾値のマージ条件化 — 変更前後で既存テストが全パスすること＋新規コードのカバレッジ閾値を設定 |
書き換えたロジックの正確性を「テスト通過」で客観的に証明する |
1〜2週間 |
| 12-5 |
「変更の必然性」と「変更の正確性」の分離レビュー — Phase 1（設計意図：人間）→ Phase 2（コード品質：AI＋人間）の2段階フローに変更 |
人間が「全行読む」必要をなくし、人間は設計判断に、AIは機械的チェックに集中させる |
1〜2ヶ月 |
背景と根拠：
- SmartBear社およびCisco Systemsの調査により、人間のレビュー品質は200行を超えると急激に低下し、400行超で検出率は半分以下になることが示されています（出典: SmartBear "Best Practices for Code Review"; Cisco Systems code review study）
- O'Reilly Media の分析では、AIによるコードレビューでも検出できるバグは約半数に留まり、人間とAIの組み合わせが最も効果的であると報告されています（出典: O'Reilly "AI Code Review Only Catches Half of Your Bugs" (2026-04-30)）
- Cloudflare（2026年4月公開）は、7つの専門AIレビュアーを並列実行し「コーディネーターAI」が統合・重大度判定する方式で、数万件のMRを自動レビューしています。重大問題発見時はマージを自動ブロックします（出典: Cloudflare Blog (2026-04-20)）
- 本対策の核心は「人間に全行レビューを求める」モデルから「AIが機械的チェックを行い、人間はAIの指摘と設計意図を判断する」モデルへの転換です
段階的導入の流れ：
Week 1: PRサイズ制限(12-1) + テスト閾値(12-4) → 即日効果
Week 2-3: ADR義務化(12-2) → 不要な大規模書き換えを事前に防止
Week 3-4: AIレビューツール統合(12-3) → 機械的チェックの自動化
Month 2: 2段階レビューフロー(12-5) → 人間のレビュー負荷を構造的に軽減
13. IaC変更管理強化（Policy as Code）
| 項目 |
内容 |
| 何をやるか |
Terraform Plan + OPA/SentinelでSG全開放、パブリックS3等の危険パターンを事前ブロック |
| なぜ今か |
AIがIaC変更を提案→適用する流れが増えています。人間がPlan結果を見ても危険に気づかないケースを自動検出します |
| 依存関係 |
既存環境でCI/CDがワークしていることが前提（既存CI/CDに追加するのみだが、CI/CD未導入のケースは対応に時間が必要） |
| 実行期間 |
2〜4週間 |
14. 本番環境アクセス制限
| 項目 |
内容 |
| 何をやるか |
Break-glass手順策定 + 時限付き特権アクセス（IAM Identity Center） |
| なぜ今か |
AIツールに本番アクセス権を与えたまま作業するケースを制度的に防止します。「常時アクセス可能」を「必要時のみ申請」に変えます |
| 依存関係 |
なし |
| 実行期間 |
1〜2ヶ月 |
⚪ 今はやらない対策
| 対策 |
後回しにする理由 |
| カナリアリリース |
パイプライン構築に時間がかかります。レビュー義務化+Policy as Codeで「そもそも危険な変更を出さない」アプローチを先に固めます |
| AI自動化のガードレール |
ガードレール設計が複雑で3ヶ月では完了しません。まずは人間ゲートで対応します |
| CI/CDパイプラインの新規導入 |
パイプラインを使用して自動化と人間ゲートを組み合わせて効果的な対策が可能なので、CI/CDパイプラインが未導入の場合は中期で整備します |
| シフトレフト / セキュアバイデザイン |
長期的には重要ですが、既存システムの即時リスク低減には寄与しません。対策12（レビュー義務化）で当面の品質担保は確保されます |
リスクシナリオ④：サプライチェーン汚染（OSS感染含む）
概要
オープンソースの依存関係を通じた攻撃（Dependency Confusion、Typosquatting、リポジトリ乗っ取り）が急増しています。CI/CDパイプライン自体が攻撃対象となるケースも多発しており、「信頼しているツールが武器化される」リスクが現実のものとなっています。
実際の事例
🔴 すぐやる対策
15. 依存関係の自動脆弱性スキャン
| 項目 |
内容 |
| 何をやるか |
Dependabot / Trivy をCI/CDに統合。Critical/Highの脆弱性検出時はマージブロック。ただしKEV（Known Exploited Vulnerabilities）/EPSSベースのリスク判断で優先度付け |
| なぜ今か |
既存パイプラインへの追加で即日導入可能です。OSS感染攻撃（4月Trivy事件）への最も直接的な対策です |
| 依存関係 |
なし |
| 実行期間 |
即日〜2週間 |
| 注意 |
CVSSスコア一律やパッチ全適用は机上の空論です。KEV/EPSSで「実際に悪用されている」or「悪用される蓋然性が高い」ものに集中します |
16. 既存のCI/CDパイプラインのセキュリティ強化（基礎）
| 項目 |
内容 |
| 何をやるか |
ビルド環境の分離（エフェメラルランナー）、シークレット管理の見直し、GitHub Actions権限最小化 |
| なぜ今か |
対策15でスキャンしても、ビルドパイプライン自体が侵害されていれば意味がありません。スキャンの信頼性を担保する基盤です。3rd Party/OSSツールのリポジトリ乗っ取り事案が多発しており、パイプラインの信頼性確保は急務です |
| 依存関係 |
対策15と同時着手が効率的 |
| 実行期間 |
1〜2ヶ月 |
⚪ 今はやらない対策
| 対策 |
後回しにする理由 |
| SBOM管理本格運用 |
運用負荷が極めて高く費用対効果が悪いです。まず自動スキャンで「今危険なもの」を捕まえる方が効率的です |
| OSS集約管理（CodeArtifact） |
開発者体験への影響が大きく合意形成に時間がかかります。スキャン+パイプラインセキュリティで当面カバーします |
| 署名検証（Sigstore/Cosign） |
完全なSLSA準拠は長期目標です。基礎的な分離とスキャンを先に固めます |
本レポートは2026年5月11日時点の情報に基づきます。レポートの作成にあたってAIによる支援を活用しました。
