はじめに

こんにちは。
SB C&Sの佐藤です。

AIによるコード生成や開発支援が広がる一方で、作成されたコードをどのように確認し、安全性を担保するかは重要なテーマになっています。
静的解析ツールや依存関係スキャンは以前から利用されていますが、検出された項目の中から、本当に対処が必要なものを見極めるには、アプリケーションの構造やデータフローを踏まえた判断が必要です。

そこで今回試したのが、Devinのセキュリティスキャン・修正支援機能である「Devin Security Swarm」です。
Security Swarmは、単に危険そうなコードパターンを列挙するのではなく、リポジトリの内容と設定した脅威モデルを基に、脆弱性候補の調査、優先度付け、ランタイム検証、修正用Pull Requestの作成までを支援します。

本記事では、Security Swarmの概要と必要性、実際の使い方、利用して感じた特徴、おすすめのユースケースを紹介します。

目次

• Devin Security Swarmとは
• なぜSecurity Swarmが必要なのか
• Security Swarmの使い方と、各段階でできること
• 実際に使って感じたこと
• おすすめのユースケース
• まとめ

Devin Security Swarmとは

Devin Security Swarmは、Devinのセキュリティスキャン・修正支援機能です。
リポジトリの内容に合わせた脅威モデルを作成し、潜在的な脆弱性を調査します。公式ドキュメントでは、リモートコード実行、SQLインジェクション、パストラバーサル、SSRF、認可回避、メモリ安全性に関する問題、サービス拒否につながる問題などが検出対象の例として挙げられています。複数ファイルにまたがる攻撃経路も調査対象です。

Security Swarmでは、複数のDevinがリポジトリ内を並列に調査し、結果をリポジトリ全体の視点でまとめます。そのため、特定のファイルに危険な記述があるかを確認するだけではなく、外部入力がどの処理を通り、最終的にどのデータや機能へ到達するかを追跡できます。
ただし、スキャンが完了したからといって、リポジトリに脆弱性がないことが保証されるわけではありません。結果はスキャン範囲、プロファイルの内容、リポジトリから得られる情報、ランタイム検証環境などに左右されます。既存のコードレビューや静的解析、依存関係スキャン、ペネトレーションテストを置き換えるのではなく、それらを補完する機能として利用するのが適切です。

なぜSecurity Swarmが必要なのか

実装時にコードレビューやテストを行っていても、後からセキュリティに特化した確認を行う意味はあります。
通常のコードレビューでは、要件を満たしているか、設計に沿っているか、保守しやすいかといった観点が中心になります。一方、セキュリティレビューでは、攻撃者が入力を制御できる場所、認証や認可を回避できる経路、他のユーザーやテナントのデータへ到達する可能性などを確認します。
つまり、同じコードでも、見る立場が変われば確認すべき点も変わるということです。

Security Swarmでは、攻撃者、保護対象、信頼境界、重要なエントリーポイント、調査対象外とする範囲をプロファイルに記載できます。また、異なる攻撃者像や脅威カテゴリを確認する場合は、プロファイルを分けてスキャンすることが推奨されています。

たとえば、同じリポジトリに対しても、次のように確認の目的を変えられます。

・未認証の外部攻撃者による侵入経路を確認する
・認証済みユーザーによる権限昇格を確認する
・マルチテナント環境のデータ分離を確認する
・管理APIや管理者機能を重点的に調査する
・SSRFや外部通信に対象を絞る

最初に広い範囲を確認し、その結果を踏まえて特定の脅威に絞ったスキャンを追加する使い方も考えられます。
実装時に一度確認して終わりにするのではなく、Security Swarmのようなツールを利用し、アプリケーションの変更内容や、その時点で注意したいリスクに合わせて調査条件を見直すことが重要です。

Security Swarmの使い方と、各段階でできること

Security Swarmでは、対象リポジトリを選んでスキャンを実行するだけでなく、調査方針の設定、結果のトリアージ、ランタイム検証、修正、継続的な再スキャンまで進められます。
ここでは、実際の利用に近い流れで紹介します。

1．リポジトリとスキャンプロファイルを指定する

