> ## Documentation Index
> Fetch the complete documentation index at: https://docs.corgea.app/llms.txt
> Use this file to discover all available pages before exploring further.

# トリアージの理由

> 検出結果を終了するときに理由を必須にする

## 概要

検出結果を終了すると、監査記録として恒久的に残ります。「誤検知」「リスクを受け入れる」といったコメントは、すでにステータスに記録されている決定を繰り返しているだけです。数か月後にその検出結果を読む人（チームメンバー、新しい担当者、監査担当者）は、そこから何も分かりません。

Corgeaは、ステータス変更時に書かれたコメントを確認し、決定の理由が説明されていない場合は書き直しを求めます。求める水準は高くありません。読んだ人が確認できる具体的な一文があれば十分です。

<Note>
  理由の要件はステータス変更のコメントに対するものです。誰がステータスを変更できるかは変わらず、引き続き`change_issue_status`権限で制御されます。[権限グループ](/ja/permission_groups)を参照してください。
</Note>

## 適用される範囲

この確認は、ステータス変更が記録されるすべての場所で実行されます。

* 検出結果の詳細ページの**Change Decision**モーダル
* [脆弱性ワークベンチ](/ja/vulnerabilities)の詳細ドロワー
* 一括トリアージのアクションバー（SAST、SCA、IaCの検出結果を含む）
* [Corgea Agent](/ja/agent)を通じてプルリクエストから依頼された却下

検出結果の再オープンは対象外です。再オープンは何も却下しないため、理由の要件はありません。

## 適切な理由とは

読んだ人が確認できる具体的な内容が1つでも含まれていれば、理由として受け入れられます。次のいずれかで十分です。

<Check>
  * **コードを安全にしている制御**: 入力検証、出力エスケープ、パラメータ化されたクエリ、認可チェック、フレームワークによる保証など
  * **入力が信頼できる理由、またはこの環境でそのパスに到達しない理由**
  * **リスクを受け入れる補完的な制御や業務上の理由**（担当者、期限、範囲があるとなお良い）
  * **修正が入った場所、またはどの検出結果と重複しているか**: コミット、プルリクエスト、チケット、検出結果ID
  * **スキャナーがコードをどう読み違えたか**
</Check>

受け入れられる例:

```plaintext theme={null}
44行目のクエリはパラメータ化されており、ユーザーの値は連結ではなくバインドされています。
この入力は署名済みJWTのクレームで、このハンドラーに届く前に認証ミドルウェアで検証されています。
VPN内の社内専用エンドポイントです。来四半期の2.0アップグレードまで受け入れます。担当はプラットフォームチームです。
PR #1421で修正済みです。このスキャンの後にマージされました。
検出結果8c31と重複しています。シンクもコミットも同じです。
```

## 差し戻される例

決定そのものに何も加えていないコメントは差し戻されます。

| パターン              | 例                                                                  |
| ----------------- | ------------------------------------------------------------------ |
| 決定を言い換えただけ        | `false positive`、`accept risk`、`won't fix`、`fixed`、`duplicate`     |
| 理由のない結論だけ         | `not exploitable`、`this is safe`、`not a real issue`、`low priority` |
| 内容のない文字列やプレースホルダー | `n/a`、`test`、`asdf`、`...`、`per policy`、`as discussed`              |
| 承認者や手続きだけで理由がない   | `approved by security`、`reviewed`、`ticket created`                 |

コメントが差し戻されると、Corgeaは何が足りないかを示し、入力した内容はそのまま残るので追記できます。コメントが受け入れられるまでステータスは変更されません。

<Tip>
  同じ言い回しでも、実際の理由が続いていれば問題ありません。「誤検知。値はレンダリング前にテンプレートエンジンでエスケープされます」は受け入れられますが、「誤検知」だけでは受け入れられません。
</Tip>

## 差し戻しの理由にならないもの

この確認が見るのは理由が述べられているかどうかであり、文章の巧拙ではありません。

<Note>
  長さ、綴り、文法、くだけた表現、記述言語を理由に差し戻されることはありません。どの言語で書かれた理由も同じ基準で扱われます。また、その理由が技術的に正しいかどうかをCorgeaが判断することもありません。その判断はチームに委ねられており、判断がつかない場合はコメントを受け入れます。
</Note>

確認処理を利用できない場合、コメントは受け入れられ、ステータス変更はそのまま実行されます。確認処理の停止によってトリアージが止まることはありません。

## プルリクエストから検出結果を終了する

[Corgea Agent](/ja/agent)もプルリクエストのコメントに対応するときに同じ監査記録を書き込むため、同じ理由を求めます。

理由を述べずに検出結果の却下を求めるコメント（`@Corgea false positive`、`accept risk`、`not an issue`、`wontfix`）には、ステータスを変更する代わりに理由を尋ねる返信が返ります。コメントに理由を含めれば、エージェントがそれを記録します。

```plaintext theme={null}
@Corgea false positive, the query is parameterized on line 44
@Corgea accept risk until the 2.0 upgrade next quarter, this endpoint is internal-only
```

同じスレッドですでに述べた理由も有効です。これは実際の検出結果を終了する却下、つまり誤検知と受け入れ済みリスクに適用されます。プルリクエストから修正済みや重複としてマークする操作は変わりません。

## 承認者によるレビューを必須にする

理由は決定を説明しますが、それだけでは誰も内容を確認しません。会社の管理者は、却下が実際に適用される前に別の担当者の承認を必須にすることもできます。

**Settings → Company → Triage approvals**（[開く](https://www.corgea.app/settings/company/triage-approvals/)）で有効にします。このページには独立した2つのトグルがあり、どちらも既定ではオフです。

* **False positive**: 検出結果を誤検知として却下する操作が承認待ちになります。
* **Accepted risk**: 検出結果を受け入れ済みリスクとして抑制する操作が、有効期限の有無にかかわらず承認待ちになります。

対象の決定をオンにすると、検出結果の詳細ページ、ワークベンチのドロワー、一括トリアージバーのいずれから操作しても、ステータスは変更されずに申請が作成されます。検出結果は現在のステータスのまま**Pending approval**と表示され、誰かがレビューするまで変わりません。入力した理由は申請と一緒に渡され、レビュー担当者はそれを読みます。

### 申請をレビューする

レビューは[/approvals/](https://www.corgea.app/approvals/)の承認キューで行います。タブは**Pending**、**Approved**、**Rejected**、**Withdrawn**です。決定内容、プロジェクト、申請者で絞り込み、**Everyone**、**Waiting on me**、**Mine**に範囲を限定でき、CWE、CVE、パス、プロジェクト、理由、レビュー担当者のメモ、申請者を対象に検索できます。フィルターはクエリ文字列に保持されるため、絞り込んだ表示をリンクとして共有できます。

レビュー担当者は申請者本人以外で、同じ会社に所属し、トリアージ申請を承認する権限と、申請に含まれるすべての検出結果タイプを変更する権限が必要です。承認と却下にはメモを任意で添えられ、申請者は自分の申請を取り下げられます。

<Note>
  申請を承認できる担当者は、自分の操作については対象外です。自分の決定をキューに入れても自分自身を承認することになるため、その場で適用されます。会社の管理者はキュー内のすべての申請を確認でき、それ以外のユーザーは自分が提出した申請のみを確認できます。
</Note>

申請、承認または却下、レビュー担当者のメモ、取り下げといった各段階は、すべて検出結果の履歴に記録されます。