24.4 Working with Security Researchers¶

Security researchers find vulnerabilities that you and your users would rather discover through a responsible report than through an attack. The best researchers improve your project's security significantly—often for free—and some become long-term contributors. But the relationship isn't always smooth. Researchers have their own incentives (reputation, bounties, publication), timelines (conference deadlines, disclosure policies), and communication styles that don't always align with maintainer constraints.

Building productive relationships with security researchers benefits everyone: researchers get acknowledgment and sometimes compensation, maintainers get security improvements, and users get safer software. This section provides guidance for maintainers on cultivating these relationships while navigating the occasional difficult situation.

Building Relationships with the Security Community¶

Security researchers choose which projects to examine. Projects with reputations for good researcher relationships attract more attention from skilled, ethical researchers. Projects known for hostile responses, ignored reports, or legal threats drive researchers away—or toward full disclosure without coordination.

Community relationship building:

Make reporting easy and rewarding:

• Clear SECURITY.md with responsive channels (see Section 24.1)
• Prompt acknowledgment of reports (within 48 hours)
• Regular updates on progress
• Public credit in advisories
• Hall of fame page on project website

Engage with security communities:

• Participate in security-focused events and discussions
• Respond constructively to security questions about your project
• Thank researchers publicly for their contributions
• Share your security practices openly

Be known for good behavior:

• Never threaten legal action against good-faith researchers
• Never dismiss reports without investigation
• Never ignore researchers after receiving reports
• Follow through on promised timelines

Example hall of fame page:

# Security Hall of Fame

We thank the following security researchers for helping keep 
our users safe through responsible disclosure:

# 2024
- **@researcher1** - Authentication bypass (CVE-2024-XXXX)
- **Jane Smith** (Company) - XSS in admin panel (CVE-2024-XXXX)
- **Security Team, Example Corp** - Rate limiting bypass

## 2023
- **@researcher2** - SQL injection in search (CVE-2023-XXXX)
...

Want to be listed here? See our [security policy](SECURITY.md).

Many security researchers report that they return to projects where maintainers treat them as partners rather than annoyances. Good researcher relationships often lead to more thorough security reviews and ongoing engagement with your project.

Bug Bounty Programs for Open Source¶

Bug bounty programs provide financial incentives for security researchers to find and report vulnerabilities. While traditional bounties require significant budgets, several platforms now support open source projects with funded or subsidized programs.

Bug bounty platform overview:

GitHub Security Lab:

GitHub Security Lab supports open source security through: - CodeQL queries for finding vulnerability patterns - Secure Open Source Fund providing $10,000 grants to maintainers - Security research collaboration and tooling - Resources for improving project security

Huntr platform (AI/ML focus):

Following its 2023 acquisition by Protect AI, Huntr now focuses specifically on AI/ML security: - Bug bounty platform for AI/ML open source projects - CVE assignment for validated vulnerabilities - Bounties funded by Protect AI - Note: For general (non-AI/ML) open source projects, consider other platforms

Starting a bounty program:

If you want to offer bounties directly:

1. Define scope: What's in scope? What's out of scope?

   In scope:
   - Our main repository
   - Official packages and releases
   
   Out of scope:
   - Third-party dependencies (report to them directly)
   - Social engineering
   - Denial of service
   - Issues in unsupported versions
   

2. Set bounty amounts: Be realistic about your budget

   Critical (RCE, auth bypass): $500-$1000
   High (significant data exposure): $250-$500
   Medium (limited impact): $100-$250
   Low (minor issues): Swag + recognition
   

3. Establish rules: Response time, disclosure timeline, payment terms

4. Communicate clearly: Publish your program details prominently

If you can't offer bounties:

Many researchers report vulnerabilities without expecting payment. Offer what you can: - Prompt, respectful communication - Public credit and recognition - Swag (stickers, t-shirts) if available - Letters confirming contribution (useful for researcher employment) - Sincere thanks

Handling Difficult or Unreasonable Researchers¶

Most security researchers are professionals who want to help. Occasionally, you'll encounter difficult situations—unreasonable demands, poor communication, or behavior that crosses lines.

Difficult researcher handling strategies:

Researcher demands immediate disclosure:

Template response:

"I understand you'd prefer faster disclosure, and I appreciate your 
urgency about user safety. Here's my situation: [explain constraints].

I'm committed to [specific timeline] and will provide updates every 
[frequency]. Can we agree on this timeline? I'm open to discussing 
adjustments if you have concerns about specific risks."

Researcher inflates severity:

Some researchers overstate severity for reputation or bounties.

Template response:

"Thank you for your report. I've assessed this issue and believe it's 
[your severity] rather than [claimed severity] because [reasoning].

Specifically:
- [Factor 1 that reduces severity]
- [Factor 2 that reduces severity]

I'm happy to discuss this assessment if you have information I'm missing."

Researcher is unresponsive after initial report:

• Continue with your timeline
• Document all communication attempts
• Proceed to fix and disclosure
• Note in advisory that you attempted coordination

Researcher demands unreasonable bounty:

Template response:

"I appreciate this report. Our bounty guidelines [link] specify 
[amount] for issues of this severity. This is based on [reasoning].

If you believe this issue warrants different treatment, please 
share your reasoning and I'll consider it."

Researcher publishes before coordination:

• Shift to emergency response mode
• Release whatever fix is ready
• Publish advisory immediately
• Don't retaliate or engage in public conflict
• Document what happened for future reference

Researcher is hostile or abusive:

Template response:

"I want to work constructively on this security issue. However, 
[specific behavior] isn't productive for either of us.

I remain committed to addressing this vulnerability and will 
continue processing your report. I ask that future communication 
focus on the technical issues."

