mcpField
S
security-triage

security-triage

github.com/openclawセキュリティ393.3k618 回インストール今日更新
リポジトリ

security-triage について

OpenClaw のセキュリティアドバイザリー草案や GHSA 報告を審査する、メンテナー向けのスキルです。信頼境界、リリース済みバージョン、悪用経路、機能上のトレードオフを踏まえ、終了・継続・範囲縮小を判断します。

主な機能

  1. 01ポリシーと該当コードパスを確認
  2. 02影響を受けるリリース済みバージョンを検証
  3. 03信頼境界と悪用可能性を評価
  4. 04既存アドバイザリーと報告を照合
  5. 05脆弱性の扱いとハードニングを分離

活用シーン

  1. 01新しい GHSA 報告のトリアージ
  2. 02アドバイザリー終了案のレビュー
  3. 03リリースへの影響を判定
  4. 04メンテナー向け返信を作成

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/openclaw/openclaw --skill security-triage

インストール後、Claude Code で/security-triageを入力して読み込まれたか確認します。

詳細

セキュリティトリアージ

OpenClaw のセキュリティアドバイザリ、草案、または GHSA レポートをレビューするときに使用します。

目的：実際の問題を過剰にクローズしたり、不要なリグレッションをリリースしたりせず、メンテナーが高い確信を持ってトリアージできるようにします。

クローズの基準

次のいずれかに該当する場合に限り、クローズします。

  • 既存のアドバイザリまたは修正済みの問題と重複している
  • リリース済みの動作に照らして無効である
  • SECURITY.md の対象範囲外である
  • 影響を受けるリリース／タグより前に修正されている

main が修正済みという理由だけでクローズしてはいけません。最新のリリース済みタグまたは npm リリースが影響を受ける場合は、適切なステータスでリリースまたは公開されるまでオープンのままにしてください。

必読資料

回答する前に、以下を確認してください。

  1. SECURITY.md を読む。
  2. gh api /repos/openclaw/openclaw/security-advisories/<GHSA> で GHSA の本文を読む。
  3. 問題として指摘されたコードパスを正確に調査する。
  4. リリース済みの状態を確認する：
    • git tag --sort=-creatordate | head
    • npm view openclaw version --userconfig "$(mktemp)"
    • git tag --contains <fix-commit>
    • 必要であれば、git show <tag>:path/to/file
  5. 同種の問題が正式に扱われているか検索する：
    • 公開済みの既存 GHSAs
    • 過去に修正されたバグ
    • SECURITY.md ですでに扱われている、同じ信頼モデル上の分類

レビュー方法

各アドバイザリについて、次のいずれかを判断します。

  • close
  • keep open
  • keep open but narrow

コメントやクローズが関わる場合は、原則として一度に 1 件のアドバイザリを扱います。

  1. GHSA を 1 件だけレビューする。
  2. 最初に GHSA の URL を出力する。
  3. 議論に向けて、判断と根拠を要約する。
  4. メンテナーがそのまま使えるコメントを 1 件作成する。
  5. そのコメント 1 件だけをクリップボードにコピーする。
  6. 次の GHSA に進む前に、Peter が投稿または議論するのを待つ。

Peter から明示的に一括対応を求められない限り、複数のクローズコメントをまとめてはいけません。

