Your open source project just received 47 security reports this week. Twelve came from the same AI tool. Six are duplicates. Three describe features, not bugs. Somewhere in that pile might be a critical vulnerability.
The cURL maintainer shut down their bug bounty program because AI-generated submissions made it unsustainable. You need a systematic way to handle this influx before it overwhelms your security process.
Purpose of the Template
This triage template helps you categorize, prioritize, and respond to security reports efficiently. It's designed for projects receiving 10+ security reports per month and needing to separate signal from noise without burning out maintainers.
The template creates a standardized scoring system that your team can apply consistently, whether you're reviewing reports individually or in batches. It also includes response templates that acknowledge submissions professionally while managing expectations about review timelines.
Prerequisites
Before you implement this template, ensure you have:
- A dedicated security email or issue tracker where reports arrive.
- At least two people who can review reports independently to catch scoring bias.
- Baseline documentation of your project's threat model to assess whether a reported issue matters in your context.
- Response authority -- someone on your team needs to be empowered to close invalid reports without endless committee discussion.
Document what your project considers out of scope. If you don't accept reports about dependencies, denial-of-service scenarios that require physical access, or theoretical attacks with no proof of concept, say so upfront.
The Triage Template
Copy this scoring rubric into a spreadsheet or issue template. Score each incoming report 0-3 on these five dimensions, then sum the total:
1. Specificity (0-3)
- 0: Generic description ("your authentication is weak")
- 1: Names a component but vague mechanism ("JWT handling has issues")
- 2: Describes specific behavior ("JWT signature not validated on /api/auth")
- 3: Includes proof of concept or reproduction steps
2. Impact Scope (0-3)
- 0: No security impact or describes expected behavior
- 1: Minor information disclosure with no privilege escalation
- 2: Affects confidentiality or integrity of user data
- 3: Remote code execution, authentication bypass, or data destruction
3. Source Credibility (0-3)
- 0: Obvious AI generation (generic language, multiple unrelated issues in one report, references non-existent functions)
- 1: Unclear origin, no prior interaction with project
- 2: Known security researcher or previous valid submission
- 3: Includes working exploit code or detailed analysis
4. Threat Model Alignment (0-3)
- 0: Describes scenario outside your documented threat model
- 1: Edge case that requires unlikely preconditions
- 2: Realistic attack path but requires user error
- 3: Directly exploitable in default configuration
5. Actionability (0-3)
- 0: No clear fix possible or requires complete architectural change
- 1: Fix possible but would break compatibility
- 2: Can be fixed in minor release
- 3: Clear, backwards-compatible fix identified
Total Score Interpretation:
- 12-15: Critical -- review within 24 hours
- 8-11: High priority -- review within one week
- 4-7: Standard queue -- review within 30 days
- 0-3: Close with template response
Response Templates
For scores 0-3, use this template to close efficiently:
Thank you for your submission. After review, this report doesn't align with
our project's threat model [link to threat model doc].
[If AI-generated]: We've noticed an increase in automated security scanning.
While we appreciate the intent, we ask that submissions include manual
verification and specific reproduction steps.
[If out of scope]: This scenario falls outside our documented security
boundaries because [brief reason].
We're closing this report but welcome future submissions that include proof
of concept and demonstrate impact within our threat model.
For scores 4-7, acknowledge and set expectations:
We've received your report and scored it as standard priority. Our current
queue time is approximately [X days]. We'll follow up by [specific date]
with either a fix timeline or additional questions.
In the meantime, if you identify this as more critical than initially
described, please reply with additional context about [specific gap in
the original report].
For scores 8+, engage immediately with specific questions about reproduction or impact.
Customizing the Template
Adjust the threat model weight based on your project's maturity. Early-stage projects might score threat model alignment lower since you're still defining boundaries. Production-critical infrastructure projects should weight it heavily.
Modify impact scoring for your domain. A library used in embedded systems might treat resource exhaustion as a 3, while a web framework might score it as a 1. Document your adjustments in a "Scoring Guide" that reviewers can reference.
Add a sixth dimension if you're dealing with specific abuse patterns. Some projects add "Report Quality" to catch submissions that bundle 15 unrelated issues together, making them impossible to track. Others add "Upstream/Downstream" to identify whether the issue exists in your code or a dependency.
Set score thresholds based on your capacity. If you're getting 100 reports per month with a two-person team, you might close everything under 5 instead of 3. Adjust monthly based on your backlog size.
Validation Steps
After implementing this template for 30 days:
Check for false negatives. Review your closed reports (scores 0-3) and verify that none contained actual vulnerabilities. If you're finding real issues in the closed pile, your scoring is too aggressive -- lower the threshold or add weight to specificity scoring.
Measure response time distribution. You should see 80%+ of critical reports (12-15) getting initial response within 48 hours. If not, you're either understaffed or your critical threshold is too low.
Track AI-generated volume. Count how many reports score 0 on source credibility. If this number exceeds 30% of total submissions, add CAPTCHA or proof-of-work requirements to your submission process. The cURL project's experience shows that unmanaged AI submissions will eventually make any bug bounty program unsustainable.
Review scorer agreement. If you have two reviewers scoring the same reports, they should agree within 2 points on total score for 90%+ of submissions. Larger disagreements mean you need clearer rubric definitions or more calibration discussions.
Audit your threat model documentation. If more than 20% of reports score 0 on threat model alignment, your documented boundaries aren't clear enough. Reporters shouldn't have to guess what you consider in-scope.
This template won't eliminate low-quality reports, but it will prevent them from consuming all your security bandwidth. When you can close 40% of submissions in under five minutes with a template response, you create space to actually fix the vulnerabilities that matter.
