docs(security): document the private follow-up path for pending reports

[lidge-jun]

Summary

SECURITY.md explained how to file a report but stopped there. A reporter whose private
advisory had gone quiet had no stated follow-up route, no statement of what a public issue may
contain in that situation, and no way to tell an acknowledgment apart from completed triage —
which is the gap #4073 was opened to close.

Three additions, all wording only:

• Public or private. The test is whether the weakness is already public — the fix has
  shipped, or it is already described in a published advisory, issue, or pull request. Being
  findable in the source is explicitly called out as not disclosure, since opencodex is
  source-available and the opposite reading would route nearly every finding into the open. When
  unsure, file privately: a report can be moved to public review, not back.
• Following up on a report you already filed. Follow-up stays inside the private advisory
  thread. GitHub private vulnerability reporting is stated plainly as the only technical channel;
  there is no security email. If that thread itself is stalled, a public issue may carry
  coordination only — no reproduction, no exploit reasoning, no logs or attachments, no
  affected-version narrowing, and no advisory identifiers or links, since naming the report in
  public is itself a signal. A public maintainer reply confirms the route, not the content.
• Response expectations. Receipt is not triage: an acknowledgment, including a maintainer
  confirming they can reach the private queue, means the message arrived and nothing more. A
  landed public patch does not close the corresponding private report or settle disclosure for
  anything else. And there is no response deadline — stated explicitly so it is not read
  into the acknowledgment or into the triage-step list.

README.md carries the same three facts next to its existing security pointer.

No response-time target or SLA is introduced. Per @Ingwannu on #4073, a first-response target
needs @lidge-jun's agreement before it becomes a project commitment, so this PR states the
absence of one rather than proposing a number. No new reporting channel or email address is
invented either.

Closes #4073

Verification

• git diff origin/dev — two files, documentation only. No src/, gui/, scripts/, workflow,
  or test file is touched, and nothing in the build, typecheck, or test path reads SECURITY.md
  or README.md prose (rg 'SECURITY\.md' tests/ scripts/ .github/ finds only
  .github/ISSUE_TEMPLATE/config.yml and .github/CODEOWNERS, neither of which asserts on text).
• Independent audit of the diff and both full files by a separate agent, checking for an implied
  SLA, an invented channel, contradictions with the existing text, any wording that would push
  vulnerability detail into a public place, and Markdown/heading breakage. It returned FAIL on
  the first draft of the public-or-private test — "visible in published code" contradicted lines
  18, 26-27 and 85-86 of the same file — which is what cf967c3d0 rewrites; a re-audit of the
  corrected text passed.
• Local checks were NOT RUN — no bun run typecheck, no bun run test, no build, no lint,
  no bun install — per explicit maintainer instruction for this lane. Exact-head remote CI on
  this PR is the gate.

Checklist

• Scope stays focused and avoids unrelated cleanup.
• Docs or release notes were updated when needed.
• Security-sensitive changes were reviewed for secrets, auth, and unsafe defaults.

Nothing here changes behavior, and no secret, identifier, or unreleased finding appears in the
diff — the policy text is written so that following it keeps such material out of public view.

Summary by CodeRabbit

• Documentation
  • Clarified that private vulnerability reporting is handled through GitHub’s private reporting form, with no security email channel.
  • Added guidance on follow-ups, stalled reports, and the limited coordination role of public issues.
  • Explained the distinction between acknowledging and triaging a report.
  • Clarified that public patch reviews do not close private reports and that response timing is best-effort.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Advanced

Run ID: 4d4e01b6-5ce7-448d-84be-7ce239bbd010

📥 Commits

Reviewing files that changed from the base of the PR and between d1e6094 and cf967c3.

📒 Files selected for processing (1)

• SECURITY.md

Included review availability: Your plan provides up to 10 included reviews per hour; 6 remain after this review.

---

📝 Walkthrough

Walkthrough

The change updates security reporting documentation. It defines the private reporting channel, private follow-ups, public coordination limits, and response expectations.

Changes

Security reporting documentation

Layer / File(s)	Summary
Reporting channels and follow-ups README.md, SECURITY.md	The documentation identifies GitHub private vulnerability reporting as the technical channel, limits public issues to coordination, and defines how to follow up on existing reports.
Response expectations SECURITY.md	The policy distinguishes acknowledgment from triage, keeps private reports open during public patch review, and states that no response deadline exists.

Priority: ⬇️ Low

Estimated code review effort: 1 (Trivial) | ~5 minutes

Severity of issue fixed: Low

Merge Risk: ⚪ Minimal · up to cf967