はじめに、Security画面からスキャン対象のリポジトリを選択します。初回スキャンでは、Single repoから対象を指定し、インタラクティブモードを有効にして実行する手順が推奨されています。
Single repo以外にも「Multi-repo」、「Bulk scan」といったオプションが用意されています。スキャンを繰り返し利用する場合は、調査方針をスキャンプロファイルとして保存することも可能です。プロファイルには、主に次の内容を設定します。

・想定する攻撃者
・保護すべきデータや機能
・信頼境界と重要なエントリーポイント
・調査対象と対象外の範囲
・問題の調査方法と必要な根拠
・重複の扱いや重要度の判断基準
・ランタイム検証の手順
・修正時の制約やテスト要件

プロファイルは、各項目を手動で入力する方法と、アプリケーションの概要や懸念点を自然言語で伝える「Devinで生成」の2通りで作成できます。Devinで生成ではDevinが下書きを生成しますが、公式ドキュメントでも、利用前にすべての項目を確認するよう案内されています。

「Devinで生成」によるチャット画面

Devinで作成したプロファイル

2．脅威モデルを確認してスキャンを実行する

インタラクティブモードを有効にすると、Devinはプロファイルとリポジトリの内容を基に脅威モデル案を作成し、調査を始める前に一時停止します。

画面上で内容を確認し、そのまま開始するか、追加・削除・重点確認したい項目をフィードバックできます。初回スキャンや、アプリケーションのリスク範囲、プロファイルを大きく変更した場合に適した進め方です。プロファイルの内容が固まった後の定常的なスキャンでは、この確認待ちを省略できます。

脅威モデルでは、攻撃者になり得る人物、保護すべき情報、外部からアクセス可能な入口、信頼境界、想定される攻撃経路などが整理されます。
ここで重要なのは、生成された内容をそのまま受け入れないことです。
社内ネットワークからのみ利用できる機能や、APIゲートウェイ側で実施している認証、リポジトリ外で管理されているアクセス制御などは、コードだけでは把握できない場合があります。対象システムを理解している担当者が、前提条件を補足する必要があります。

スキャンを開始すると、複数のDevinがリポジトリ内を並列に調査します。危険な関数やコードパターンを見つけるだけでなく、攻撃者が制御できる入力から問題のある処理まで実際に到達できるか、途中に有効な入力検証や認可処理があるか、具体的な影響が発生するかを確認します。

3．検出項目を確認し、対応順を判断する

スキャン中は、検出項目が見つかるたびに画面へ追加されます。検出項目は重要度別に整理され、Open、Reviewed、Dismissedのステータスで管理できます。
各検出項目では、次の情報を確認できます。

・重要度
・悪用可能性 ※ランタイム検証が有効な場合に表示
・確信度
・脆弱性のカテゴリ
・影響を受けるファイルとコード
・問題の説明と修正案
・ランタイム検証を実施した場合の結果や証跡
・関連するPull Request（以降「PR」と記述）とその状態
・コードオーナーやノート

公式ドキュメントでも、危険なコードパターンが見つかっただけでは脆弱性の証明にならないと説明されています。攻撃者が制御できる入力から到達可能か、既存の検証や認可を考慮しているか、具体的な影響が示されているかを確認する必要があります。

またマークダウン形式の報告書も生成されるため、外部にむけたレポートに使用することも可能です。

この部分に関して今回使ってみて特に分かりやすいと感じたのは、実際のコードと照らし合わせながら、問題が成立する流れが説明される点です。
たとえば、「このAPIから入力を受け取る」「途中に十分な認可処理がない」「その結果、本来参照できないデータへ到達できる可能性がある」といった形で、指摘の根拠を確認できます。

今回は対象外でしたが、悪用可能性には攻撃に認証済みアカウントが必要か、特定の権限が必要かといった条件が示されます。単に脆弱性の名称や重要度を見る場合よりも、修正するか、追加調査するか、リスクを受容するかを考えやすくなります。
またプロファイルのトリアージガイダンスでは、重複する検出項目のまとめ方や、優先順位、重要度の判断基準を指定できます。

Security Swarmは「最終判断を代行する機能」というより、「大量の検出項目を人が確認しやすい形に整理する機能」と考えるのがよさそうです。

4．必要に応じてランタイム検証と修正を行う

