Factory AIとSnyk Studioで検出された脆弱性にパッチを適用

著者

0 分で読めます

Factory AIのDroidsでプログラミングするのはとても楽しい体験です。一貫性があり、スムーズで、心躍る。まるでゲームをプレイしているようです。この理想へのこだわりは、UIだけでなくパートナーシップにも表れています。主要なインテグレーションの1つがLinearとの連携です（Jiraの新興競合で、リアクティブなWebアプリのアニメーションやキーボードショートカットによる優れたUXで知られています）。Claude Code、OpenAI Codex、Gemini CLIがオフラインのWord文書だとすれば、Factory AIは、チームでの共同作業を前提に一から構築されたオンライン版Google Driveです。

「FACTORY」という見出し、エージェントネイティブなソフトウェア開発の説明、「[ enter to continue ]」というプロンプトが表示されたFactoryのランディング画面。

開発者向けの導入体験には、ウェブサイトに組み込まれた丁寧なチュートリアルがあり、次の手順を順を追って案内してくれます。

Factory CLIをダウンロードする
Droid IDE ExtensionをVS Code、またはお好みの派生版（CursorやWindSurfなど）に追加する
ブラウザーまたはIDEで、Droid（Factory AIの専用AIエージェント）に最初のタスクを与える

Linuxをお使いの場合は、次のようにFactory CLIをインストールできます。

curl -fsSL https://app.factory.ai/cli | sh

VS Code用の拡張機能はこちらから入手できます。インストール後、`Ctrl-Shift-P`でコマンドパレットを開き、Run Factory Droidを選択します。

SnykのプロジェクトディレクトリでFactory Droid v0.19.9が実行され、AIコマンドプロンプトと更新成功メッセージが表示されたターミナル

Droidとは？

Factory AIは、幅広い一般的なソフトウェア開発タスクに対応する専用AIエージェントを提供しています。これらはDroidsと呼ばれます。

Code Droid: アイデアをマージ可能なコード変更へ。明確な要件に基づいて、新しい機能やコンポーネントを作成します。Code Droidはコードベースを理解し、プロジェクトのパターンやベストプラクティスに沿って機能を実装できます。複雑または非効率なパターンを見つけ、機能を維持しながら、よりクリーンで保守しやすいコードに変換して既存コードを改善します。エラーログを分析して根本原因を特定し、コードベースのバグを修正します。包括的な単体テストを作成し、コードの信頼性を高め、アプリケーションでのデグレードを防ぎます。
Knowledge Droid: エンジニアリング調査、技術文書、オンボーディングガイドを作成。APIリファレンス、アーキテクチャの概要、コンポーネント間の関係など、コードベースの包括的なドキュメントを生成して、チームの理解とオンボーディングを促進します。プロジェクト内の複雑なシステム、アーキテクチャ上の判断、実装の詳細をわかりやすく説明し、各コンポーネントの連携についてチームメンバーが理解できるよう支援します。コードベースやドキュメントから必要な情報をすばやく検索・抽出できるため、実装の詳細を探したり、特定の機能を理解したりする時間を短縮できます。
Reliability Droid: インシデントを調査し、根本原因分析（RCA）を作成し、複雑なマルチサービスシステムをデバッグ。エラーログ、メトリクス、システムの挙動を調べて本番環境のインシデントを分析し、障害やパフォーマンス低下のパターンと原因の可能性をすばやく特定します。タイムライン、影響評価、根本原因の特定、予防策を含む包括的な根本原因分析（RCA）ドキュメントを作成し、関係者と共有できます。サーキットブレーカー、リトライロジック、グレースフルデグラデーションなどの堅牢なエラー処理を実装し、システムのレジリエンスを高めて連鎖障害を防ぎます。
Product Droid: 機能を計画し、PRDを作成し、プロジェクトを管理。新製品機能について、概要、ユーザーストーリー、受け入れ基準、技術的な考慮事項、実装フェーズを含む詳細な製品要件ドキュメント（PRD）を生成します。さまざまなユーザータイプやシナリオに応じた、詳細な受け入れ基準付きの包括的なユーザーストーリーを作成し、開発チームがユーザー視点で機能要件を理解できるようにします。機能リクエストを分析し、影響度と工数の評価に基づく優先順位付けの枠組みを構築して、プロダクトチームの実装順序の判断を支援します。

あらかじめ構築された専用エージェントのライブラリを提供するという、AIエージェントの現代的なアプローチにより、ユーザーはLLMの限られたコンテキストウィンドウを最大限に活用できます。Claude Code、OpenAI Codex、Gemini CLIのようなツールが提供する単一のエージェントも、同様に幅広いタスクへ柔軟に応用「できます」。一方Factory AIは、特定の目的に特化したエージェントを提供するために時間をかけ、コンテキストを的確に管理できるようにしています。もちろん、専用Droidsの対応範囲外の用途に使える汎用Droidもライブラリに含まれており、必要に応じて活用できます。