If abuse continues, you may: - Continue processing the report professionally - Decline further engagement beyond necessary technical discussion - Report harassment to platform (GitHub, etc.) - Document everything

When to involve others:

• Consult other maintainers for perspective
• Contact platform trust & safety for harassment
• Seek legal advice only if explicit threats made (rare)

Dealing with Public Disclosure Pressure¶

Researchers may pressure you to work faster than you're comfortable with, or threaten public disclosure before you're ready.

Disclosure pressure response:

Understand researcher motivations:

• Conference deadlines (security conferences have submission dates)
• Publication timelines (academic researchers have paper deadlines)
• Reputation concerns (researchers want to publish their findings)
• Genuine user safety concerns (some vulnerabilities are actively exploited)

Standard disclosure timelines:

Negotiating timelines:

Template response:

"The standard 90-day timeline works for most cases. However, 
this issue requires [specific challenges]:

- [Challenge 1: e.g., extensive backporting]
- [Challenge 2: e.g., dependency on upstream fix]
- [Challenge 3: e.g., testing requirements]

I propose [specific timeline]. I'll provide updates every [frequency].

If you have a deadline I should know about (conference, etc.), 
please share it so we can plan accordingly."

When you can't meet their timeline:

Be honest about constraints:

"I understand you want to disclose on [date]. Here's my honest 
assessment: I can have [partial fix / workaround / full fix] ready 
by then.

Options:
1. Partial disclosure with workaround on [their date], full fix later
2. Full disclosure on [your date] with complete fix
3. [Other creative solution]

What works best for user safety?"

Preparing for unwanted disclosure:

If a researcher will disclose before you're ready: - Prepare whatever mitigation you can - Draft an advisory acknowledging the issue - Identify workarounds users can apply - Accelerate your fix timeline where possible - Don't burn bridges—you may work together in the future

Turning Researchers into Contributors¶

Security researchers who report vulnerabilities are demonstrating both skill and interest in your project. Some become valuable long-term contributors.

Researcher-to-contributor pathway:

1. Invite fix collaboration: "Would you like to submit a PR for the fix?"
2. Many researchers enjoy contributing the solution
3. Gives them commit credit and stronger portfolio

4. Reduces your workload

5. Ask for ongoing involvement: "Would you be interested in reviewing security-sensitive PRs occasionally?"

6. Researchers with deep knowledge of your codebase are valuable reviewers

7. Light commitment they can scale to their availability

8. Offer formal role: "We're looking for security-focused maintainers. Based on your contributions, would you be interested?"

9. For researchers who've contributed multiple times

10. Follow normal trust-building process (Section 24.3)

11. Keep them informed: Add them to security discussions (with their permission)

12. Early awareness of future security issues
13. Opportunity to contribute insights

Example outreach:

"Thanks again for reporting CVE-2024-XXXX. Your analysis was 
thorough and helped us fix this quickly.

I noticed you clearly understand our authentication system well. 
Would you be interested in any ongoing involvement with the project? 

Options:
- Review security-sensitive PRs when you have time
- Be notified early about security issues to help with analysis
- Contribute security-focused improvements you think would help

No pressure either way—we appreciate your help regardless."

Benefits of researcher contributors:

• Security expertise you may lack
• Fresh perspective on your codebase
• Ongoing security attention (they may keep looking)
• Credibility signal to other researchers

Expressing Gratitude and Recognition¶

Recognition costs nothing but means a lot to researchers. Proper acknowledgment encourages future reports and builds your reputation in the security community.

Recognition approaches:

Credit communication template:

"Before publishing the advisory, I want to confirm your credit 
preference:

How would you like to be credited?
- Name (e.g., "Jane Smith")
- Handle (e.g., "@researcher")
- Affiliation (e.g., "Jane Smith, Example Security")
- Anonymous

I'll also be listing you on our security hall of fame unless you 
prefer otherwise.

Is there anything else you'd like me to include?"

What researchers appreciate:

• Prompt communication throughout the process
• Being kept informed of progress
• Clear, accurate credit in the format they prefer
• Public acknowledgment (for most researchers)
• Being treated as a partner, not an adversary
• Honest assessment of severity (even when they disagree)
• Professional handling even when disagreements occur

What damages relationships:

• Ignoring reports or going silent
• Dismissing findings without investigation
• Taking credit for researcher's work
• Legal threats against good-faith research
• Publicly criticizing researchers
• Misrepresenting what was reported
• Failing to credit after promising to do so

Recommendations¶

We recommend the following practices for working with security researchers:

1. Build reputation through consistent good behavior: Prompt responses, respectful communication, and proper credit attract quality researchers to your project.

2. Consider bug bounty platforms: Services like Huntr reduce the burden of managing security reports while providing researcher incentives. Even projects without budget can participate.

3. Maintain professionalism in difficult situations: Most difficult situations can be navigated with clear communication. Stay focused on resolving the security issue even when relationships are strained.

4. Negotiate timelines honestly: Explain your constraints; ask about theirs. Most timeline conflicts can be resolved through transparent communication about real constraints.

5. Invite researchers to become contributors: Security researchers who report vulnerabilities are demonstrating skills and interest. Some make excellent ongoing contributors.

6. Express genuine gratitude: Recognition costs nothing but matters significantly. Thank researchers publicly, credit them properly, and treat them as partners in keeping your users safe.

7. Document interactions: Keep records of communications, especially for difficult situations. Documentation protects everyone and helps resolve disputes.

8. Never make legal threats against good-faith researchers: This destroys your reputation in the security community and may drive researchers toward full disclosure rather than coordination.

Security researchers can be among your most valuable collaborators—finding vulnerabilities before attackers do, contributing fixes, and improving your project's security posture. Investing in these relationships pays dividends far beyond any individual vulnerability report.