getdebug 0.4.0、Python AI アプリのセキュリティパターン検出を追加

AI アプリコードベース走査用CLIツールであるgetdebugがバージョン0.4.0をリリースし、Python向けの5つの決定論的で正規表現ベースの脆弱性パターン検出器（prompt-injection、unsafe-role-merge、pii-in-prompt、unbounded-stream、unsafe-tool-output）が追加されました。これらのパターンは0.3.0で提供されたJS/TSディテクターに加わります。ツールはミリ秒単位で実行され、費用がかかり、LLM呼び出しを必要としません。subprocess.run(tool_call.input.command, shell=True)またはstream=TrueタイムアウトガードなしなどのSDKイディオムに対する静的パターンマッチングのみです。

チームはgetdebugを3つの競合者に対してベンチマークしました：Bandit（Python OSS セキュリティリンター標準、手書きルール、Pythonのみ）、Semgrep（コミュニティルールパック付き多言語SAST、手書きルール）、vulnhuntr（Protect AI のオープンソースLLMアプリ静的アナライザー、LLM駆動型、Pythonのみ、エントリーポイント検出ベース）。10ペアの脆弱/安全なPythonフィクスチャー（脆弱性パターンカテゴリーあたり1ペア）に対する合成テストでは、getdebugは83%の精度と100%のリコール（5真陽性、1偽陽性、0偽陰性）を達成しました。BanditとSemgrepは両方とも50%の精度と20%のリコール（1真陽性、1偽陽性、4偽陰性）を記録しました。これは、安全なバリアント（model出力ではなく静的アローリストから値を受け取ったsubprocess.run(shell=True)）にフラグを立てたためです。どちらのツールもcmdが静的辞書から来たことを理解しませんでした。getdebugの正規表現要件では、tool_call.input.Xがシンク引数に出現する必要があり、その誤検知をフィルタリングしました。両ツールは他の4つの振る舞いカテゴリーも完全に見落としました。ルールパックにはprompt-injection、pii-in-prompt、unsafe-role-merge、unbounded-streamのパターンがありません。

実世界テストは3つの機能するツールをすべてsimonw/llm（Simon Willison氏のLLMと対話するためのCLI、49 Pythonファイル、コミット0d593ea）で実行しました。Banditは1,261件の検出結果を返しました。そのうち1,228件がpytestアサーション上のassert_usedにフラグを立てたもので、Banditのデフォルト設定に関する長年の不満です。残りのシグナルはAIアプリカバレッジがゼロでした。Semgrepは3件の汎用SASTヒット（プラグインシステム向けのcli.pyのexec()、静的HTMLアセット上の欠落した整合性属性、非リテラルインポート）を検出しました。ここでも、AIアプリ固有のものはゼロです。getdebugは7件の検出結果を表示しました：6件がAIアプリカテゴリ分類済み（テンプレート機能連結からの1件のプロンプトインジェクション、OpenAIプラグイン内の5件のunbounded-streamヒット、stream=Trueでスコープ内にタイムアウトなし）、1件がボーダーラインロールマージ（APIの独自レスポンスをエコーするロール、リクエスト入力ではない）。すべてはHIGH/MEDIUM（CRITICALではない）としてフラグ立てされ、トリアージの文脈がありました。vulnhuntrはPython 3.11上できれいにインストールされましたが、エントリーポイントヒューリスティックがネットワーク公開ウェブアプリを対象とし、CLIツールではないため、0件のファイルを選択しました。

チームは以前のバージョン（0.4.0）が合成フィクスチャー上でクリーンスイープを示したことを認識しましたが、0.5.5で追加された更新された検出器（scanPyShellToolArg）は、tool_call.input.tagが静的ルーティングを理解せずにshell=Trueに到達するのを見ているため、その安全なアローリストケースをCRITICALとしてフラグ立てするようになりました。この回帰は厳密化のために追跡されています。著者は3つのツールカテゴリーをすべて補完的に実行することをお勧めします。Banditはassert_usedを無効にしてPython衛生（ assert_usedを無効）、Semgrepは言語横断型SAST、getdebugはAIアプリ振る舞いパターンのために。ベンチマークコーパス、方法論、ハーネスはGitHub上のCodeSecBench下でオープンソース化されており、ツールはnpm（@getdebug/cli@0.4.0）またはHomebrew（getdebug-ai/tap/getdebug）でインストールできます。

getdebugはオープンソースセキュリティリンティング環境における本当のブラインドスポットに対処しています。BanditとSemgrepは、それぞれPythonセキュリティと言語横断型SASTに設計された成熟した広く使われるツールで、SQLインジェクション、安全でないデシリアライゼーション、欠落した整合性チェックの検出に優れています。しかし、どちらもLLM固有のリスク、つまりユーザーオブジェクトのプロンプトへのシリアライゼーション、タイムアウトなしのストリーミング、メッセージアレイ内の互換性のないロールフィールドのマージを理解するよう設計されていません。ベンチマークはその汎用性のコストを示唆しています。49ファイルのコードベース上でBanditの1,228件のassert_used警告はほとんどの本番環境ではノイズであり、Semgrepの3件の検出結果は実在していますが汎用的で、AIアプリ固有ではありません。

vulnhuntrはLLM駆動型AIアプリ分析のカテゴリーリーダーとして位置づけられており、LLMを呼び出してエントリーポイントと脆弱性を推測することで異なるアプローチを採用しています。トレードオフはスコープです。ファイル選択はウェブアプリヒューリスティックに基づいており、CLIツールは分析されません。getdebugの正規表現層はウェブであろうとコマンドラインであろうと、LLM SDKと接触するあらゆるPythonで実行することでこれを回避しています。別方向でのトレードオフは、手書きされた正規表現パターンはLLMが推測する可能性のある新しい攻撃対象領域を見落とすことです。ツール設計者はこれを認め、オープンコミュニティからのフィードバックを招待しています。

公開ベンチマーク方法論とオープンソースコーパス（GitHub上のCodeSecBench）は透明性に高い基準を設定しています。simonw/llmの実世界テストでは、getdebugの7件の検出のうち2件は脅威モデルに依存しており（単一ユーザーツール内の2つのCLIユーザー入力間のプロンプトインジェクション）、リクエスト入力ではなくAPIレスポンスを通じてルーティングされるロールマージロジックです。ツールはフラグ立てされたすべてを表示し、チームは.getdebug-ignoreファイル経由でトリアージでき、境界線的なケースを認識しています。これは誤検知の削減と完全性とのトレードオフを優先する立場です。

まだコメントがありません。最初のコメントを投稿しましょう！