生成AI時代のセキュアコーディングとDevSecOps

WAKECareer様の勉強で登壇させていただきました。
https://wake-career.connpass.com/event/369552/

DevSecOpsのセキュリティ戦略の設計や脅威の識別、GitHub Advanced Securityを活用したセキュリティの開発プロセスへの適用についてお話しさせていただきました。

Transcript

1. 生成AI時代のセキュアコーディングと DevSecOps 2025/10/16 Yurie Mori
2. INTRODUCTION
3. 今日話すこと • DevSecOpsで対応すべき脅威と対応策 • セキュリティを開発プロセスに統合する • GitHub Advanced SecurityによるDevSecOps • DevSecOpsの導入について（よくある質問やポイント等）
4. AGENDA Why DevSecOps Now? DevSecOpsにおけるセキュリティ戦略の設計 GitHub Advanced SecurityによるDevSecOps DevSecOps導入のポイント
5. Who Am I? Yurie Mori (森 友梨映) Microsoft Japan Cloud & AI Platform, Software Solution Engineer Carrer ◆ Microsoft Japan Software Solution Engineer ◆ Avanade Japan DevOps Engineer/Architect ◆ Plus Alpha Consulting Web Application Engineer Technology stack ◆ DevOps ◆ DevSecOps ◆ Platform Engineering ◆ Developer Experience/Productivity SNS Awards ◆ Microsoft MVP for DevOps & Cloud Security 2025 ◆ Microsoft MVP for DevOps 2024
6. ALL OPINIONS ARE OWN 発言は個人の見解です
7. Why DevSecOps Now?
8. 生成AIによってデリバリーのパフォーマンスは向上する？(1/2) 出典: https://cloud.google.com/devops/state-of-devops?hl=ja&region=JP DORA(DevOps Research and Assessment)のState of DevOps2024のレポートでは、AI導入が25%増えること で、デリバリーのスループットと安定性の両方が若干低下する可能性があると示されている。 スループットが-1.5% デリバリー安定性が-7.2%
9. 生成AIによってデリバリーのパフォーマンスは向上する？(2/2) • AIの導入により、タスクの完了速度（開発のスピード、リファクタリングスピード）は向上する • しかし、デリバリーのスループット（どれだけ成果物をリリースできるか）と安定性（成果物の品質や信頼性の一 貫性）の両方が若干低下する可能性がある • これは何を意味するのか？ • →「AI導入を増やす＝必ずしも良い成果、品質を保証しない」 • スループットはむしろAIが作業を支援するから上がりそうなのに、 実際には人やプロセスの調整コストが増える （例：AIツールに合わせた学習・調整が必要）ことで、一時的に成果物の量が減る可能性がある。 • 安定性については、 AIはまだ十分に安定していないツールもあるし、誤動作やヒューマンエラーが入り込みやすい ので、品質の一貫性にマイナスの影響が出やすい。 成果の質や安定性に目を配りながら、AIツールの運用や導入プロセスをしっかり整備する必要がある
10. スピード VS 品質：ソフトウェア開発の歴史の中で の永遠のシーソーゲーム 開発のスピードアップ • CI/CD • 自動化 • AIによるコーディング支 援/自動実行 etc. 品質・セキュリティの担保 • テスト駆動開発 • DevSecOps • SAST • DAST etc.
11. WHY DevSecOps NOW? AIによるコード生成品質とセキュリティの担保 • 生成AIによってどんどん生産されるソースコードの安全性をスピーディーにチェックし、セキュリティを担保 する 継続的なセキュリティ • CI/CDパイプラインにセキュリティテストを自動化して、常にセキュリティチェックが行われるようにする Found means FIX • AIを活用して、脆弱性の検知と修正をスピードアップする • 検知(found)したら即座に修正(fix) 開発プラットフォームの信頼性の担保 • 開発者のインフラである開発プラットフォームのセキュリティ監視
12. DevSecOpsにおけるセキュリティ戦略の設計
13. 脅威モデリングによるセキュリティ戦略の設計 構築しようとしているシステムに対して予測される攻撃、脅威、リスクを特定し、セキュリティ戦略を検討する Design Break Fix Verify • 構築しようとしているシステムの目 的、実行環境、シナリオなどシステ ムに関する情報をベースにデータフ ローダイアグラムを作成 • データフローダイアグラムをベースに、 STRIDEフレームワーク等を使用してシ ステムに対する潜在的な脅威を特定 • 特定した脅威に対して、対策を検 討 • 考えた対策がセキュリティ要件をク リアしているかを確認 Step1:データフローの可視化 Step2:脅威の特定 Step3:脅威への対策を識別 Step4:対策の有効性の検証
14. STRIDEによる脅威の分解と特定 システムに対する脅威を6つのカテゴリの頭文字を合わせたもの。各カテゴリごとに脅威を分類し、それに対する対 策を考える 脅威の種類 具体例 対策例 Spoofing （なりすまし） 攻撃者が他のユーザーやシステムになりす ます • 多要素認証 • 強力なパスワードポリシー • 証明書の使用 Tampering （改ざん） データが不正に変更される • 通信暗号化 Repudiation （否認） 攻撃者がログの削除や改ざんを行ってユー ザーが行った操作を否認する • ログの監査 Information disclosure （情報漏洩） 個人情報や資格情報などの機密情報が 不正に取得される • データのアクセス制御 • 暗号化による保護 • セキュアな通信プロトコル Denial of service （サービス拒否） サービスに過剰な負荷を与えて利用不可 状態にする • Rate limit • WAF(Web Application Firewall) Elevation of privilege （権限昇格） 攻撃者が不正に強力な権限（管理者権 限など）を取得して操作する • 最小特権の原則 • RBAC
15. 開発フローで発生しうる脅威を考える
16. • アクセスしてはいけない人がア クセスできるようになっている • 権限の過剰な付与 • ソースがPublicに公開できる ようになってしまう →データ漏洩のリスク • 共有コードベースに機密情報が混入 する • セキュリティ的に脆弱性のあるコード • 脆弱性のある外部ライブラリ（ソフト ウェアサプライチェーンに依存するリス ク） • ユーザーが特定できる情報など機密 情報の漏洩 • 本番環境への攻撃
17. DevSecOpsにおける脅威とセキュリティ対策 攻撃を受けやすいコード シークレットの流出による 不正アクセス 外部パッケージやOSSに含まれる脆弱性 コンテナイメージに含まれる 脆弱性 ソースコードの静的解析(SAST) シークレット管理、 シークレットスキャン 依存関係の脆弱性スキャン コンテナイメージのスキャン 対策 ソフトウェア開発中に発生しうる脅威 開発プラットフォームのガバナンスに起因する脅威 ソースコードの漏洩 不正アクセス 脆弱性のソースコードへの混入 可視性/リポジトリへの制御 SSO/MFAなど認証基盤の整備 ブランチポリシーなどガードレールや プロセスの整備 対策
18. GitHub Advanced Securityによる DevSecOps
19. GitHub Advanced Security(GHAS) GitHub Code Security • $30/1 active committer/月 • Code Scanning • コードに含まれる脆弱性の検知 • 依存関係レビュー • PRをマージする前に、依存関係に対する変更の影響をすべて 示し、脆弱なバージョンの詳細を表示 • Copilot Autofix • Copilotによる脆弱性を含むコードの自動修正提案 • Security Campaign • これまで蓄積されたセキュリティ的な脆弱性を最大数1000件 規模でトリアージ&修正 GitHub Secret Protection • $19/1 active committer/月 • Secret Scanning • Push Protection: シークレットが含まれる変更をpushさせ ないようにする • AIによるパスワード混入の検出
20. GitHub Advisory Database CVE*1に基づいて脆弱性を一意に識別 CWE *2に基づいて脆弱性を分類 CVCC *3に基づいて 脆弱性をスコアリング Repository 分析対象のソースコード Package.jsonなど依存関係を定義し たマニフェストファイル Dependency Graph ①リポジトリの依存関係の定義ファイル、 GitHub Advisoryに更新が入ると 依存関係グラフが更新される Dependabotアラート Dependabot セキュリティアップデート Dependabot バージョンアップデート セキュリティ的な脆弱性 バージョン乖離による脆弱性 自動アップデート Pull Request アラート生成 ③検知された脆弱性の種類により、自 動アップデートのPRが自動で作成される Dependabotによる 自動アップデートのPR作成 Dependency Review ②依存関係由来の脆弱性が検知さ れるとDependabotアラートが生成 ↑PRの変更適用による 依存関係変更の表示 依存関係の脆弱性の検知と対応 • CVE(Common Vulnerability and Exposures)*1: • ソフトウェアの脆弱性やセキュリティリスクを一意に管 理する識別子 • CWE (Common Weakness Enumeration)*2: • ソフトウェアにおける脆弱性を分類・整理した体系 • CVCC (Common Vulnerability Scoring System)*3: • 脆弱性の深刻度を評価するためのスコアリングシステム
21. Copilot Autofix: Copilotによる脆弱性の修正提案 • Code Scanningで検出された脆弱性に対して、Copilotが修正案を生成して提案 • GitHub Copilotのライセンスは不要、GitHub Code Securityのライセンスに含まれる • Copilot Autofix による脆弱性修正の提案を行うために、Code Scanning の解析結果から GPT-4o に以下の情 報が送信されます • 対象ブランチの最新のソースコード • ソース（入力）やシンク（出力）など、データの流れに関係する位置情報 • アラートメッセージやデータフロー内で参照された場所の、周辺のコードスニペット関連する各ファイルの冒頭最大10行の コード • 問題を検出した CodeQL クエリのヘルプテキスト • 修正プログラムを生成するプロセスでは、上記の範囲を超えてユーザーのデータが収集または利用されることは ない
22. SecurityとCopilotをCI/CDに統合 GitHub Repository PR Check • Build • Unit Test GitHub Actions Dev • Code Scanning • Dependency Check • Secret Scanning GitHub Actions GitHub Secret Protection GitHub Code Security CI/CD • Code Scanning • Dependency Check • Secret Scanning GitHub Secret Protection GitHub Code Security GitHub Repository Review Provide suggestion for fix Merge to main Create PR Observe Publish build artifacts to Packages GitHub Secrets Refer secrets Dev
23. セキュリティを開発フローに適用 適切な可視性制御 コードベースへの適切 なアクセス制御と権限 設計 認証基盤の整備 監査可能にする 外部ライブラリの脆弱 性のスキャンとブロック シークレットのスキャン、 pushの防止 コードの脆弱性スキャン セキュリティインシデント を監視可能にする インシデント発生時 のフローの定義 セキュリティリスクの トリアージルールの定義 セキュリティリスク発見時 に即時切り戻り可能にす るフロー設計 セキュアコーディング ルールの定義
24. シークレットが発見された！どうする？ • そのシークレットの種類、有効/無効かを特定 • 有効だった場合→いますぐそのシークレットを無効にする • 影響範囲を特定 • リポジトリの履歴に残っていないか確認（残っていたらクリーンアップ） • 再発行する際は必ずシークレットマネージャーに分離
25. DevSecOps導入のポイント
26. セキュリティスキャンを導入しました！これからどうする？ • そもそも開発プラットフォームは安全ですか？ • 過剰な権限が付与されていませんか？ • セキュリティリスクをどのようにトリアージして修正しますか？ • セキュリティインシデントが発生したときにどのように対応しますか？
27. よくある質問 • Q. DevSecOpsを一気に実践するのは大変。何から始めるべき？ • A. シークレット漏洩対策。SQL injectionやXSSなどセキュリティ的な脆弱性のあるコードに比べると、シーク レットに関しては実際にそれを使って攻撃されなかったとしても本番環境で露出しただけで一発で信用問題にな り、それ自体がセキュリティインシデントになり、もっともインパクトが大きいため。 • Q. DevSecOpsの導入/実践の際のあるあるな課題は？ • A.セキュリティの担保と開発スピードを担保すること。既存のワークフローにセキュリティスキャンを適用したりルール 整備をした結果、開発スピードが一時的に鈍化する可能性もある。すべてのチェックポイントで実施して、 Middle, Lowレベルの脆弱性も一切許容しない、すべてのセキュリティ脆弱性をクリアにすることなどを品質ゲー トのように適用することは現実的ではないので、既存の開発プロセスのどこに適用するのか、開発スピードとセキュ リティ担保によるコストのバランスを両立していくことが重要。 • Q.セキュリティスキャンはどのタイミングで適用すべき？ • A. 「汚染」されたくない場所（ブランチ/環境）に変更が適用されるとき。 • Q.DevSecOpsの導入戦略のおすすめは？ • A. DevOpsやDevSecOpsを組織内にロールアウトして拡大して、定着させていくのには少なからずコスト（お 金的な意味でも変更コストという意味でも）を強いることになるので、まずは小さくPoCから初めて、うまくいったら 段階的にロールアウトすることをおすすめする。
28. 生成AI時代の新たなセキュリティ脅威と対策 脅威 概要 どう対応する？ プロンプトインジェクション 攻撃者が「プロンプトに悪意ある指示」を 混ぜ込むと、AIが意図せず機密情報を 出力する。 シークレットをAIツールから隔離するよう なルール整備（シークレットマネージャー を使うなど） コンテンツ除外などAIから学習されたくな いコンテンツの隔離 AIが生成したコードに対する検証 シャドーAI 組織で許容していないAIツール（いわ ゆる野良AI）を開発者が個人で使って しまって、コードや設計書を外部サービス に送信してしまう 過剰にAIに対して規制をせず、適切に ガバナンスしたAIツールを提供。 AIツールに対するアクセス制御。 モデルサプライチェーン 生成AIモデルやAPIそのものに改ざんが 行われるリスク。 外部モデルを自社環境に組み込むと き、 学習データの出所や署名検証が曖昧だ と汚染データやマルウェア注入のリスク が生じる 生成AIが使用するモデルとそのモデルサ プライヤー側でのデータプライバシーに関 する規約を確認。 認可したモデルだけ使用できるように制 御 セキュリティオートメーションの過信 AIによる自動修正を「完全自動」と誤 解し、ヒューマンレビューが抜けて実際は 修正されていない脆弱性が流出 人とAIの責任分界を明確にする。 レビュー/承認の過程で人が確認すべき ところを定義。(Human-in-the- loop)
29. DevSecOps導入のポイント • ゴールを設定する • DevSecOpsによってどのような状態にしたいかを明確にする • シークレット露出の撲滅/平均復旧時間の短縮/過去におきたセキュリティインシデントを繰り返さない etc. • 組織にとっても最も恐れるセキュリティインシデントはなにか？ • 開発プラットフォームの自由と統制のバランス • データ漏洩や不正アクセスを防ぐためには、コードのセキュリティスキャンだけでなく変更の起点である開発プラットフォームの防御も 必要。これに対してはデータの境界を定め、それらを適切に分離する境界防御でアプローチする。 • 統制しすぎるとシャドーAIのリスクもある • 開発スピードとセキュリティのバランス • セキュリティスキャンには一定の実行時間がかかるので、すべてのフェーズで「品質ゲート」のように適用するとリリースまでのスピード が著しく落ちる • 既存の開発プロセスのどのポイントがセキュリティ担保のチェックポイントとして重要かを理解して適用する。 • アラート疲労の問題 • セキュリティスキャンで脆弱性が見つかった場合、アラートの重要度に応じて誰がどのように対応するのかのプロセス設計が重要 • 多すぎるアラートはアラート疲労や認知負荷の問題につながり、結果的に開発体験の低下につながるリスク • ツール以外のプロセス整備も重要 • そもそも開発者が「セキュリティ的に書いてはいけないコード」の共通認識があるか • セキュアコーディングルールの整備 • セキュリティインシデント発見時のプロセス設計
30. THANK YOU ☺