Skip to content

Fix #7176: [BUG] Security vulnerability: requesting a security contact#7309

Merged
brimoor merged 2 commits intovoxel51:developfrom
JiwaniZakir:fix/7176-bug-security-vulnerability-requesting-a
Apr 6, 2026
Merged

Fix #7176: [BUG] Security vulnerability: requesting a security contact#7309
brimoor merged 2 commits intovoxel51:developfrom
JiwaniZakir:fix/7176-bug-security-vulnerability-requesting-a

Conversation

@JiwaniZakir
Copy link
Copy Markdown
Contributor

@JiwaniZakir JiwaniZakir commented Apr 5, 2026

Closes #7176

🔗 Related Issues

Closes #7176

📋 What changes are proposed in this pull request?

Adds a SECURITY.md file to the repository root, providing a documented security vulnerability disclosure process. The file specifies:

  • [email protected] as the dedicated reporting channel, with a 48-hour response SLA
  • Required information for reports (issue type, affected components, reproduction steps, PoC, impact)
  • A four-step disclosure policy: confirm → audit → prepare fixes → release patches
  • Supported versions policy (latest stable release)

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?

  • No. You can skip the rest of this section.
  • Yes. Give a description of this change to be included in the release
    notes for FiftyOne users.

What areas of FiftyOne does this PR affect?

  • App: FiftyOne application changes
  • Build: Build and test infrastructure changes
  • Core: Core fiftyone Python library changes
  • Documentation: FiftyOne documentation changes
  • Other

This PR was created with AI assistance (Claude). The changes were reviewed by quality gates and a critic model before submission.

Summary by CodeRabbit

  • Documentation
    • Added a security policy documenting how to report vulnerabilities, expected 48-hour response timeline, required report contents, the disclosure and remediation workflow, guidance on supported-version fixes and prompt patch releases, and a request for reasonable delay before public disclosure.

@JiwaniZakir JiwaniZakir requested a review from a team as a code owner April 5, 2026 19:24
@voxel51-bot
Copy link
Copy Markdown
Collaborator

Thanks for opening this pull request, @JiwaniZakir! 🎉

A maintainer will review your changes soon. In the meantime, please ensure:

  • You filled out the PR template above, completely to the best of your knowledge
  • You include tests (if applicable)
  • You read the contribution guide

Helpful resources:

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented Apr 5, 2026

Caution

Review failed

Pull request was closed or merged during review

Walkthrough

A new SECURITY.md was added establishing the project's vulnerability reporting and disclosure process. It requires reporters to email [email protected] instead of using public GitHub issues, requests specific report contents (issue type, affected components, reproduction steps, PoC/exploit when available, and impact), sets an expected 48-hour response window with follow-up instructions, describes the team's confirmation/audit/fix/release workflow, requests a reasonable embargo on public disclosure, and states that security fixes target the latest stable release.

Sequence Diagram(s)

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title accurately describes the main change: adding a SECURITY.md file to address issue #7176 by establishing a security contact and vulnerability disclosure process.
Description check ✅ Passed The PR description is comprehensive, covering objectives, methodology, testing rationale, and release notes, matching the template structure with all required sections completed.
Linked Issues check ✅ Passed The PR successfully addresses #7176 by establishing a documented security vulnerability disclosure process with a dedicated email channel ([email protected]) and clear reporting requirements, fulfilling the core objective.
Out of Scope Changes check ✅ Passed The PR adds only SECURITY.md, a documentation file directly aligned with #7176's requirement for a documented security disclosure process with no extraneous changes.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

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

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

📥 Commits

Reviewing files that changed from the base of the PR and between 11c7024 and 22fe00f.

📒 Files selected for processing (1)
  • SECURITY.md

Comment thread SECURITY.md Outdated
Comment thread SECURITY.md
Comment on lines +18 to +26
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.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

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.

Comment thread SECURITY.md
Comment thread SECURITY.md
@JiwaniZakir
Copy link
Copy Markdown
Contributor Author

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 .

Copy link
Copy Markdown
Member

@brimoor brimoor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@brimoor
Copy link
Copy Markdown
Member

brimoor commented Apr 6, 2026

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.

@brimoor brimoor merged commit 5fda9f5 into voxel51:develop Apr 6, 2026
11 of 13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] Security vulnerability: requesting a security contact

3 participants