This change clarifies secure vulnerability-reporting and follow-up guidance without changing runtime behavior. The documented reporting paths and expectations are aligned, with no current merge-readiness risk identified.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately and concisely describes the primary change: documenting the private follow-up path for pending security reports.
Linked Issues check	✅ Passed	README.md and SECURITY.md satisfy issue #4073 by documenting private advisory-thread follow-up, maintainer acknowledgment and reviewer coordination, and restrictions that keep technical details in pri…
Out of Scope Changes check	✅ Passed	The changes are limited to security-reporting documentation in README.md and SECURITY.md. The added guidance directly supports issue #4073 and introduces no unrelated code, release, or functional chan…
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0…

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch codex/security-private-followup-4073

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

✅ Deterministic PR hygiene checks passed.

[lidge-jun]

리뷰 · 우선순위 48 / 80

이 PR은 SECURITY.md와 README.md에만 글을 더합니다. 지금 dev의 SECURITY.md는 “비공개로 신고하라 / 폼이 안 되면 최소 공개 이슈로 안전한 길을 물어라 / best-effort로 본다”까지는 말해 주지만, 이미 넣어 둔 비공개 신고가 조용할 때 어디에 후속 연락을 해야 하는지, 공개 이슈에 무엇을 적어도 되는지, 접수(acknowledgment)와 트리아지(triage)가 다른지, 첫 응답 기한이 있는지까지는 비어 있습니다. 그게 바로 열린 이슈 #4073이 묻는 구멍입니다. 이 PR은 그 구멍을 세 덩어리로 메웁니다. (1) 공개 vs 비공개 판별 — 공개 코드/이미 나간 수정에 약점이 보이면 공개, 아니면 비공개, 헷갈리면 비공개. (2) 이미 넣은 신고의 후속 — 비공개 advisory 스레드 안에서만, 기술 채널은 GitHub 비공개 신고뿐이고 보안 메일 없음, 스레드가 막히면 공개 이슈는 조율만(재현·익스플로잇·로그·버전 좁히기·advisory 식별자/링크 금지). (3) 응답 기대 — 접수는 트리아지가 아님, 공개 패치 머지가 비공개 신고를 자동으로 닫지 않음, 첫 응답 기한/SLA 없음. README의 기존 보안 안내 옆에 같은 세 사실을 짧게 붙입니다.

현재 dev 방향(#4128 Spark 할당량 귀속, 2.50.0/사전 2.49.0 릴리스 위생)과는 직접 코드 겹침이 없고, 문서·정책 공백만 닫습니다. #4073 본문도 “coordination-only follow-up”을 이미 말하고 있어 이 PR 문장과 방향이 같습니다. 특히 @Ingwannu가 #4073에서 첫 응답 목표 숫자는 @lidge-jun 합의 전 프로젝트 약속이 되면 안 된다고 한 점을, 이 PR이 “기한이 없다”고 명시해 지키는 선택이 좋습니다. 새 채널·새 메일·새 SLA를 만들지 않았고, src/·테스트·워크플로도 안 건드리니 런타임 위험은 없습니다.

SECURITY.md Following Up 절 - “naming it in public is itself a signal”과 advisory 식별자/링크 금지는 맞지만, 리포터가 실수로 티켓 번호나 advisory URL을 넣는 흔한 실수를 한 줄 더(예: “이슈 번호·advisory URL도 넣지 말 것”) 막아 주면 #4073 같은 조율 이슈를 쓸 때 실수가 더 줄어듭니다. 지금은 의미상 포함되어 있으나 예시가 약합니다.

SECURITY.md Public or private 절 - “fix has shipped, or the defect is plainly visible in published code”는 좋은 기준인데, “공개 PR로 수정 중인 아직 머지 전 약점”처럼 애매한 중간 상태 한 줄이 없으면 리포터가 또 헷갈릴 수 있습니다. 필수는 아니고, 헷갈리면 비공개라는 문장이 이미 안전망입니다.

README.md 추가 3줄 - SECURITY.md와 내용이 맞습니다. 다만 README만 읽는 사람에게는 “coordination only”의 구체 금지 목록이 안 보이므로, 상세는 SECURITY.md를 보라는 짧은 안내를 붙이면 더 안전합니다.

메인테이너의 판단이 필요한 지점

• #4073을 이 PR 머지와 함께 닫을지(본문이 Closes Request a safe private follow-up path for pending security reports #4073), 아니면 실제 비공개 큐에 밀린 신고를 한 번 더 훑은 뒤에 닫을지
• 첫 응답 기한 부재를 이대로 고정할지, 나중에 별도 이슈로 SLA 숫자를 논의할지(이 PR 범위 밖이 맞음)
• README에 SECURITY.md 링크를 한 번 더 강조할지

너의 추천
CI 초록이면 머지하고 #4073을 닫으세요. 보안 프로세스 문서 구멍을 정확히 메우면서 SLA·새 채널을 발명하지 않은 점이 현재 메인테이너 합의와 맞습니다. README에 “자세한 금지 목록은 SECURITY.md” 한 줄만 더 넣으면 더 좋고, 없어도 머지를 막을 정도는 아닙니다.

이 댓글은 grok-bot이 작성했습니다