うれしいことに、Factory AIでは特定のLLMベンダーに縛られません。よく知られたベンダーはすぐに利用できます（下記参照）。推論などに特化した独自のバリエーションを持つLLMも、同じUIダイアログから簡単に選択できます。

Claude Sonnet 4.5が選択され、推論レベルが「低」に設定されたモデル選択メニュー。ほかのAIモデルとコスト倍率も表示されています。

MCPのサポート

他のAIエージェントCLIと同様に、Droid CLIはModel Context Protocol（MCP）を強力にサポートしています。お気に入りのMCPサーバーも簡単に追加できます。

サーバー管理メニューに、SNYKとWeather MCPサーバーが接続されたFactory AIのターミナル画面。

たとえば、公式Snyk MCP Serverは次のように追加できます。

droid mcp add --type stdio SNYK "snyk mcp -t stdio"
Added stdio MCP server SNYK with command: snyk mcp -t stdio

では、これを使って何ができるでしょうか？すでに高機能なDroidにツールを追加するメリットは何でしょう？シェルコマンドの実行や、ファイルの読み取り、書き込み、編集は、すでに標準でサポートされています。

AIエージェント（Droids）を使って脆弱性に自動でパッチを適用する

この例では、OWASPのプロジェクトリーダーadeyosemanputra’sによるpyGoatリポジトリをクローンしました。このプロジェクトには、教育目的で、十分に文書化された脆弱性が意図的に複数含まれています。Snyk独自のIDE拡張機能が検出した脆弱性の一部を以下に示します。

Pythonのデシリアライゼーション脆弱性と、「信頼できないデータのデシリアライゼーション」（CWE-502）に関するSnykの詳細を表示したダークモードのコードエディター。

DroidにMCPサーバーを使わせて、同じ脆弱性の一部を一覧表示することもできます。ご覧ください。

>  Please run a code scan on the codebase with Snyk.

⛬  I'll help you run a Snyk code scan on the pygoat codebase. Let me first check the
   authentication status and then perform the scan.

 PLAN   Updated: 3 total (2 pending, 1 in progress, 0 completed)

 ○ Check Snyk authentication status
 ○ Run Snyk code scan on pygoat codebase
 ○ Review and report scan results

 [MCP] SNYK:SNYK_AUTH_STATUS 
 ↳stephen.thoemmes

⛬  Great! You're authenticated as stephen.thoemmes. Now I'll run the Snyk code scan on
    the pygoat codebase to identify security vulnerabilities.

 PLAN   Updated: 3 total (1 pending, 1 in progress, 1 completed)

 ○ Check Snyk authentication status
 ○ Run Snyk code scan on pygoat codebase
 ○ Review and report scan results

 [MCP] SNYK:SNYK_CODE_SCAN  (/home/owler/Documents/Snyk/factory/pygoat)
 ↳
 Testing /home/owler/Documents/Snyk/factory/pygoat ...

  ✗ [Low] Use of Hardcoded Credentials 
    Path: introduction/playground/A9/api.py, line 17 
    Info: Do not hardcode credentials in code. Found hardcoded credential used in a 
 condition.

…

  ✗ [High] SQL Injection 
    Path: introduction/views.py, line 871 
    Info: Unsanitized input from an HTTP parameter flows into 
 introduction.models.sql_lab_table.objects.raw, where it is used in an SQL query. This 
 may result in an SQL Injection vulnerability.

…

 ✔ Test completed

 Organization:      stephen.thoemmes
 Test type:         Static code analysis
 Project path:      /home/owler/Documents/Snyk/factory/pygoat

 Summary:

   101 Code issues found
   15 [High]   44 [Medium]   42 [Low] 

 PLAN   Updated: 3 total (0 pending, 0 in progress, 3 completed)

 ○ Check Snyk authentication status
 ○ Run Snyk code scan on pygoat codebase
 ○ Review and report scan results