ランタイム検証を有効にすると、Devinはアプリケーションを隔離された環境でビルド・実行し、検出した問題を再現できるか試みます。
ランタイム検証は、選択したプロファイルで機能が有効になっており、検証手順が記載されている場合に実行されます。アプリケーションの起動方法、テストデータの作成方法、認証方法、確認すべき挙動などをプロファイルへ記載します。検出項目ごとに別のDevinセッションが開始されます。

再現に成功した場合は、問題が実際に悪用可能であることを示す、より強い根拠になります。
一方、再現できなかった場合も、脆弱性が存在しないとは限りません。既存の防御策で攻撃が防がれた可能性もあれば、実行環境、テストデータ、認証設定が不足していた可能性もあります。結果とあわせて、検証時の証跡や環境上の制約を確認する必要があります。

今回の検証では、ランタイム上で再現可能な脆弱性が見つからなかったため、再現成功時の動作や証跡までは確認できませんでした。
それでも、コード上の可能性を示すだけでなく、条件が整えば実際の挙動まで確認できる仕組みは、対応優先度を考えるうえで有用だと感じました。

Security Swarmによって発見された対応が必要な検出項目は、Assign to Devinから修正用のDevinセッションへ割り当てられます。これによりDevinは修正を行い、PRを作成します。セッションと作成されたPRは、元の検出項目から追跡することが可能です。
また修正時に実施してほしいテストや、互換性に関する条件は、プロファイルの「修復ガイダンス」に記載することで反映させることが可能です。

実際に使って感じたこと

ここからは私が実際にSecurity Swarmを試してみて感じた良かった点と、個人的な要望を挙げていきます。

確認したいリスクに焦点を当てやすい

Security Swarmを使って最も特徴的だと感じたのは、ユーザー側で調査の焦点を調整できる点です。
一般的なセキュリティスキャンでは、ツール側に用意されたルールに従って、広い範囲を一律に調査するイメージがあります。

Security Swarmでは、「認証済みユーザーによる権限外アクセスを確認したい」「テナント間のデータ分離を重点的に見たい」といった意図を、プロファイルや脅威モデルへ反映できます。
目的が曖昧なままスキャンを始めるのではなく、何を守り、誰を攻撃者として想定するかを先に整理する必要があります。その手間はありますが、確認したいリスクと調査結果を結び付けやすいと感じました。

プロファイルで確認方針をそろえられる

プロファイルには、脅威モデルだけでなく、調査方法、重要度の基準、ランタイム検証、修正時の条件も記録できます。
同じプロファイルを再利用すれば、担当者が変わった場合でも確認方針をそろえやすくなります。

また、Generate with Devinを利用すれば、プロファイルの下書きをDevinに任せ、生成された内容を人が調整する形で準備できます。
プロファイル自体は定期的に見直す必要がありますが、リポジトリごとの確認基準を毎回一から説明しなくてよい点は、継続運用に向いていると感じました。

検出理由を追いやすい

検出項目では、問題のあるコードだけでなく、入力から影響が発生するまでの経路が示されます。
実際のコードと照らし合わせながら「ここで入力を受け取り、この制御を通らず、この処理へ到達する」と確認できるため、単にルール名や警告だけが表示される場合よりも内容を理解しやすくなっています。
Exploitabilityに具体的な条件が記載されることも、対応要否の判断に役立ちました。

ただし、リポジトリ外のネットワーク制御や運用上の制約は、結果に反映されていない場合があります。表示された説明だけで結論を出さず、自社環境の前提と照らし合わせる必要がありますのでご注意ください。

優先順位を付けやすい

セキュリティスキャンで検出項目が多くなると、確認作業そのものが負担になります。
Security Swarmでは、Severity、Exploitability、Confidence、コード上の根拠をまとめて確認できます。プロファイルでトリアージ方針も設定できるため、影響が大きく、悪用される可能性が高い項目から確認を始めやすくなっています。
結果を自動的に確定する機能ではありませんが、人が判断するための材料を整理してくれる点は実用的でした。

検出から修正へつなげやすい

検出項目からDevinへ修正を割り当て、PR作成まで進められる点も、Security Swarmの特徴です。
検出ツールと修正担当が分かれている場合、問題の内容、対象コード、攻撃経路、対応方針を別のIssueなどへ転記する必要があります。

Security Swarmでは、調査時の文脈を引き継いだ状態で修正セッションを開始できます。これにより、最終的なレビューは必要ですが、検出結果を修正作業へ渡す際の情報整理を減らせる可能性があると感じています。

