docs(security): align org-default policy with the real disclosure process - #6
Conversation
…cess This file is the Security-tab default for org repos that do not ship their own SECURITY.md (homebrew-tap, scoop-bucket, linux-repo, awesome-nimbus, nimbus-benchmarks, plus private repos). It already led with private vulnerability reporting, and its pointer to nimbus-security still resolves after that repo's rewrite. Two fixes: - "We aim to acknowledge reports within a few business days" contradicted the rewritten policy, which states plainly that a solo maintainer cannot guarantee a response time. Replaced with the same honest expectation so a reporter sees one answer wherever they land. - The alternative "or follow the disclosure instructions in nimbus-security" read as a second, separate channel. nimbus-security now routes back to PVR, so it is described as the full policy text rather than another way to report. Also adds a direct advisories/new link for reporters who cannot tell which repository is affected, and states there is no bug bounty. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 33 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
1 participant
Third of three PRs fixing the public security-disclosure surface. Companions: nimbus-agent/nimbus-security#1 (the central policy, which had literal
PLACEHOLDERtext and a fakesecurity@nimbus.dev) and nimbus-agent/Nimbus#909.Did this file's instructions still resolve after the rewrite?
Yes — this one was in the best shape of the three. It already led with private vulnerability reporting, and its pointer to
nimbus-securitystill resolves. So this is a consistency pass, not a rescue.Two things did need fixing:
1. A contradicting response promise. This file said "We aim to acknowledge reports within a few business days." The rewritten policy states plainly that a solo maintainer cannot guarantee a response time. A reporter comparing the two got different answers depending on which repo they landed on. Now aligned.
2.
nimbus-securitywas described as an alternative channel. The old text read "use PVR ... or follow the disclosure instructions in nimbus-security", implying a second way to report. After the rewrite, nimbus-security routes back to PVR — it is the policy text, not a separate channel. Reworded so there is exactly one channel.Also adds a direct
advisories/newlink for reporters who cannot tell which repo is affected, and states there is no bug bounty.Scope of this file (worth recording)
This is the org default, which GitHub only applies to repos that do not ship their own
SECURITY.md. I checked all 12 public repos:homebrew-tap,scoop-bucket,linux-repo,awesome-nimbus,nimbus-benchmarksNimbus(.github/),nimbus-security,nimbus-vscode,nimbus-web-clipper,nimbus-client,nimbus-sdk(docs/),.githubitselfSo the reach is 5 public repos plus private ones — not all of them.
Nimbusin particular overrides it, which is why its own stale policy (a nonexistent email contact, a 72-hour SLA, and a Supported Versions table namingv0.13.xwhen current isv1.5.0) needed the separate fix in nimbus-agent/Nimbus#909.I audited the four satellite policies too (
nimbus-vscode,nimbus-web-clipper,nimbus-client,nimbus-sdk): all are PVR-first with no placeholder text, fake email, or PGP key. Their only blemish is the same "within a few business days" wording. I left them alone rather than opening four more PRs for a one-line nit — flagging it instead so you can decide whether consistency is worth the churn.🤖 Generated with Claude Code