Security for App Builders @ Loft #1 参加レポート
クロスマートでSREをしている長野(ながの)と申します。
2025年11月21日、目黒セントラルスクエアで開催された「Security for App Builders @ Loft #1」に参加してきました。AIエージェントがコードを書く時代における、開発者が押さえるべきセキュリティの原理原則と実践的なプラクティスについて学ぶ機会をいただきました。とくに「脅威モデリング」についての学びが印象的でしたので、今回はそこにフォーカスした内容をまとめていきたいと思います。
イベント概要
- 日時: 2025年11月21日(金) 15:00 - 17:30
- 会場: 目黒セントラルスクエア 17F Startup Loft
アジェンダ
- 15:10 - 15:40 ビルダーのための脅威モデリング
- 15:45 - 16:15 セキュリティのシフトレフト
- 16:20 - 16:50 アプリケーションセキュリティの実装を効率化するマネージドサービス
脅威モデリングとは
脅威モデリングは、システムに対する潜在的な脅威を体系的に特定・評価し、適切な対策を講じるためのプロセスです。設計段階で実施することで、実装後に発見されるセキュリティ問題を事前に防ぐことができます。
脅威モデリングで実現できること
脅威モデリングを実践することで得られる成果は以下のようなものになります。
- 漠然とした不安の具体化: 「セキュリティが心配」という抽象的な懸念を、具体的な脅威シナリオとその対策に落とし込める
- 網羅的なリスク把握: STRIDEなどのフレームワーク(後述します)を活用することで、見落としがちな脅威も体系的に洗い出せる
- 設計段階での問題発見: 実装前にセキュリティ上の問題を特定し、手戻りコストを大幅に削減できる
- チーム内の共通認識形成: セキュリティリスクとその対策について、開発チーム全体で共通の理解を持てる
- 優先順位付けの明確化: 限られたリソースの中で、どの脅威から対策すべきかを判断できる
これらの成果の中でも特に重要だと感じたのは、機能開発と並行してチーム全体がセキュリティを考慮できるようになる点と、優先順位付けによってチーム内で共通認識を持てる点です。従来のように、セキュリティ担当者だけが問題を抱え込むのではなく、開発チーム全員がセキュリティに関わることができる仕組みは、持続可能なセキュリティ対策の実現に不可欠だと感じました。
とはいえ脅威モデリングって難しいんでしょう？
とはいえ、いざ脅威モデリングをやるぞとなるとまず何から始めればいいのでしょうか？せっかくチームで開発メンバーを巻き込んで時間を作ったとしても何もないところから脅威を洗い出しましょうといっても、なかなか成果はでないでしょう、、、
そこで 生成AIを使いましょう！ ということになります。
従来、脅威モデリングはセキュリティの専門家が持つ専門的なスキルが必要であり、一般の開発者にとっては実践のハードルが高いものでした。しかし、生成AIの登場により、この状況が大きく変わりつつあります。AIをサポートツールとして活用することで、専門的な知識が少ない開発者でも、体系的な脅威分析を行えるようになってきています。これにより、脅威モデリングがより身近で実践しやすいものになり、多くの開発チームがセキュリティを設計段階から考慮できるようになっていくのです。
脅威モデリングの実践方法
具体的なアプローチとして、今回は以下の4つのステップを学ぶことができました。
- システムの図示: アーキテクチャ図を作成し、データフローを可視化
- 脅威の識別: STRIDEなどのフレームワークを用いて潜在的な脅威を洗い出し
- 対策の検討: 各脅威に対する緩和策を設計
- 検証: 実装された対策が適切に機能しているか確認
ところでSTRIDEフレームワークとは？
今回はいくつかある脅威分類フレームワークの中でもとくにSTRIDEというフレームワークが紹介されました。STRIDEは以下の6つの脅威カテゴリの頭文字を取ったものです。
- Spoofing (なりすまし): 他のユーザーやシステムになりすます攻撃
- Tampering (改ざん): データやコードの不正な変更
- Repudiation (否認): 実行した操作を否認できてしまう状態
- Information Disclosure (情報漏洩): 機密情報が権限のない人に公開される
- Denial of Service (サービス拒否): システムを利用不能にする攻撃
- Elevation of Privilege (権限昇格): 本来持たない権限を不正に取得する
STRIDEフレームワークの使い方
STRIDEフレームワークは、一般的に以下のように活用されます。
システムコンポーネントごとに適用: システムのアーキテクチャ図を用意し、各コンポーネント(UI、API、データベース、外部連携など)に対して、STRIDEの6つのカテゴリそれぞれについて脅威が存在しないかを確認していきます
データフローに沿って分析: ユーザーからの入力がシステム内をどのように流れるかを追いながら、各経路でSTRIDEの視点から脅威を検討します
チェックリストとして活用: STRIDEの6つのカテゴリを網羅的なチェックリストとして使うことで、特定の種類の脅威を見落とすリスクを減らせます
このように、STRIDEは脅威を「漏れなく」洗い出すための構造化されたアプローチとして機能します。フレームワークがあることで、「何を考えればいいのか」が明確になり、チームでの議論もしやすくなります。
生成AIで脅威モデリングを実践しやすくする
ここまで、脅威モデリングで実現できることや、STRIDEフレームワークを使った具体的な手法を見てきました。しかし、実際にチームで取り組もうとすると「どこから始めればいいのか分からない」という壁に直面します。
そこで活用できるのが生成AIです。AIをサポートツールとして使うことで、専門的な知識が少ない開発者でも、体系的な脅威分析を行えるようになります。
たたき台の作成で最初のハードルを下げる
何もない状態から脅威を洗い出すのは困難ですが、生成AIを使えば初期のたたき台を素早く作成できます。システムのアーキテクチャ図や主要なコンポーネントの情報をAIに提供すると、以下のようなアウトプットを得られます。
- システム構成に基づいた想定される脅威のリスト
- 各コンポーネントに対するSTRIDE分析の下書き
- 一般的な攻撃シナリオとその対策案
このたたき台をベースにチームで議論を進めることで、ゼロから始める負担が大幅に軽減され、設計段階からセキュリティについて考えることが容易になります。
STRIDEフレームワークとAIの組み合わせで網羅性を担保
また、STRIDEのような確立されたフレームワークを基準として活用することで、生成AIは次のようなサポートを提供できます。
- フレームワークの各カテゴリ(Spoofing、Tampering等)に沿った質問や検討項目の提示
- 類似システムにおける脅威事例の参照
- 見落としがちな脅威も含めた網羅的なチェックリストの生成
フレームワークという「型」があることで、AIに何を聞けばいいのかが明確になり、チーム全体でセキュリティを考える共通言語が生まれます。これにより、機能開発と並行してセキュリティを検討する文化を作りやすくなります。
ただし、AIが生成した分析結果はあくまでたたき台です。必ずチームでレビューし、自社のシステム特有の文脈や要件を反映させることが重要です。
チームでの実践
ここまでで生成AIを活用した脅威モデリングの概要は理解できたと思いますが、これを我々開発者はいかに実践すればいいのでしょうか？ここからは脅威モデリングをチームで実践する際の重要なポイントを学んでいきましょう。
ドメイン観点を中心に脅威を考える
脅威を洗い出す際は、自社のドメイン特有の脅威に注目することが重要です。例えば、ECサイトに対する脅威を考える場合
- SQLインジェクションによるデータ漏洩
- DDoS攻撃によるサービス停止
- 悪意ある内部犯による注文履歴の閲覧・悪用
- 不正な大量注文による正規ユーザーの注文機会損失
上記のような脅威がでてきます。これを以下のように分類します。
汎用的な脅威
- SQLインジェクションによるデータ漏洩
- DDoS攻撃によるサービス停止
ドメイン特有の脅威
- 悪意ある内部犯による注文履歴の閲覧・悪用
- 不正な大量注文による正規ユーザーの注文機会損失
そうすると、汎用的な脅威への対策はこれまでの一般的なセキュリティ対策で対応できますが、ドメイン特有の脅威にこそ、チーム独自の深い分析が必要になります。自社のビジネスドメインを理解した上で脅威を考えることで、より実効性の高い対策を講じることができます。
多様なペルソナで考える
脅威モデリングを開発者だけの視点で行うと、技術的な脅威に偏りがちです。チームで様々なペルソナ(エンドユーザー、管理者、攻撃者、内部関係者など)を想定して議論することで、多様な観点から脅威を洗い出せます。
このプロセスは、チームメンバーが自分たちのシステムを学び直す良い機会にもなります。異なる役割の視点でシステムを見ることで、これまで気づかなかった脅威や改善点が見えてくることもあります。
脅威への対応を戦略的に考える
すべての脅威に同じように対応する必要はありません。脅威に対するリスク分析を行い、優先順位をつけて戦略的に対応することが重要です。リスクへの対応戦略には以下の4つがあります:
- 回避: 脅威そのものを取り除く対策を実施
- 低減: 脅威の発生確率や影響を減らす対策を実施
- 移転: リスクを第三者に転嫁する(例: AWSなどのマネージドサービスを利用してインフラレベルのセキュリティ責任を委譲)
- 受容: リスクを緩和するためのコストと、悪用された場合の代償を天秤にかけて、意識的にリスクを受け入れる
特に「受容」は、気づいていないリスクやリスクを放置することを良しとしているわけではありません。脅威を認識した上で、戦略的に受容を選択するという意思決定です。限られたリソースの中で、どこに注力すべきかを判断することが、持続可能なセキュリティ対策につながります。
まとめ
今回の勉強会で一番印象に残ったのは、生成AIとSTRIDEのようなフレームワークを組み合わせることで、脅威モデリングがぐっと身近になったことです。これまで専門知識がないと難しかった脅威の洗い出しが、AIにたたき台を作ってもらうことではじめやすくなる。チーム内でセキュリティの知識に差があっても、フレームワークという共通言語とAIのサポートで、最低限のラインを担保しながら議論できる。この組み合わせは、開発チーム全員がセキュリティを考える文化を作るきっかけになるんじゃないかと感じています。
まずは自分のチームで小さく試してみようと思います。そして実践内容はまたブログで報告できればと考えています。
最後に、このような学びの機会を提供いただいたAWS様と、快く送り出してくれたチームメンバーに感謝いたします。ありがとうございました。
