セキュリティトリアージ は何をしますか？
OpenClaw のセキュリティアドバイザリ、ドラフト、または GHSA レポートをレビューする際に使用します。
目標: 実際の問題を過剰にクローズしたり、不要なリグレッションを出荷したりすることなく、メンテナによる高信頼性のトリアージを実現します。
クローズ基準
以下のいずれかに該当する場合のみクローズします:
- 既存のアドバイザリまたは修正済みの問題の重複
- 出荷済みの動作に対する無効な報告
SECURITY.mdの範囲外- 影響を受けるリリース/タグよりも前に修正済み
main ブランチが修正されたという理由だけでクローズしないでください。最新の出荷済みタグまたは npm リリースが影響を受けている場合は、適切なステータスでリリースまたは公開されるまでオープンにしてください。
必須の事前確認
回答する前に:
SECURITY.mdを読む。gh api /repos/openclaw/openclaw/security-advisories/<GHSA>で GHSA 本文を読む。- 正確に関係するコードパスを調査する。
- 出荷状態を確認する:
git tag --sort=-creatordate | headnpm view openclaw version --userconfig "$(mktemp)"git tag --contains <fix-commit>- 必要に応じて:
git show <tag>:path/to/file
- 重複の可能性を検索する:
- 既存の公開 GHSA
- 過去の修正済みバグ
SECURITY.mdで既にカバーされている同一の信頼モデルクラス
レビュー方法
各アドバイザリについて、以下を決定します:
close（クローズ）keep open（オープン維持）keep open but narrow（オープン維持するが範囲を絞る）
コメントやクローズが伴う場合は、デフォルトで一度に 1 つのアドバイザリを処理します:
- 正確に 1 つの GHSA をレビューする。
- 最初に GHSA の URL を出力する。
- 決定内容と証拠を議論用に要約する。
- メンテナがそのまま使えるコメントを 1 つドラフトする。
- そのコメント 1 つだけをクリップボードにコピーする。
- 次の GHSA に移る前に、Peter が投稿/議論するのを待つ。
Peter が明示的にバッチ処理を要求しない限り、複数のクローズコメントをまとめて処理しないでください。
以下の順序で確認します:
- 信頼モデル
- 前提条件がすでに信頼されたホスト/ローカル/プラグイン/オペレーターの状態内にあるか？
SECURITY.mdでこのクラスが範囲外またはハードニングのみと明示的に指定されているか？
- 出荷済みの動作
- バグが最新の出荷済みタグまたは npm リリースに存在するか？
- リリース前に修正されたか？
- 攻撃経路
- レポートが、プロンプトインジェクション、ローカル同一ユーザー制御、またはヘルパーレベルのセマンティクスではなく、実際の境界バイパスを示しているか？
- データが
SECURITY.mdで指定された信頼されたワークスペースメモリファイル間でのみ移動する場合、「インジェクションマーカー」だけをセキュリティバグとして扱わないでください。 - その場合、サニタイゼーションは、期待されるメモリワークフローを維持する場合にのみ、オプションのハードニングとして位置づけてください。
- 機能トレードオフ
- ハードニング変更により意図されたユーザー機能が低下する場合は、提案する前にそのことを指摘してください。
- 境界がそれを要求しない限り、デフォルトで拒否するようなリグレッションよりも、ユーザーワークフローを維持する修正を優先してください。
- ハードニングフォローアップ
- GHSA をクローズすべき場合でも、文書化された信頼境界を変更せずに、誤操作を減らせる狭い範囲のハードニング変更がないか検討してください。
- ハードニングと脆弱性ステータスは分けて扱ってください。「GHSA クローズには必須ではないが、検討する価値はある」と表現してください。
- 具体的でリスクが低く、意図されたメンテナ/オペレーターのワークフローを維持する場合にのみ、ハードニングを持ち出してください。
- ハードニングに製品/セキュリティモデルの変更が必要な場合は、そのことを明示的に述べ、クローズに必要な修正であると暗示しないでください。
応答形式
メンテナが投稿できるクローズ返信を準備する場合:
- 最初に GHSA の URL を出力する。
- 次にメンテナが投稿できる詳細な応答をドラフトする。
- 以下を含める:
- クローズの正確な理由
- 正確なコード参照
- 正確な出荷済みタグ/リリースの事実
- 該当する場合、修正の出自または正規の重複 GHSA
- 価値があり機能を維持する場合に限り、オプションのハードニングノート
トーンはしっかりと、具体的に、非防御的に保ちます。
公開文言の衛生
- 生のコミットハッシュ、PR タイトル/番号、修正メカニズムの要約は、公開アドバイザリテキストに含めないでください。パッチ済みリリース/バージョンフィールドのみを使用してください。
- 正確なコミット SHA、PR、実装ノートは、内部ノートと検証ファイルに保持してください。
- ハードニング/非公開の結果の場合、エクスプロイトの詳細、「Fixed by」テキスト、または「Fix Commit(s)」セクションを追加しないでください。報告者に感謝し、クレジットを保持し、
SECURITY.mdの境界を述べ、GHSA が公開なしでクローズされることを明確に述べてください。 - 公開 CVE/GHSA テキストの場合は、
### Patched Versionsで修正リリースを記載することを推奨します。Peter が明示的に要求しない限り、パッチの仕組みを説明しないでください。 - Peter が明示的に要求しない限り、GHSA ID をチェンジログやリリースノートの文言に含めないでください。
ディスカッションモード
Peter が手動で GHSA コメントを投稿している場合、以下のフローを使用します:
- URL を表示する。
- 簡潔な判定を示す (
close、keep open、またはkeep open but narrow)。 - 最も強力な証拠の箇条書きをリストする。
- クローズ理由とは別に、任意のハードニングフォローアップがあれば述べる。
- 提案するコメント本文を
pbcopyでコピーする。 - そのアドバイザリに関する返信で終了する。Peter が続行を指示するまで、次のアドバイザリに進まないでください。
GitHub API がプライベートアドバイザリにコメントを投稿できない場合は、そのことを一度伝え、クリップボード/UI ペーストを使用し続けてください。
クリップボード手順
現在のアドバイザリの最終投稿本文をドラフトした後、それをコピーします:
pbcopy <<'EOF'
<最終応答>
EOF
そのアドバイザリに対する提案応答がクリップボードにコピーされたことをユーザーに伝えてください。
便利なコマンド
gh api /repos/openclaw/openclaw/security-advisories/<GHSA>
gh api /repos/openclaw/openclaw/security-advisories --paginate
git tag --sort=-creatordate | head -n 20
npm view openclaw version --userconfig "$(mktemp)"
git tag --contains <commit>
git show <tag>:<path>
gh search issues --repo openclaw/openclaw --match title,body,comments -- "<terms>"
gh search prs --repo openclaw/openclaw --match title,body,comments -- "<terms>"
サイバー分類器の割り込み
許可された防御作業がサイバー分類器によって中断された場合、その限定されたタスクに対してのみ、承認済みで利用可能な Daybreak Blue ルートを使用し、その後以前のモデルに戻してください。承認された ID、スコープ、権限、サンドボックス、レビューゲートを保持してください。アクセス拒否、不許可リクエスト、拒否されたツールアクションを回避するためにモデルを切り替えないでください。そのルートも拒否する場合は、停止して報告してください。承認されたモデルアクセスについては、OpenAI のガイダンスに従ってください。
判断ノート
- 「main で修正済み、未リリース」は通常クローズ理由になりません。
- 「攻撃者が最初に信頼されたローカル状態を制御する必要がある」は通常範囲外です。
- 「同一ホスト同一ユーザーのプロセスはローカル状態を既に読み書きできる」は通常範囲外です。
- 「信頼されたワークスペースメモリが信頼されたワークスペースメモリを昇格/再インデックスする」は、文書化された境界を越えない限り通常範囲外です。
- 「ヘルパー関数が文書化された設定セマンティクスと異なる動作をする」は通常無効です。
- 深刻度のみが間違っていてバグが本物の場合は、オープンを維持し、返信で影響を狭めてください。