Fix #7176: [BUG] Security vulnerability: requesting a security contact#7309
Conversation
|
Thanks for opening this pull request, @JiwaniZakir! 🎉 A maintainer will review your changes soon. In the meantime, please ensure:
Helpful resources: |
|
Caution Review failedPull request was closed or merged during review WalkthroughA new Sequence Diagram(s)Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@SECURITY.md`:
- Around line 37-38: The SECURITY.md disclosure policy uses the vague phrase
"reasonable amount of time"; replace that wording with an explicit coordinated
disclosure timeline (e.g., "90 days from initial report") and add a short
sentence describing exceptions and how to request an extension (e.g.,
"exceptions for actively exploited vulnerabilities may be discussed with the
reporter; contact [security contact]"). Update the sentence containing
"reasonable amount of time" to read the explicit timeline and ensure the
security contact/process remains referenced so reporters know how to proceed.
- Around line 18-26: Add an encrypted communication option for high-severity
reports by updating SECURITY.md to include a PGP public key and brief
instructions for reporters to encrypt sensitive details; specifically, add a new
section (suggested insertion after the existing contact/line 13) that lists the
PGP public key fingerprint and ASCII-armored public key, shows the exact fields
reporters should still include (type of issue, affected components, reproduction
steps, PoC, impact), and instructs how to encrypt their message (e.g., “encrypt
with this PGP key and send to [security@domain]”), plus guidance on alternative
secure channels and a note about accepted file formats for encrypted
attachments.
- Around line 40-43: The "## Supported Versions" policy currently states only
the latest stable release is supported; update that section to define a clear
multi-version support policy (for example "current + previous major version" or
an explicit X-month support window) and describe backport/patch handling for
critical security fixes (e.g., criteria for backports, how to request a
backport, and when an LTS branch is provided); ensure the revised text replaces
the existing paragraph under "## Supported Versions" and includes the chosen
support window, backport process, and any exceptions for emergency fixes.
- Around line 1-47: Update the "Supported Versions" section in SECURITY.md to
list explicit supported and unsupported release ranges (e.g., "Supported: 2.x,
1.5.x; Unsupported: <1.0") instead of "latest stable version", add an optional
"Encrypted communication" subsection that provides a PGP/GPG public key or
instructions for submitting encrypted reports, and mention GitHub's private
vulnerability reporting as an alternative channel if the repo has it enabled;
ensure these additions are placed near the existing "Supported Versions" and
"Reporting a Vulnerability" sections so reporters can easily find version
coverage and secure submission options.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 8fe1712f-5362-415d-972d-02bace563436
📒 Files selected for processing (1)
SECURITY.md
| Please include the following information in your report: | ||
|
|
||
| - Type of issue (e.g., remote code execution, authentication bypass, etc.) | ||
| - The component(s) affected (e.g., server, database, API) | ||
| - Step-by-step instructions to reproduce the issue | ||
| - Proof-of-concept or exploit code (if possible) | ||
| - Impact of the issue, including how an attacker might exploit it | ||
|
|
||
| This information will help us triage your report more quickly. |
There was a problem hiding this comment.
Add encrypted communication option for sensitive vulnerabilities.
For high-severity issues (like the unauthenticated network-accessible vulnerability mentioned in #7176), reporters need a way to send encrypted details. Industry best practice is to provide a PGP public key.
📧 Suggested addition after line 13
**[email protected]**
+
+For sensitive reports, you may encrypt your message using our PGP key:
+[Link to PGP key or key fingerprint]🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@SECURITY.md` around lines 18 - 26, Add an encrypted communication option for
high-severity reports by updating SECURITY.md to include a PGP public key and
brief instructions for reporters to encrypt sensitive details; specifically, add
a new section (suggested insertion after the existing contact/line 13) that
lists the PGP public key fingerprint and ASCII-armored public key, shows the
exact fields reporters should still include (type of issue, affected components,
reproduction steps, PoC, impact), and instructs how to encrypt their message
(e.g., “encrypt with this PGP key and send to [security@domain]”), plus guidance
on alternative secure channels and a note about accepted file formats for
encrypted attachments.
|
The coderabbitai feedback is valid on all three points — the file to specify a 90-day coordinated disclosure timeline, add a PGP key or keybase link for encrypted submissions, and expand the supported versions policy to cover at least the prior minor release to account for enterprise users who can't upgrade immediately. Will push an update . |
|
The coderabbitai feedback is valid on all three points — the file to specify a 90-day coordinated disclosure timeline, add a PGP key or keybase link for encrypted submissions, and expand the supported versions policy to cover at least the prior minor release to account for enterprise users who can't upgrade immediately. Will push an update . Coderabbit's comments are reasonable but I think the policy as currently written is acceptable for now. |
Closes #7176
🔗 Related Issues
Closes #7176
📋 What changes are proposed in this pull request?
Adds a
SECURITY.mdfile to the repository root, providing a documented security vulnerability disclosure process. The file specifies:This directly addresses the absence of a security contact raised in #7176, giving reporters a private channel instead of having to open public GitHub issues with sensitive vulnerability details.
🧪 How is this patch tested? If it is not, please explain why.
Not applicable — this is a documentation-only change adding a single Markdown file (
SECURITY.md). No code logic is introduced or modified. Manual verification: confirmed the file renders correctly on GitHub and that the email address and policy steps are accurate.📝 Release Notes
Is this a user-facing change that should be mentioned in the release notes?
notes for FiftyOne users.
What areas of FiftyOne does this PR affect?
fiftyonePython library changesThis PR was created with AI assistance (Claude). The changes were reviewed by quality gates and a critic model before submission.
Summary by CodeRabbit