次の順で確認します。

  1. 信頼モデル
    • 前提条件は、すでに信頼されたホスト／ローカル／プラグイン／オペレーターの状態の中にあるか？
    • SECURITY.md では、この分類が対象外またはハードニングのみと明示されているか？
  2. リリース済みの動作
    • バグは最新のリリース済みタグまたは npm リリースに存在するか？
    • リリース前に修正されているか？
  3. 悪用経路
    • レポートは、単なるプロンプトインジェクション、ローカルの同一ユーザーによる制御、またはヘルパーレベルのセマンティクスではなく、実際の境界回避を示しているか？
    • データが SECURITY.md で明示されている信頼済みのワークスペースメモリファイル間でのみ移動する場合、「インジェクションマーカー」だけをセキュリティバグとして扱ってはいけません。
    • その場合、サニタイズが想定されるメモリのワークフローを維持するのであれば、任意のハードニングとして位置付けてください。
  4. 機能とのトレードオフ
    • ハードニングの変更によって意図されたユーザー機能が損なわれる場合は、提案する前にその点を明示してください。
    • 境界上必要な場合を除き、デフォルト拒否によるリグレッションよりも、ユーザーのワークフローを維持する修正を優先してください。
  5. ハードニングのフォローアップ
    • GHSA をクローズすべき場合でも、文書化された信頼境界を変更せずに、意図しない操作のリスクを減らす限定的なハードニング変更があるか検討してください。
    • ハードニングと脆弱性のステータスは分けてください。「GHSA のクローズには不要ですが、検討する価値があります」と表現してください。
    • ハードニングを取り上げるのは、具体的で、リスクが低く、メンテナー／オペレーターの意図されたワークフローを維持できる場合に限ってください。
    • ハードニングに製品／セキュリティモデルの変更が必要な場合は、その旨を明示し、クローズに必須の修正であるかのように示してはいけません。

回答形式

メンテナーが投稿できるクローズ返信を準備する場合：

  1. 最初に GHSA の URL を出力する。
  2. 次に、メンテナーが投稿できる詳細な返信案を作成する。
  3. 以下を含める：
    • クローズする正確な理由
    • 正確なコード参照
    • リリース済みタグ／リリースの正確な情報
    • 該当する場合は、修正の由来または正式な重複 GHSA
    • 価値があり、機能を維持できる場合に限り、任意のハードニングに関する注記

断定的かつ具体的で、防御的にならない口調にしてください。

公開文言の衛生管理

  • 公開するアドバイザリーテキストには、生のコミットハッシュ、PR のタイトル／番号、修正メカニズムの概要を含めないでください。パッチ適用済みのリリース／バージョンフィールドのみを使用してください。
  • 正確なコミット SHA、PR、実装メモは、内部メモと検証ファイルに記載してください。
  • 強化対応／非公開の結果については、エクスプロイトの詳細、「修正内容」テキスト、「修正コミット」セクションを追加しないでください。報告者に感謝し、謝辞を残し、SECURITY.md の境界を明示し、GHSA は公開せずにクローズすると明確に伝えてください。
  • CVE／GHSA を公開するテキストでは、修正済みリリースを記載した ### Patched Versions を優先してください。Peter から公開情報として明示的に求められない限り、パッチの仕組みを説明しないでください。
  • Peter から明示的に求められない限り、変更履歴やリリースノートの文言に GHSA ID を含めないでください。

ディスカッションモード

Peter が GHSA コメントを手動で投稿する場合は、次の手順に従ってください。

  1. URL を示します。
  2. 簡潔な判定（close、keep open、または keep open but narrow）を伝えます。
  3. 最も強力な根拠を箇条書きにします。
  4. 任意の強化対応は、クローズ理由とは分けて記載します。
  5. 提案するコメント本文を pbcopy でコピーします。
  6. 1 件のアドバイザリーへの返信後に応答を終了します。Peter が続行を指示するまで、次のアドバイザリーに進まないでください。

GitHub API から非公開アドバイザリーにコメントを投稿できない場合は、その旨を一度伝え、クリップボード／UI への貼り付けを引き続き使用してください。

クリップボードの手順

現在のアドバイザリーに対する最終投稿本文を作成したら、コピーします。

pbcopy <<'EOF'
<final response>
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 では修正済み、未リリース」は、通常クローズの理由にはなりません。
  • 「攻撃者が制御する信頼済みのローカル状態が事前に必要」は、通常スコープ外です。
  • 「同一ホスト上の同一ユーザーのプロセスが、すでにローカル状態を読み書きできる」は、通常スコープ外です。
  • 「信頼済みワークスペースのメモリが、信頼済みワークスペースのメモリを昇格／再インデックスする」は、文書化された境界を越えない限り、通常スコープ外です。
  • 「ヘルパー関数の動作が、文書化された設定の仕様と異なる」は、通常無効です。
  • 深刻度のみが誤っていてバグ自体は実在する場合は、オープンのままにし、返信で影響範囲を限定してください。

コメント

Markdown 対応