⛬  The Snyk code scan has completed successfully! Here's a summary of the security
   findings:

   Scan Results Summary

   Total Issues Found: 101
   •  15 High severity vulnerabilities
   •  44 Medium severity vulnerabilities
   •  42 Low severity vulnerabilities

   Key High-Severity Issues Found:
   1. SQL Injection - Multiple instances in views.py
   2. Code Injection - eval() usage with unsanitized input
   3. Command Injection - subprocess.Popen with unsanitized input
   4. Path Traversal - File operations with unsanitized paths
   5. XML External Entity (XXE) Injection - Insecure XML parsing
   6. Deserialization vulnerabilities - pickle.loads and yaml.load with untrusted data
   7. Hardcoded cryptographic keys - JWT keys hardcoded in source
   8. Hardcoded secrets - Non-cryptographic secrets in code

   Medium/Low Severity Issues:
   •  Hardcoded passwords and credentials
   •  CSRF protection disabled on multiple endpoints
   •  Insecure cookie configurations (missing HttpOnly/Secure flags)
   •  Weak hashing algorithms (MD5)
   •  Debug mode enabled in production
   •  SSRF vulnerabilities

   This is a comprehensive security assessment showing that pygoat (being a
   deliberately vulnerable application for educational purposes) contains numerous
   intentional security flaws across all severity levels, making it an excellent
   training platform for learning about web application security vulnerabilities.

最後に、Code Droidを選択した状態で、LLMにこれらの高優先度の脆弱性の1つを修正するよう依頼できます。

>  ✗ [High] SQL Injection 
       Path: introduction/views.py, line 871 
       Info: Unsanitized input from an HTTP parameter flows into 
    introduction.models.sql_lab_table.objects.raw, where it is used in an SQL query. 
   This 
    may result in an SQL Injection vulnerability. Can you fix this vulnerability and 
   then re-scan to show that it is fixed?

⛬  I'll help you fix the SQL injection vulnerability on line 871 in
   introduction/views.py and then re-scan to verify the fix. Let me first examine the
   vulnerable code.

 PLAN   Updated: 3 total (2 pending, 1 in progress, 0 completed)

 ○ Examine SQL injection vulnerability on line 871 in views.py
 ○ Fix the SQL injection vulnerability using parameterized queries
 ○ Re-run Snyk scan to verify the fix

 READ  (introduction/views.py, offset: 860, limit: 20)
 ↳ Read 22 lines.

⛬  Let me see more context around the vulnerable code to understand how the SQL query
   is constructed:

 READ  (introduction/views.py, offset: 840, limit: 40)
 ↳ Read 42 lines.

⛬  Now I can see the vulnerability clearly. The SQL query on line 855 is constructed
   by directly concatenating user input without sanitization. Let me also check the
   imports to see what model is being used:

 GREP  ("from.*models import|import.*mo...", content mode)
 ↳ Read 1 line.

 GREP  ("sql_lab_table", content mode)
 ↳ Read 7 lines.

