OpenClaw GHSA Maintainer
このスキルは、リポジトリのセキュリティアドバイザリワークフロー専用です。一般的なリリース作業は release-openclaw-maintainer に委ねてください。
アドバイザリのガードレールを尊重する
- リポジトリのアドバイザリをレビューまたは公開する前に、
SECURITY.mdを読んでください。 - 公開アクションの前に必ず許可を求めてください。
- このスキルはGHSA専用として扱ってください。安定版やベータ版のリリース作業には使用しないでください。
アドバイザリの状態を取得して確認する
現在のアドバイザリと最新の公開npmバージョンを取得します：
gh api /repos/openclaw/openclaw/security-advisories/<GHSA>
npm view openclaw version --userconfig "$(mktemp)"
パッチを適用する前に、取得した出力を使ってアドバイザリの状態、リンクされたプライベートフォーク、脆弱性ペイロードの形状を確認してください。
プライベートフォークのPRがクローズされていることを確認する
公開前に、アドバイザリのプライベートフォークにオープンなPRがないことを確認します：
fork=$(gh api /repos/openclaw/openclaw/security-advisories/<GHSA> | jq -r .private_fork.full_name)
gh pr list -R "$fork" --state open
公開前にPRリストが空でなければなりません。
アドバイザリのMarkdownとJSONを安全に準備する
- アドバイザリのMarkdownはheredocを使って一時ファイルに書き込みます。エスケープされた
\n文字列は使用しないでください。 - PATCHペイロードのJSONは
jqを使って構築し、手動エスケープされたシェルJSONは使用しないでください。
例のパターン：
cat > /tmp/ghsa.desc.md <<'EOF'
<markdown description>
EOF
jq -n --rawfile desc /tmp/ghsa.desc.md \
'{summary,severity,description:$desc,vulnerabilities:[...]}' \
> /tmp/ghsa.patch.json
PATCH呼び出しを正しい順序で適用する
- 同じPATCH呼び出しで
severityとcvss_vector_stringを設定しないでください。 - アドバイザリが両方のフィールドを必要とする場合は、別々の呼び出しを使用してください。
- アドバイザリをPATCHして
"state":"published"を設定することで公開します。個別の/publishエンドポイントはありません。
例の形状：
gh api -X PATCH /repos/openclaw/openclaw/security-advisories/<GHSA> \
--input /tmp/ghsa.patch.json
公開して成功を確認する
公開後、アドバイザリを再取得して以下を確認します：
state=publishedpublished_atが設定されている- 説明にリテラルのエスケープされた
\\nが含まれていない
確認パターン：
gh api /repos/openclaw/openclaw/security-advisories/<GHSA>
jq -r .description < /tmp/ghsa.refetch.json | rg '\\\\n'
よくあるGHSAの落とし穴
- 必須フィールドが不足しているか、プライベートフォークにまだオープンなPRがある場合、公開はHTTP 422で失敗します。
- シェルでは正しく見えるペイロードでも、Markdownがエスケープされた改行文字で組み立てられていると間違っている可能性があります。
- アドバイザリのPATCHシーケンスは重要です。GHSA APIの制約で必要な場合はフィールド更新を分離してください。
- 公開前のハードニング/非公開コメントやドラフトテキストでは、生のコミットハッシュ、PRタイトル/番号、修正メカニズムの要約を避けるべきです。パッチが適用されたバージョンフィールドやリリース専用の表現を優先し、SHA、PR、実装ノートは内部証拠として保持してください。