Example pattern:

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

Apply PATCH calls in the correct sequence

• Do not set severity and cvss_vector_string in the same PATCH call.
• Use separate calls when the advisory requires both fields.
• Publish by PATCHing the advisory and setting "state":"published". There is no separate /publish endpoint.

Example shape:

gh api -X PATCH /repos/openclaw/openclaw/security-advisories/<GHSA> \
  --input /tmp/ghsa.patch.json

Publish and verify success

After publish, re-fetch the advisory and confirm:

• state=published
• published_at is set
• the description does not contain literal escaped \\n

Verification pattern:

gh api /repos/openclaw/openclaw/security-advisories/<GHSA>
jq -r .description < /tmp/ghsa.refetch.json | rg '\\\\n'

Common GHSA footguns

• Publishing fails with HTTP 422 if required fields are missing or the private fork still has open PRs.
• A payload that looks correct in shell can still be wrong if Markdown was assembled with escaped newline strings.
• Advisory PATCH sequencing matters; separate field updates when GHSA API constraints require it.
• Public hardening/no-publish comments and draft text should avoid raw commit hashes, PR titles/numbers, and fix-mechanism summaries. Prefer patched-version fields or release-only wording; keep SHAs, PRs, and implementation notes in internal evidence.

tag-duplicate-prs-issues

帮助团队检索重复的 PR 与问题单，并自动分组同步重复状态。