$codex-security:triage-finding を使うと、報告済みのセキュリティ上の指摘を現在のリポジトリに照らして確認できます。このワークフローでは、読み取り専用の静的解析を行います。Codex は各指摘を未検証の主張として扱い、コードを実行せずにリポジトリ内の根拠を調べます。
評価対象のリポジトリを作業範囲とする Codex プロジェクトから、このワークフローを実行してください。Codex には、そのリポジトリのソースコードを読み取る権限が必要です。Jira と Linear の指摘はコネクタから取得できます。GitHub の指摘を取得するには、認証済みの GitHub REST API アクセスが必要です。どちらの場合も、ソースコードへのアクセスは別途必要です。
一方、$codex-security:validation では、コードのビルドや実行、テストや概念実証の作成、実際のインターフェースの操作を通じて、指摘された問題を再現したり、指摘が成り立たないことを示したりできます。既存のバックログを分類して優先順位を付けるには、トリアージを使います。静的解析だけでは指摘の妥当性を判断できず、実行時の挙動を確認すれば判断できそうな場合は、検証を使います。
バックログのトリアージは、報告済みの指摘を対象とします。リポジトリで新たな脆弱性を探すには、セキュリティスキャンを実行してください。トリアージではリポジトリの変更や修正の実装は行いません。
トリアージ対象の選択
次のいずれかの情報源から、1 件または複数の指摘を指定できます。
| 情報源 | 指定する内容 | 必要なアクセス |
|---|---|---|
| 貼り付けた指摘またはローカルに保存した指摘 | SARIF 形式の結果、CVE または GHSA、アドバイザリ、スキャナーが作成したチケット、バグバウンティの報告書、Codex Security の指摘を記録した成果物、または脆弱性を文章で説明したもの。 | コネクタは不要です。 |
| Jira または Linear | セキュリティや脆弱性に関する課題の正確な URL または識別子、Jira の JQL クエリ、あるいは Linear のチーム、プロジェクト、検索語句を指定します。Codex はトリアージの前に、選択した課題の内容を取得します。 | Atlassian Rovo 経由の Jira または Linear の読み取り権限が必要です。 |
| GitHub | リポジトリを指定し、指摘の情報源として「コードスキャン」「Dependabot による脆弱性とマルウェアの検出」「セキュリティアドバイザリと非公開の脆弱性報告」から 1 つ、またはすべてを選びます。リポジトリを指定しない場合、現在の Codex プロジェクトに GitHub リポジトリが関連付けられていれば、Codex はそのリポジトリを使います。GitHub イシューはデフォルトでは対象外です。対象にするには、個別のイシューを指定するか、GitHub イシューを含めるよう明示してください。 |
gh auth token、GH_TOKEN、GITHUB_TOKEN などを使った認証済みの GitHub REST API アクセスが必要です。選択したリポジトリと、指定した種類の指摘の両方を読み取る権限が必要です。 |
Codex は、入力された指摘ごとに 1 件の結果を入力順に記録するため、各結果を元の指摘と照合できます。重複しているように見える指摘も、統合したり除外したりしません。
読み取り専用トリアージの実行
指摘を貼り付ける場合やローカルの成果物を使う場合は、次のようなプロンプトを送信します。
$codex-security:triage-finding を使って、以下に示す報告済みのセキュリティ上の指摘を、このリポジトリに照らしてトリアージしてください。
[Paste the findings or provide the artifact path.]Jira または Linear の課題を使う場合は、対象とする課題を指定し、取得元では読み取り専用で作業するよう指示します。
$codex-security:triage-finding を使って、[Jira or Linear issue URLs, identifiers, or query] で指定した課題からセキュリティ上の指摘を取り込み、このリポジトリに照らしてトリアージしてください。
元の課題は変更しないでください。GitHub の指摘を使う場合は、リポジトリと情報源を指定します。
$codex-security:triage-finding を使って、[code scanning, Dependabot vulnerabilities and malware, security advisories and private vulnerability reports, or all] の指摘を GitHub リポジトリ [owner/repository] から取り込み、このリポジトリに照らしてトリアージしてください。現在の Codex プロジェクトに関連付けられた GitHub リポジトリを使う場合は、指摘の情報源だけを指定します。
$codex-security:triage-finding を使って、[code scanning, Dependabot vulnerabilities and malware, security advisories and private vulnerability reports, or all] の指摘を GitHub から取り込み、このリポジトリに照らしてトリアージしてください。取得元には、現在の Codex プロジェクトに関連付けられた GitHub リポジトリを使ってください。Codex は現在のソースコードと、適用される SECURITY.md のポリシーを確認し、入力された指摘ごとに判定を返します。指摘を裏付ける根拠と反証となる根拠の両方を、未解決の疑問点とともに記録します。
結果の確認
| 判定 | 意味 |
|---|---|
confirmed |
指摘に記載された前提条件のもとで、脆弱性のあるコードパスに到達でき、そのパスが保護対象のセキュリティ境界を越えることを、リポジトリ内の根拠から確認できました。 |
not_actionable |
リポジトリ内の根拠から、指摘が成り立たないと判断できました。たとえば、使用中のバージョンが影響を受けない、該当のコードパスに到達できない、保護策が有効に機能する、該当の機能が製品に含まれていないといった場合です。 |
needs_review |
必要な情報が不足しているか曖昧である、または結論が実行時の挙動、環境、ポリシーに左右されるため、リポジトリ内の根拠だけでは判断できません。 |
優先順位を参考に、confirmed の指摘のうちどれを先に修正するか、needs_review の指摘のうちどれを先に調査するかを決めます。優先順位はグループごとに付けられます。
判定理由を読む際は、影響を受けるコードと、攻撃が成立するための前提条件も確認してください。優先順位に従って対応する前に、根拠を指摘内容と照合し、未解決の疑問点を確認します。ここでの confirmed は、リポジトリの静的解析で指摘の裏付けが得られたことを意味します。アプリケーションを実行して問題を再現したという意味ではありません。
Jira、Linear、その他のバックログの記録は、トリアージ結果を確認した後で Codex に更新を依頼した場合にのみ変更されます。
次のステップ
-
confirmed：担当者が指摘を修正対象と判断したら、$codex-security:fix-findingを使って問題を修正し、修正内容を検証します。トリアージでは、そのままプロンプトに使える引き継ぎ情報を用意しますが、スキルは自動で呼び出しません。 -
needs_review：コードを実行すれば不足している根拠が得られる場合は、$codex-security:validationを使い、実行時の挙動を調べて指摘を検証します。トリアージ結果から、指摘の内容、影響を受ける箇所、前提条件、静的解析で得られた根拠、まだ立証できていない点を渡してください。$codex-security:validation を使って、バックログのトリアージ結果にある指摘 [triage item ID or source ID] を動的に検証してください。指摘された問題を再現するか、指摘が成り立たないことを示してください。検証した内容を記録し、なお不確かな点があれば列挙してください。トリアージとは異なり、検証ではコードのビルドや実行、テストや概念実証の作成、実際のインターフェースの操作を行うことがあります。実行を制御する方法については、Codex の承認とセキュリティに関するポリシーを参照してください。
-
needs_review：指摘の妥当性が製品ポリシーやデプロイ環境に左右される場合は、コードを変更する前に、結果に記載された未解決の疑問点に回答してください。 -
not_actionable：判定の根拠をトリアージの記録とともに保存してください。Codex は元のチケットを自動でクローズしたり更新したりしません。 -
指定したバックログ以外の脆弱性を探すには、セキュリティスキャンを実行してください。