⛬  Perfect! Now I understand the vulnerability. The code is directly concatenating
   user input (name and password) into the SQL query string, making it vulnerable to
   SQL injection. Let me fix this by using parameterized queries:

 PLAN   Updated: 3 total (1 pending, 1 in progress, 1 completed)

 ○ Examine SQL injection vulnerability on line 871 in views.py
 ○ Fix the SQL injection vulnerability using parameterized queries
 ○ Re-run Snyk scan to verify the fix

 EDIT  (introduction/views.py)
 ↳ Succeeded. File edited. (+3 added, -2 removed)

 ╭───────────────────────────────────────────────────────────────────────────────╮
 │ 854 │  854           print(password)                                          │
 │ 855 │  855                                                                    │
 │ 856 │  856           if name:                                                 │
 │ 857 │      -             sql_query = "SELECT * FROM introduction_sql_lab_tabl…│
 │     │  857 +             # Fixed SQL injection by using parameterized query   │
 │     │  858 +             sql_query = "SELECT * FROM introduction_sql_lab_tabl…│
 │ 858 │  859                                                                    │
 │ 859 │  860               sql_instance = sql_lab_table(id="admin", password="6…│
 │ 860 │  861               sql_instance.save()                                  │
 │                                                                               │
 │... 7 unchanged lines ...                                                      │
 │                                                                               │
 │ 868 │  869               print(sql_query)                                     │
 │ 869 │  870                                                                    │
 │ 870 │  871               try:                                                 │
 │ 871 │      -                 user = sql_lab_table.objects.raw(sql_query)      │
 │     │  872 +                 user = sql_lab_table.objects.raw(sql_query, [nam…│
 │ 872 │  873                   user = user[0].id                                │
 │ 873 │  874                   print(user)                                      │
 │ 874 │  875                                                                    │
 ╰───────────────────────────────────────────────────────────────────────────────╯

⛬  Great! I've successfully fixed the SQL injection vulnerability by:

   1. Changing the SQL query construction: Instead of directly concatenating user
      input into the SQL string, I'm now using parameterized query placeholders (%s)
   2. Using parameterized execution: The raw() method now receives the parameters as a
       separate list [name, password], which ensures proper escaping and prevents SQL
      injection

   Now let's run the Snyk scan again to verify that this specific vulnerability has
   been fixed:

 PLAN   Updated: 3 total (0 pending, 1 in progress, 2 completed)

 ○ Examine SQL injection vulnerability on line 871 in views.py
 ○ Fix the SQL injection vulnerability using parameterized queries
 ○ Re-run Snyk scan to verify the fix

 [MCP] SNYK:SNYK_CODE_SCAN  (/home/owler/Documents/Snyk/factory/pygoat)
 ↳
 Testing /home/owler/Documents/Snyk/factory/pygoat ...

  ✗ [Low] Use of Hardcoded Credentials 
    Path: introduction/playground/A9/api.py, line 17 
    Info: Do not hardcode credentials in code. Found hardcoded credential used in a 
 condition.

…

  ✗ [High] Hardcoded Non-Cryptographic Secret 
    Path: pygoat/settings.py, line 25 
    Info: Avoid hardcoding values that are meant to be secret. Found a hardcoded string 
 used in here.

 ✔ Test completed

 Organization:      stephen.thoemmes
 Test type:         Static code analysis
 Project path:      /home/owler/Documents/Snyk/factory/pygoat

 Summary:

   100 Code issues found
   14 [High]   44 [Medium]   42 [Low] 

 PLAN   Updated: 3 total (0 pending, 0 in progress, 3 completed)

 ○ Examine SQL injection vulnerability on line 871 in views.py
 ○ Fix the SQL injection vulnerability using parameterized queries
 ○ Re-run Snyk scan to verify the fix

⛬  Perfect! The fix has been successfully verified. Here's what happened:

   ✅ SQL Injection Vulnerability Fixed!

   Before the fix:
   •  101 total issues (15 High, 44 Medium, 42 Low)
   •  SQL Injection vulnerability at introduction/views.py, line 871

   After the fix:
   •  100 total issues (14 High, 44 Medium, 42 Low)
   •  The SQL injection vulnerability is no longer reported ✅

   Summary of the Fix

   I successfully fixed the SQL injection vulnerability by:

   1. Replaced vulnerable string concatenation:
      ```python
      # BEFORE (vulnerable):
      sql_query = "SELECT * FROM introduction_sql_lab_table WHERE id='"+name+"'AND
   password='"+password+"'"
      user = sql_lab_table.objects.raw(sql_query)
      ```

   2. With secure parameterized query:
      ```python
      # AFTER (secure):
      sql_query = "SELECT * FROM introduction_sql_lab_table WHERE id=%s AND
   password=%s"
      user = sql_lab_table.objects.raw(sql_query, [name, password])
      ```

   The Snyk scan now shows 1 fewer issue (from 101 to 100), confirming that the
   specific SQL injection vulnerability on line 871 has been eliminated. The fix uses
   Django's built-in parameter binding which automatically escapes user input and
   prevents SQL injection attacks.

これは、DevSecOpsワークフローにおける新たな可能性を示しています。セキュリティを独立した、対応が遅れがちな課題として扱うのではなく、脆弱性の検出と修正を開発プロセスに直接組み込めるようになりました。Factory AIの専用エージェントとSnykのようなMCPサーバーを組み合わせれば、セキュリティ問題を特定するだけでなく、開発者がすでに作業している同じインターフェース内で、迅速に修正し、その正しさを再検証できます。

Factory AIとSnyk Studioで次のステップへ

MCPの導入が進み、より多くのセキュリティツールがMCPサーバーを提供するようになれば、脆弱性の修正だけでなく、セキュリティテストの生成、修正内容を反映したドキュメントの更新、複雑な問題を人が確認するためのチケット作成まで行うDroidsが実現できるでしょう。FactoryのDroidシステムとMCPプロトコルはどちらもモジュール型のため、相互運用性を保ちながら、それぞれ独立して進化できます。

同様のワークフローを導入したいチームにとって、セットアップは簡単です。Factory CLIをインストールし、お好みのMCPサーバーを追加して、脆弱性へのパッチ適用を始め、自動修正のプロセスへの信頼を築きましょう。重要なのは、AIエージェントをセキュリティチームの代替ではなく、その能力を何倍にも高める存在として捉えることです。AIエージェントは定型的で理解しやすい修正を得意とし、人間は創造的な問題解決が必要な新しいセキュリティ課題に集中できます。

MCP Serverエコシステムのセキュリティについて詳しく知りたい方は、今すぐEbookをダウンロードしてください。

EBOOK

MCPサーバーエコシステムを安全に保護する

新たな攻撃経路を探り、実際に起きたインシデントを分析し、開発フローを踏まえた実践的な戦略でどのように対処するかを解説します。

電子書籍をダウンロード

実際に試してみませんか？

Droidとは？

MCPのサポート

AIエージェント（Droids）を使って脆弱性に自動でパッチを適用する

Factory AIとSnyk Studioで次のステップへ

MCPサーバーエコシステムを安全に保護する