【要望】検出項目について質問できるUIが欲しい

今回使ってみて、今後追加されると便利だと感じたのは、検出項目の画面から直接チャットできる機能です。
検出内容を確認していると、次のような点をその場で質問したくなります。

・この問題が成立する具体的な条件は何か
・既存の認可処理では防げないのか
・なぜこのSeverityになっているのか
・社内ネットワーク限定の場合、評価は変わるのか
・別の修正方法はあるのか
・修正によって既存機能へどのような影響が出るのか

現在もFeedbackを使って不足している前提を伝え、今後のスキャンプロファイルへ反映できます。また、Severityの調整やDevinへの割り当ても可能です。
一方、検出項目を起点として対話的に内容を掘り下げられれば、対応要否を判断するまでの調査がさらに進めやすくなると感じました。
※これは現行機能ではなく、今回の検証(2026年7月時点)を通じて感じた要望です

おすすめのユースケース

ここまでSecurity Swarmの機能についてご紹介してきましたが、ここからは実際に使ってみて感じた「Security Swarmを活用するおすすめユースケース」を紹介します！

リリース前の追加チェック

認証、認可、決済、管理機能、外部公開APIなど、影響の大きい変更が含まれるリリース前の確認に向いていると感じました。
初回や大規模な変更時にはフルスキャンを行い、通常時はAuto Scan、重要な変更の直後はScan new commitsを利用する運用が考えられます。

レガシーコードや引き継いだリポジトリの調査

長期間運用されているシステムや、別の担当者から引き継いだリポジトリでは、外部入力から重要な処理までの流れを把握するだけでも時間がかかります。
そこでSecurity Swarmを最初の調査に使い、検出された重要な経路を人が詳しく確認することで、対応工数を大きく減らすことが可能です。
ただし前述の通り、リポジトリ外のインフラストラクチャやネットワーク制御は別途確認が必要になりますのでご注意ください。

AIが生成・修正したコードの追加確認

AIによる実装を導入すると、複数ファイルにまたがる変更が短時間で作成されることがあります。AIが生成したコードだけを特別に危険視する必要はありませんが、人が作成したコードと同じように、重要な変更には目的に合った確認が必要です。
新しいAPI、認証経路、外部通信処理などが追加された場合に、実装時とは異なる攻撃者の視点で確認する用途に向いています。

組織内のセキュリティチェックの標準化

プロファイルを使えば、組織として確認したい脅威、重要度の基準、必要な証跡、修正時の条件を共有できます。
初回展開ではAll reposを使って対象リポジトリをまとめてキューへ追加し、その後は重要度や変更頻度に応じてAuto Scanの実行間隔を設定できます。
実際に運用する際には、すべてのリポジトリに同じプロファイルを適用するのではなく、外部公開サービス、社内システム、マルチテナントサービスなど、用途ごとに確認条件を分ける方が適切だと感じています。

まとめ

Devin Security Swarmを使って特に印象に残ったのは、次の点です。

・アプリケーションに合わせて脅威モデルを調整できる
・プロファイルを使って調査や判断の方針をそろえられる
・コード上の経路と悪用可能性を確認しながら対応要否を考えられる
・ランタイム検証によって、検出結果の根拠を補強できる
・検出項目からDevinによる修正とPR作成へつなげられる
・All repos、Auto Scan、Scan new commitsを使って継続運用できる

Security Swarmは、実行するだけですべての脆弱性を発見し、自動的に解決する機能ではありません。どのような攻撃者を想定するのか、何を保護するのか、どのような条件を重大と判断するのかを整理し、プロファイルや脅威モデルへ反映する必要があります。
そのうえで、コードの文脈を踏まえた調査、検出項目の整理、ランタイム検証、修正までを一つの流れで支援できることが、Security Swarmの特徴です。
既存のセキュリティツールや人によるレビューと組み合わせながら、リリース前の確認、認証・認可機能の変更、重要なリポジトリの定期スキャンなどに活用できる機能だと感じました。

今回の検証では、ランタイム上で再現できる脆弱性が見つからなかったため、再現成功時の証跡までは確認できませんでしたが、今後、該当する検出項目が得られた場合は、ランタイム検証によって対応判断がどの程度変わるかも確認したいと考えています！