GET /v1/findings (API キー) または MCP の list_findings ツール (OAuth) を使用します。どちらも同じフィルターを使用し、同じサマリーフィールドを返します。
検出結果を一覧表示する
クエリパラメータ
レスポンス
findings の各項目には次のフィールドが含まれます。
レスポンスには、ページネーション用の
total、limit、offset、next_cursor も含まれます。offset + len(findings) >= total になるまで offset を使用してください。next_cursor は不透明なページネーションマーカーです。
ダッシュボードと一致させる
MindFort の UI では、API パラメータに対応するタブとフィルターを使用しています。exclude_secured=true を指定しない場合、一覧の結果には、ダッシュボードのデフォルトの Open タブでは非表示になっている情報提供用の secured プローブの検出結果 (severity=secured) が含まれます。API や MCP の件数が UI より多く見えるのは、これが原因である可能性があります。例
ターゲットの脆弱性 (デフォルトの Open タブと一致):検出結果の詳細を取得する
description、impact、evidence、approach、remediation_advice、status、再テストの判定コンテキストを含むすべてのフィールドを返します。
現在の実行状態は retest_status で判断します。
QUEUED: 受け付け済みだが、まだ実行されていないRUNNING: 実行中FAILED: 実行を完了できなかった。retest_failure_reasonを確認してくださいCOMPLETED: 検証が完了し、その結果が検出結果のライフサイクルに適用された
ステータスを更新する
ACTIVE、RESOLVED、ARCHIVED。status が RESOLVED の場合は、resolve_reason (FIX または WONT_FIX) と、任意の resolve_context (最大 2000 文字) を含めることができます。
一括更新は POST /v1/findings/status で利用でき、最大 50 件の finding_ids を指定できます。
重大度を上書きする
critical、high、medium、low、secured。上書きを解除するには null を渡します。info は secured の非推奨エイリアスとしてのみ受け付けられます。
検出結果を再テストする
ACTIVE、RESOLVED、または ARCHIVED の検出結果に対して非同期の再テストを開始します。別の再テストがすでにキュー待ちまたは実行中の場合、リクエストは失敗します。
リクエストが受け付けられたら、GET /v1/findings/{finding_id} をポーリングします。再テストが完了すると、MindFort は検証結果を適用します。
- テストした条件下で問題が修正されたことを示す再テスト結果の場合、検出結果は
RESOLVEDになります。 - 問題が引き続き再現可能であることを示す再テスト結果の場合、検出結果は
ACTIVEになります。 - 実行に失敗した場合、セキュリティ上の結果は変更されず、
retest_failure_reasonが設定されます。
RUNNING および FAILED への遷移では検出結果の updated_at が更新されるため、変更ベースで処理するコンシューマーもこれらを検知できます。
コメント
PATCH /v1/findings/{finding_id}/comments/{comment_id} を、削除には DELETE /v1/findings/{finding_id}/comments/{comment_id} を使用します。
パッチのサマリー
pr_url、patch_status、patch_state とともに返します。現在のユーザーの検出結果に限定するには assigned_to_me=true を、検出結果の ID、タイトル、説明、エンドポイント、影響で検索するには search を使用します。認可された組織には、プライベートリポジトリの URL を含め、保存されている GitHub プルリクエストの URL が返されます。パッチのアクティビティは、検出結果のライフサイクルステータスとは独立しています。
分析
検出結果の分析エンドポイントは、任意のtarget_id を受け付けます。組織全体のメトリクスを取得するには省略してください。GET /v1/findings/severity-score-history は granularity (day、week、または month) を受け付け、修正状況のメトリクスでは、さらに任意で両端を含む from と to の日付を指定できます。
ターゲットのヘルススコアは
GET /v1/targets/{target_id}/health-score で取得できます。
MCP
MCP ガイドでは、list_findings ツールで同じ意味のフィルターを利用できます。target_id、assessment_id、status、exclude_secured、severity、sort_by、order_direction、search、または割り当てに関するフィルターを渡してください。MCP のコレクションツールは、生のオフセットではなく不透明な cursor を使用します。
サーバーの更新後に MCP を再インストールする必要はありません。同じ https://api.mindfort.app/mcp URL のまま、エージェントを再起動するか新しいチャットを開始すれば、最新のツールスキーマが読み込まれます。
再テストの認証情報を復旧する
retest_failure_code が認証の失敗または利用できない認証情報を示している場合は、同じターゲットの代替の認証情報で再試行してください。公開の再テストリクエストでは、代替のプライマリ認証情報として target_credential_id を指定できます。2 つの認証情報を使用する検出結果で両方のアカウントを確認するには、ダッシュボードを使用してください。
代替の指定は、条件を満たす認証情報の失敗があった後にのみ許可されます。これにより今後の再テストで使用する認証情報が変更されますが、元の検出結果に記録された認証情報は変更されません。顧客に表示される説明については、retest_failure_reason を確認してください。検出結果の再テストを参照してください。
誤検知を記録する
検出結果のライフサイクルステータスを更新する際、誤検知と判断した場合は、status: "ARCHIVED"、resolve_reason: "FALSE_POSITIVE"、および判断の理由を説明する空でない resolve_context を使用します。FIX と WONT_FIX は、RESOLVED の検出結果に対する解決理由です。リクエストの完全な仕様については、ステータスエンドポイントのスキーマを参照してください。