2026/02/13

テクノロジー

1秒でも早く知っておきたい「セキュリティ専門じゃないアプリケーションエンジニア」向けの脅威の洗い出しと対応方法

この記事の目次

    イベント概要とこの記事の目的

    法人ディベロップ課のS.Sです！
    日々、アプリケーションエンジニアとして、法人ソリューション事業部向き合いで、サービスの開発・保守を行なっております。

    先日、AWS のセキュリティイベント
    「Security for App Builders @ Loft #1」 に参加してきました。

    私は、セキュリティ専門ではないアプリケーションエンジニアですが、
    このイベントで、セキュリティへの関心がよりより湧き、
    未然に防ぐ具体的なアクションに取り組まねばな、と改めて思わされました。

    この記事では、「Security for App Builders @ Loft #1」で、何を学んだのかを記すとともに、
    「アプリケーションエンジニアで、セキュリティについて気にはなっている」という方の参考になれば幸いです。

    改めて、この記事の内容・目的は、以下の 4 点です。

    • イベント内セッションの概要を記載しつつ、学びと理解を整理する
    • アプリケーションエンジニアのセキュリティ意識や理解を深めてもらう
    • セッション内容の共有と、背景知識やちょっぴりの深掘り情報の共有
    • セキュリティ専門じゃないアプリエンジニアとして、「これから試してみたい脅威の洗い出しのやり方」のたたき台をまとめる

    そこそこの分量になっているので、気になるタイトルをポチポチとかいつまんで見ていただけると幸いです。

    なぜ、今、アプリケーションエンジニアがセキュリティを強く意識すべきなのか

    OWASP Top 10 とアクセス制御の不備

    冒頭で触れられていたのが OWASP Top 10 です。

    • OWASP Top 10 は、Web アプリケーションの代表的なリスクを 10 項目に整理したもの
    • 直近の正式版は OWASP Top 10: 2021 で、たとえば
      • A01:2021 – Broken Access Control（アクセス制御の不備）
      • A02:2021 – Cryptographic Failures…
        といった分類があります

    セッションでは、

    OWASP のデータに基づき、「アクセス制御の不備」が一定割合（3.73%）で見つかっている

    という話がありました。

    プロのエンジニアの手で開発されたサービスにおいて、アクセス制御の不備という重大な脆弱性が、およそ4%（100件に4件）も起こり得てしまうという点に驚いたとともに、エンジニアとしてお仕事を続けていれば、誰しも1度は発生させてしまうくらいの可能性があるなと背筋が伸びました。

    参考：

    シフトレフト：後になるほどコストが跳ね上がる

    工数やスケジュールが限られた中での開発で、往々にしてセキュリティ対応は後回しにされてしまいます。
    けれども、セキュリティ対応は、開発ライフサイクルの早い段階で取り込むほど「コストは低い」「被害は小さい」ので、むしろ開発サイクルのはやい段階で取り組むべしというお話でした。

    • 仕様検討（要件定義）で気づく
      → 仕様の一部修正で対処可能
    • 実装中に気づく
      → 実装の修正で対応可能
    • リリース後に顧客やインシデントで気づく
      → 影響調査、データ復旧、顧客への説明、信用回復など大きなコスト

    絵にするとこんな感じです。

    この「セキュリティを開発プロセスの左側に寄せる」考え方が 、Shift-left（シフトレフト） です。
    矛盾しているように聞こえますが、工数やスケジュールが限られているからこそ、開発サイクルの中でも、なるったけ早くに、セキュリティ対応をすべしということですね。

    参考：

    ビルダーのための脅威モデリング

    さて、ここからが、今回のタイトルに直結する部分です。 （サビです）

    「脅威モデリング」とは何か

    こちらのセッションでは、まず「脅威モデリング」の定義から整理されました。

    脅威モデリングとは

    システムに対する脅威を特定・列挙し、
    それぞれにどう対応するかを検討し、優先順位をつけるプロセス

    開発ライフサイクルで置く場所は、

    計画 → 設計（ここで脅威モデリング） → ビルド → テスト → デプロイ → 保守

    です。

    絵にするとこうです。

    参考：

    脅威モデリングの進め方

    セッションで紹介されていた流れは、以下の 4 ステップでした。

    1. 「何を作っているか」を明確にする
      • アーキテクチャ図
      • データフロー図
    2. 何が問題になり得るか洗い出す
    3. チームで脅威を議論する
    4. 対応方針を決め、優先順位をつける

    ここでのポイントは、

    • 可視化をして、PJメンバー全員で前提・問題の認識を揃えること
      → 図がないと、どこに攻撃面があるか議論できない
    • 1 回きりではあまり意味がなく、ライフサイクルに組み込む必要がある

    という点です。

    絵にするとこうです。

    STRIDE など、代表的なフレームワーク

    脅威モデリングでは、次のようなフレームワークが紹介されました。

    • STRIDE
    • DREAD
    • PASTA（Process for Attack Simulation and Threat Analysis）
    • Trike
    • VAST（Visual, Agile, and Simple Threat）
    • OCTAVE（Operationally Critical Threat, Asset, and Vulnerability Evaluation）

    今回、取り上げられていたのは STRIDE でした。
    網羅性が高く、チームでの議論の「型」として使いやすいのが理由です。

    STRIDE の 6 要素

    • S: Spoofing identity（なりすまし）
      • 攻撃者が正当なユーザーやシステムであるかのように振る舞うこと
        • 例: 攻撃者が他人のIDとパスワードを不正に入手し、そのユーザーになりすましてシステムにログインする
          例: 偽のWi-Fiアクセスポイントを設置し、正規のネットワークであるかのように見せかけて接続させる
    • T: Tampering with data（改ざん）
      • データや通信内容を許可なく変更すること
        • 例: オンラインバンキングの通信を傍受し、送金金額や送金先口座番号を書き換える
          例: Webサイトの設定ファイルを書き換え、訪問者を悪意のあるサイトへリダイレクトさせる
    • R: Repudiation（否認）
      • ユーザーが行った操作やアクションを「やっていない」と主張できる状態、またはその証拠がないこと
        • 例: ログ機能が不十分なシステムで、従業員が不正なデータ削除を行ったが、「自分はやっていない」としらを切られ、証拠が出せない
          例: 電子署名がないメールで契約の承認を行い、後になって「そのようなメールは送っていない」と主張される
    • I: Information disclosure（情報漏えい）
      • 機密情報が権限のない人間に閲覧・公開されること
        • 例: データベースの設定ミスにより、顧客のクレジットカード情報がインターネット上で誰でも閲覧できる状態になる
          例: エラーメッセージに詳細なシステム内部情報（パスやDB構造など）が表示され、攻撃者にヒントを与えてしまう
    • D: Denial of service（サービス拒否）
      • 正当なユーザーがサービスやリソースを利用できない状態にすること
        • 例: Webサーバーに大量のアクセス（DDoS攻撃）を送りつけ、サーバーをダウンさせて一般ユーザーが閲覧できないようにする
          例: アカウントロック機能を悪用し、わざとパスワードを何度も間違えて特定ユーザーのアカウントをロックさせる
    • E: Elevation of privilege（権限昇格）
      • 本来持っている権限以上の操作ができるようになること
        • 例: 一般ユーザーとしてログインした攻撃者が、システムの脆弱性を突いて管理者（root/admin）権限を奪取する
          例: URLのパラメータを書き換えることで、本来アクセスできない他人の注文履歴ページを閲覧・操作する

    これを「自分たちのシステム構成図・データフロー図」に対して当てはめていくことで、脅威モデリングができます。

    参考：

    ドメイン特有の脅威に目を向ける

    一般的に、下記のような共通の脆弱性 は見つけやすいですが、

    • SQL インジェクション
    • XSS
    • 典型的な認証バイパス

    ビジネス／ドメイン特有の脅威 は見逃されがちです。

    例：

    • EC サイト
      • 在庫数や価格の改ざん
      • ポイント／クーポンの不正利用
    • B2B SaaS
      • テナント分離の不備による他社データ閲覧
      • 管理権限の誤委譲・誤設定
    • サブスクリプションサービス
      • 無料トライアルの不正延長
      • 請求先のなりすまし

    脅威モデリングでは、こういった「そのサービス特有のリスク」を意識的に洗い出せる点が大きな価値です。（ドメイン理解の深い事業会社のエンジニアの価値発揮できるポイントですね）

    チームでやることの意味

    脅威モデリングは、セキュリティ専門家だけの作業ではない、「チームでやるべきことである」ということが強調されていました。

    • プロダクトオーナー
    • アプリケーションエンジニア
    • インフラ／SRE
    • セキュリティ担当

    など複数ロールで実施することで、

    • 「多様なペルソナ（攻撃者像・利用者像）」を出し合える
    • 見落としが減る

    という効果があります。（今の時代は、更に、AI というもう一人の存在の力も借りるのも有効ですね）

    セキュリティ専門じゃない自分が「脅威の洗い出し」をどう始めたいか

    正直な所、私はまだ、日々の開発の中で、本格的な脅威モデリングを回せていないです。（新規開発や保守をしていく上での脆弱性診断や対策は行ってはいますが）
    このセッションを聞いて、「まずはこのくらいのスコープからなら試せそう」と感じたものがあったので、簡単に流れを書いておこうと思います。

    • 新しい機能や API を作るときだけでもよいので対象を絞る
    • ざっくりした構成図・データフロー図を描く（ホワイトボードや Miro 等の書き出せるものでOK）
    • STRIDE の 6 つを観点にして 、「なりすましは？」「改ざんは？」「情報漏えいは？」… を見ていく
    • 出てきた脅威のうち 「すぐ直せそうなもの」 「影響が大きいもの」 を対策に落とす

    AI を活用した脅威モデリング支援

    後半戦では、

    AI を活用して脅威モデリングの手間を減らす

    という話が出ていました。
    登場したのは「AI エージェント」的なコーディング／解析支援のイメージで、AWS でいえば Amazon Q Developer ですね。（今は、kiro ですね）

    AI にやらせる部分 vs 人間がやる部分

    スピードや網羅性に関しては、AI の方が人間よりも優れていることが多いので、うまくAIと人間で分業をして協業することが重要そうだなと感じました。

    AI に任せやすい部分：

    • ワークロードの図式化
      • アーキテクチャ説明文から簡易図を生成させる
    • 想定される脅威の洗い出し
      • 「この構成に対して STRIDE 観点で脅威を列挙して」
    • 想定される脅威への一般的な対応策の候補出し
    • リスク評価のたたき台
      • 「影響度が高そうな順に並べて」

    人間が担うべき部分：

    • 脅威モデリングそのものの意義と目的の理解
    • 事業やサービスのドメイン周りの脅威洗い出し
    • 「何を対象に、何のために」脅威モデリングするかの設定
    • 事業戦略・リスク許容度に基づく 優先順位付けと最終判断

    「AI は“脅威のたたき台”を出してもらうところまで」と割り切り、
    最後の判断と、プロダクト側への落とし込みは人間がやるといった線引きで使っていきたいと感じました。

    セキュリティのシフトレフトと AI 活用

    攻撃は 100% 防げないが、被害は限定できる

    このセッションは、

    「リスクをゼロにはできないが、
    被害を限定し、復旧を容易にすることはできる」

    という前提から出発していました。

    例として挙げられたランサムウェア攻撃の典型フロー：

    1. ネットワークスキャン
    2. 脆弱性の調査・悪用
    3. ランサムウェアの設置
    4. ランサムウェアがターゲットシステムで動作
    5. 情報の窃取や暗号化

    どこか一段階でも早く検知・防御できれば、
    「完全な被害」から「一部のシステムだけ」「一部データだけ」で済む可能性が高まるという話です。

    DevSecOps と AI の進化

    2015年ごろから、セキュアコーディングについて、叫ばれていたが、業務に落とし込むことが物理的な制約のため難しかったけれど、2025年現在のAI の進歩により、実現可能になったので、今こそ改めて、セキュアコーディングへチャレンジをしていけるのではないかというお話でした。

    • 2015 年ごろ
      • DevSecOps という言葉が広がり始める
      • ただしセキュアコーディングの学習コストが大きい
      • 静的解析ツールなどから出る大量のアラートを人力でさばくのは現実的でない
    • 2025 年
      • AI コーディングエージェントが静的解析結果を解釈し、「どこをどう直すか」まで提案
      • AWS の例では Amazon Q Developer による
        • 調査（現状のコード理解、セキュリティチェック）
        • ビルド（修正案の提案・コード生成）
        • テスト（テストコード生成）
        • デプロイ（PR レビュー支援、ドキュメント生成）
          といったフローが紹介されていました。

    確かに、やりたい気持ちはあれど、なかなか手を出せていなかったですが、AI エージェントの誕生によって、良い意味で、もうそんな言い訳もできなくなったなと思いました。（← もうやってないは、怠慢かも?）

    参考：

    セキュリティトレーニングのテーマ

    アプリケーションエンジニア向けに、特に挙げられていたテーマは、

    • ガバナンスとコンプライアンス
    • セキュアコーディング
    • リスクマネジメント

    ここでも AI を「学びの相棒」として使う例として、紹介されていました。

    • 利用 OSS やライブラリについて
      • 「このライブラリに既知の脆弱性はあるか？」
      • 「この CVE（脆弱性）の影響度と対策を教えて」
    • 自分のコードに対して
      • 「ハードコードされたパスワードやシークレットがないか探して」
      • 「この関数にセキュリティ上の問題はありそうか？」

    これについては、既に行なっていましたが、すぐに試せて、かつ、有効な使い方だなと改めて思いました。

    IAM 権限設計と IAM Access Analyzer

    IAM の権限設計に関しても重要なポイントがありました。

    「最小権限を人間だけで完全に設計しきろうとすると、どうしても穴が出やすい」

    そこで活用が推奨されていた AWS サービスが IAM Access Analyzer です。

    機能の例：

    • IAM ポリシーを解析し、「外部アカウントからアクセス可能なリソース」を検出
    • ポリシーの提案（Policy generation）
    • 実際のアクセスログを分析して、「このロールに必要な最小権限」のポリシー案を生成

    ここでも AI を組み合わせると、

    • 「このポリシー JSON はどの権限をどこまで許可しているか、自然言語で説明して」
    • 「最小権限化するために、削れそうなアクションはどれか？」

    といった質問を投げることで 理解と設計の速度を上げられる、という話でした。

    自分自身、インフラ側への苦手意識が強いですが、こういった活用法を用いることで、AIエージェントの力を借りつつ、知識習得と堅牢な実装の両方を猛スピードで行なっていけるのでは？とワクワクしました。

    マネージドサービスと認証・認可はビジネス差別化になり得る

    AI が書いたコードのセキュリティオーナーは誰か？

    登壇者の方の問いかけ：

    「AI が生成したコードをそのまま本番投入してよいのか？
    その結果に対するセキュリティの責任は誰が持つのか？」

    結論としては、

    • 「全員がセキュリティのオーナー」
    • あくまで、AI は「候補」を出してくれる 存在
    • それを採用するかどうか、どうレビューするかは人間と組織の責任

    ということでした。
    本当にこの通りで、最後に出す判断を下すのは我々人間なので、これまで以上に、出すものは、本当にこれで問題がないのかは、厳格に見極める必要があるなと感じました。

    Culture of Security

    AWS では、社内外で継続的に、

    • セキュリティに関する発信
    • 勉強会
    • 事例共有
    • インシデントからの学びの共有

    を行い、トップダウンで 「Culture of Security」 を作っているという紹介がありました。
    組織やPJ のトップが、セキュリティへの関心や発信を積極的に行うことが、セキュリティへの意識・行動を想起するには重要とのことでした。

    参考：

    認証・認可設計は「ビジネス差別化」にもなる

    特に印象に残ったのが、

    「優れた認証・認可の仕組みは、
    セキュリティ対策であると同時に、ビジネスの差別化要因になる」

    というお話でした。

    • 各サービスごとにバラバラなユーザー管理をしている
      • ユーザー体験：ログインが面倒、アカウントが分散
      • 事業側：サービス横断の体験・クロスセルが難しい
    • 統合された認証・認可基盤がある
      • 一度ログインすれば複数サービスをシームレスに利用可能
      • ユーザー行動を横断的に把握できる

    セキュリティ設計がそのまま UX と事業戦略に効いてくるという例ですね。

    認可アーキテクチャの用語整理

    認可ロジックをアプリコードにべた書きせず、外部の仕組みに任せやすくするための概念として、以下の用語が紹介されていました。

    • PEP: Policy Enforcement Point
      実際のアクセス要求をブロック／許可する「ゲート」
    • PDP: Policy Decision Point
      ポリシーに基づき「許可／拒否」の判定を行うコンポーネント
    • PAP: Policy Administration Point
      ポリシー（ルール）を管理・編集するコンポーネント
    • PIP: Policy Information Point
      判定に必要な属性情報（ユーザー属性、リソース属性など）を提供するコンポーネント

    この分離により、アプリ側コードは「PEP と対話するだけ」で済み、 認可ルール自体は外部で一元管理しやすくなるとのことでした。

    参考：

    セキュリティ専門じゃないアプリケーションエンジニアとして、始めてみたい「脅威の洗い出し」（＋AI 活用）

    最後に、これまでのセッション内容を踏まえて、実際に現場で「脅威の洗い出し」をどう始めてみたいかを、具体的な手順として書いてみます。

    これから試してみたい「ざっくり手順」

    まず、自分用の「脅威の洗い出し」のざっくり手順（案）はこんなイメージです。

    1. 対象を決める
      • いきなり全システムではなく、「これから作る 1 機能 / 1 API」くらいにスコープを絞る
    2. ざっくり図を描く
      • 画面遷移 or API と外部サービスの関係、データフローを簡単に図にする
    3. 守りたいものを挙げる
      • ユーザー情報、決済情報、社内の機密データ、ポイント残高 など
    4. STRIDE を観点に「脅威のたたき台」を AI に出してもらう
    5. AI の結果を見ながら、チームで 60〜90 分だけ議論する
    6. 「今すぐ対応するもの」を 2〜3 個だけ決めて、実装・レビューに反映する

    仕様書を AI に渡して「脅威のたたき台」を作る

    • 要件定義書・仕様書・画面遷移図などを AI に渡して、
      「この仕様から想定されるセキュリティリスクを、STRIDE の観点で列挙して」 と依頼する
    • その出力をもとに、チームで 60〜90 分の脅威モデリングミーティングを行う

    「AI は“思いつきの網羅”担当、人間は評価と意思決定担当」 くらいに役割分担するイメージで進められたらと思います。

    依存ライブラリの脆弱性を AI に要約させる

    これもすぐにできて、セキュリティリスクを抑える有効な手段なので、書いておきます。

    • npm audit​ などの結果や、SCA ツールのレポートを AI に渡し、
      • 「特に優先度が高いものはどれか？」
      • 「どのライブラリは自分たちのアーキテクチャでは影響が小さそうか？」
        を整理してもらう

    これにより、「アラートの山」から「今すぐ直すべき山」を特定して、優先度の高い脆弱性を潰せる可能性を高めます。

    既存コードベースの「簡易セキュリティ健診」

    • 重要なモジュールや API ハンドラを中心に、AI に次のような観点で探してもらう
      • ハードコードされたパスワード／API キー
      • 認証・認可チェックが抜けていそうなエンドポイント
      • 危険な関数（eval​ など）の利用
    • その結果から「怪しい箇所リスト」を作り、 人間が一つずつレビューしていく

    AI には広く粗く見てもらって、最後の判断は人間で、という分業で進められたらと思います。

    セキュリティ文化を根付かせる動き

    脅威の洗い出しを一度きりのイベントにしないために、 次のような小さな仕掛けをチーム内で提案してみたいと思っています。

    • 大きな機能追加のたびに
      • 「脅威モデリングをやったか？」をチェックリストに入れる
    • 月 1 回程度の
      • 「インシデント／ヒヤリハット共有会」を開く
    • 上長に、セキュリティ文化を根付かせる発信やアクションを提案する （この記事を読んで頂こう）
      • ここにあげた手段を提案し、発信や実際に定期的イベントを行う

    いきなり、大きく完璧にやろうとすると、大抵続かない、うまくいかないので、まずは「新しい機能を作るタイミングで、脅威モデリングを行う」ところから始めてみたいと考えています。

    ゆくゆくは、組織単位で、例えば上記のようなことが浸透していけることが最終ゴールにできればなと思います。

    現時点では、ここに書いた「脅威の洗い出しのやり方」はあくまでこれから試してみたい案です。

    実際に回してみてうまくいった点・うまくいかなかった点が見えてきたら、続編としてアップデートしていきたいと思います。

    追記

    開発で携わっているPJ で、早速、新規API を作成する機会ができたので、早速、脅威モデリングをお試しでやってみようとなりました。

    初回なので、あまりに厳密にやりすぎず、脅威モデリングにおいて、重要な要素をシンプルに抽出して、進めていきます。

    「実際に、やってみた」の記事も書けたら、書きます。

    ※本記事は2026年02月時点の情報です。

    著者：マイナビエンジニアブログ編集部

    人気のあるタグ