generate-poc

PoC を生成するスキル

SAST で検出され、静的に確認された脆弱性を動的に再現してみます。Python スクリプトを使って実行中のインスタンスでテストし、結果を記録します。

入力

呼び出し元から提供されます。省略された場合はデフォルト値を使用してください。必須の入力が不足しており、妥当なデフォルト値もない場合に限り、呼び出し元に確認してください。

• project-root（任意）— 対象プロジェクトのルート。Opentaint はすべての解析成果物を固定の <project-root>/.opentaint/ ディレクトリ以下に保存するため、以下のすべての .opentaint/... パスはここを基点とします。デフォルト：カレントディレクトリ
• language（必須）— このプロジェクトの対象言語と言語固有の指示
• finding（必須）— 再現する TP の検出結果、.opentaint/tracking/findings/<name>.yaml
• base-url（任意）— アプリがすでに実行中の場合はそのベース URL。そうでなければ、ビルドして起動します

ワークフロー

1. アプリを起動する

base-url が指定されていれば、それを再利用します。指定されていない場合は、プロジェクトで想定されている方法でアプリをビルドして起動し（ビルドおよび実行コマンドについては、言語リファレンスを参照）、待ち受け状態（ヘルシー）になるまで待機して、ベース URL を記録します。PoC は稼働中のインスタンスにアクセスする必要があります。アプリがバックエンドサービス（DB、ブローカー、キャッシュなど）を必要とする場合は、サービスを個別に手動で起動するのではなく、共有ネットワーク上で 1 つの docker compose を使ってすべて起動し、単一の compose エントリとして登録します。インスタンスはループバックにバインドします（制約を参照）。待ち受け状態になったら、後でオーケストレーターが停止できるように（追跡を参照）登録します。

2. 検出結果を稼働中のリクエストに対応付ける

検出結果のソース位置からエントリーポイント（ルートとメソッド、汚染された入力を受け取るパラメーター／ヘッダー／本文フィールド）と、その入力をシンクまで到達させるペイロードを特定します。一般的な例を以下に示します。

• SQL インジェクション — ?id=1' OR '1'='1
• コマンドインジェクション — ?cmd=;cat /etc/passwd
• パストラバーサル — ?path=../../../etc/passwd
• XSS — ?q=<script>alert(1)</script>
• SSRF — ?url=http://169.254.169.254/latest/meta-data/
• XXE — <!ENTITY xxe SYSTEM "file:///etc/passwd"> を含む XML 本文

3. PoC スクリプトを作成して実行する

セットアップ（認証、状態のシードなど）を行い、リクエストを送信し、観測可能な証拠をアサートする自己完結型の Python スクリプトを .opentaint/pocs/<name>.py に作成します。再実行でき、自己検証するスクリプトにしてください。実行します。確認には観測可能な証拠が必要です。たとえば、返された行、ファイルの内容、コマンド出力、時間遅延、帯域外コールバック、インジェクションを示すエラーなどです。

4. 結果を記録する

• confirmed — スクリプトが実行され、記述された脆弱性を証明した場合。poc: confirmed を設定し、notes には単に最終リクエストを書くのではなく、成功した手順（セットアップ → リクエスト → 観測された証拠）を記述します
• failed — 複数回試しても検出結果を確認できなかった場合、またはアプリ／ルートに到達できなかった場合。poc: failed を設定し、スクリプトを保存し、試したパターンとそれぞれが成功しなかった理由を notes に記録します

出力

成果物

• .opentaint/pocs/<name>.py — PoC スクリプト。確認できたかどうかにかかわらず保持します
• .opentaint/tracking/findings/<name>.yaml — 検出結果の poc と notes を更新したもの（追跡を参照）
• .opentaint/tracking/poc-servers.yaml — 起動したインスタンスを登録したもの。再利用できるよう、実行状態のままにします（追跡を参照）

概要

• 結果（confirmed / failed）。failed の場合は、検出結果が未確認であること。インスタンスを起動した場合はベース URLも記載します

トラッキング

このスキルが書き込むのは、検出項目の poc（confirmed / failed）と、notes に追記する結果のみです。verdict やその他の検出項目のフィールドは変更しません。アプリのインスタンスを起動した場合は、サーバーレジストリにエントリを1つ追加し、そこで処理を終了します。停止処理は担当しません。

.opentaint/tracking/findings/<name>.yaml — 1つの検出項目を記録します。1つのルールの SARIF 結果をまとめ、トリアージと PoC の各段階で引き継ぎます。スキャン時にスクリプトが各ファイルを生成し、sarif_hashes、rule_id、アナライザーのレポートを notes に記録します。トリアージでは verdict を設定し、その根拠を追記します。PoC の段階では poc を設定し、その結果を追記します。コメントで明確にしてください

sarif_hashes: [a1b2c3d4, e5f6a7b8]
rule_id: <language>/security/sql-injection.yaml:sql-injection
verdict: TP
notes: >
  <analyzer report for these results — seeded from the scan>
  triage: the request's order field is attacker-controlled and reaches raw query construction → TP
  poc: a crafted order value produced the expected database delay → confirmed
poc: confirmed

.opentaint/tracking/poc-servers.yaml — PoC のために起動したアプリインスタンスのレジストリです。オーケストレーターがこれを読み取り、インスタンスを停止します。インスタンスごとに1つのエントリを記録します。kind（process | container | compose）、port、および停止コマンドの実行に使う対応する ref（pid、コンテナー ID／名前、または Compose ファイルのパス）を指定します。PoC は一度に1つずつ実行されるため、追記が競合することはありません。コメントで明確にしてください

servers:
  - kind: process
    port: 8080
    ref: "12345"

制約

• 起動したインスタンスはループバック（またはテストで本当に必要な特定の IP）にバインドし、0.0.0.0 やパブリックインターフェースにはバインドしないでください。実行中のエクスプロイトがホスト外に公開されないようにしてください
• 起動したインスタンスを停止せず、必ず登録してください。後処理はオーケストレーターが担当し、.opentaint/tracking/poc-servers.yaml に登録されたインスタンスだけを停止できます
• 結果は検出項目のファイルのみに記録し、.opentaint/vulnerabilities.md には絶対に書き込まないでください

注意点

• 仮説ではなく、再現してください。実行していないスクリプトや、観測可能な効果のない HTTP 200 は、確認の根拠になりません
• failed は false positive を意味しません。再現できなかったからといって、コードが安全である証明にはなりません（認証、状態の欠落、誤ったペイロードなどが原因の可能性があります）。failed を記録し、この段階では verdict を変更しないでください