LLMSecForge: AI Model Security Bounty Program & Responsible Disclosure Framework
/frameworks/bounty-program/
This directory provides a comprehensive framework for establishing, managing, and scaling AI security bounty programs, with detailed guidance on responsible disclosure processes, vulnerability classification, and reward structures specifically tailored for LLMs and multi-modal AI systems.
frameworks/bounty-program/
├── README.md
├── program-design/
│ ├── program-structure.md
│ ├── scope-definition.md
│ ├── vulnerability-taxonomy.md
│ └── rewards-framework.md
├── implementation/
│ ├── platform-selection.md
│ ├── researcher-guidelines.md
│ ├── triage-workflows.md
│ └── program-operations.md
├── disclosure/
│ ├── disclosure-policy.md
│ ├── communication-templates.md
│ ├── publication-guidelines.md
│ └── stakeholder-engagement.md
├── assessment/
│ ├── vulnerability-assessment.md
│ ├── impact-classification.md
│ ├── severity-determination.md
│ └── reward-calculation.md
├── governance/
│ ├── program-oversight.md
│ ├── compliance-integration.md
│ ├── metrics-reporting.md
│ └── continuous-improvement.md
└── templates/
├── bounty-program-policy.md
├── disclosure-agreement.md
├── vulnerability-report.md
└── assessment-worksheet.md
README.md
AI Model Security Bounty Program & Responsible Disclosure Framework
This framework provides a comprehensive approach to establishing, managing, and scaling AI security bounty programs, with specific emphasis on LLMs and multi-modal AI systems. It includes detailed guidance on responsible disclosure processes, vulnerability classification taxonomies, and reward structures specifically calibrated for AI-specific security challenges.
Framework Purpose
This bounty program framework serves multiple critical functions:
- Program Establishment: Comprehensive guidance for creating effective AI security bounty programs
- Vulnerability Management: Structured approaches to vulnerability triage, assessment, and remediation
- Researcher Engagement: Strategies for attracting and retaining high-quality security researchers
- Responsible Disclosure: Transparent, ethical processes for handling vulnerability information
- Risk Reduction: Methods for translating security findings into meaningful risk reduction
Core Framework Components
1. Program Design & Structure
Foundational elements for bounty program creation:
- Program Structure: Organizational models, team composition, and operational frameworks
- Scope Definition: Methodologies for determining appropriate program scope and boundaries
- Vulnerability Taxonomy: AI-specific vulnerability classification system for bounty programs
- Rewards Framework: Structured approach to incentive design and reward determination
2. Implementation Guidance
Practical guidance for program implementation:
- Platform Selection: Criteria and considerations for bounty program platform selection
- Researcher Guidelines: Clear guidelines for participating security researchers
- Triage Workflows: Structured processes for vulnerability report handling
- Program Operations: Day-to-day operational procedures and best practices
3. Responsible Disclosure Framework
Comprehensive approach to ethical disclosure:
- Disclosure Policy: Policy framework for responsible vulnerability disclosure
- Communication Templates: Standardized communications for different disclosure scenarios
- Publication Guidelines: Standards for public disclosure of vulnerability information
- Stakeholder Engagement: Approaches for managing disclosure across stakeholders
4. Vulnerability Assessment
Methodologies for vulnerability evaluation:
- Vulnerability Assessment: Structured approach to validating and assessing reported issues
- Impact Classification: Framework for determining vulnerability impact
- Severity Determination: Methodologies for calculating vulnerability severity
- Reward Calculation: Structured approach to determining appropriate rewards
5. Program Governance
Oversight and management frameworks:
- Program Oversight: Governance structures for bounty program management
- Compliance Integration: Alignment with regulatory and compliance requirements
- Metrics & Reporting: Measurement and reporting frameworks
- Continuous Improvement: Methodologies for ongoing program enhancement
Applications of this Framework
This bounty program framework supports several critical security functions:
- Vulnerability Discovery: Structured approach to finding and addressing security issues
- Security Research Engagement: Framework for productive engagement with the security community
- Security Posture Improvement: Methods for translating findings into security enhancements
- Transparency Demonstration: Evidence of commitment to security transparency
- Regulatory Alignment: Support for compliance with emerging regulatory requirements
For Security Teams
If you're establishing or improving an AI security bounty program:
- Review the program structure to determine the appropriate model for your organization
- Utilize the implementation guidance for practical program establishment
- Leverage the templates for efficient program documentation
- Adopt the assessment methodologies for consistent vulnerability evaluation
For Security Researchers
If you're a security researcher interested in AI system vulnerabilities:
- Review the researcher guidelines to understand participation expectations
- Utilize the vulnerability taxonomy to effectively categorize findings
- Follow the disclosure policy for responsible vulnerability reporting
- Reference the severity and reward frameworks to understand evaluation criteria
Program Structure & Design
# AI Security Bounty Program Structure & Design
This document outlines the foundational elements for establishing an effective AI security bounty program, focusing on organizational structure, scope definition, and program design principles specifically tailored for LLMs and multi-modal AI systems.
## Program Models & Organizational Structure
### Program Models
Different organizational approaches to bounty program design:
| Program Model | Description | Best For |
|---------------|-------------|----------|
| Continuous Bounty Program | Ongoing program with stable scope and rewards | Mature AI products with established security practices |
| Time-Bounded Challenges | Focused testing events for specific periods | New features, major releases, or targeted testing needs |
| Invitation-Only Programs | Restricted programs for vetted researchers | Early-stage programs or highly sensitive systems |
| Public Programs | Open to all security researchers | Established products with robust triage capabilities |
| Hybrid Approaches | Combination of multiple models | Organizations with diverse AI offerings |
### Organizational Structure
Different team structures for managing bounty programs:
| Team Structure | Description | Advantages | Considerations |
|----------------|-------------|------------|----------------|
| Dedicated Bounty Team | Specialized team focused exclusively on bounty program | • Specialized expertise<br>• Consistent researcher experience<br>• Process optimization | • Resource intensive<br>• Potential isolation from dev teams<br>• May require specialized recruiting |
| Integrated Security Function | Bounty program managed within broader security team | • Resource efficiency<br>• Alignment with other security functions<br>• Knowledge sharing | • Competing priorities<br>• Potential skill gaps<br>• Process consistency challenges |
| Distributed Responsibility | Responsibilities distributed across security and product teams | • Direct product team engagement<br>• Efficient triaging<br>• Broader organizational ownership | • Coordination challenges<br>• Inconsistent researcher experience<br>• Knowledge fragmentation risks |
| Hybrid Model | Core team with distributed subject matter experts | • Balanced approach<br>• Specialized knowledge access<br>• Scalability | • Role clarity challenges<br>• Governance complexity<br>• Communication overhead |
### Key Program Roles
Essential roles for effective program operation:
| Role | Responsibilities | Skills Required |
|------|------------------|----------------|
| Program Manager | • Overall program oversight<br>• Researcher relations<br>• Program strategy | • Security program management<br>• Stakeholder management<br>• Strategic planning |
| Triage Specialist | • Initial report assessment<br>• Researcher communication<br>• Vulnerability validation | • Technical security expertise<br>• AI system knowledge<br>• Communication skills |
| Vulnerability Assessor | • Detailed vulnerability analysis<br>• Impact determination<br>• Remediation guidance | • Advanced security assessment<br>• AI vulnerability expertise<br>• Technical writing |
| Developer Liaison | • Engineering team coordination<br>• Remediation tracking<br>• Technical consultation | • Development background<br>• Cross-team collaboration<br>• Technical translation |
| Executive Sponsor | • Program advocacy<br>• Resource allocation<br>• Strategic alignment | • Leadership influence<br>• Security understanding<br>• Resource management |
## Scope Definition Framework
### Scope Definition Process
Systematic approach to defining appropriate program scope:
1. **Inventory Development**
- Catalog all AI models and systems
- Document associated infrastructure
- Identify integration points
- Map data flows
2. **Risk Assessment**
- Evaluate potential impact of vulnerabilities
- Assess architectural exposure
- Consider data sensitivity
- Analyze user base and usage patterns
3. **Capability Evaluation**
- Assess internal triage capacity
- Evaluate remediation capabilities
- Consider monitoring maturity
- Gauge developer response readiness
4. **Scope Formulation**
- Define included systems and boundaries
- Establish explicit exclusions
- Document testing constraints
- Specify acceptable testing methods
### Scope Elements for AI Systems
Key considerations for AI-specific scope definition:
| Scope Element | Considerations | Documentation Guidance |
|---------------|----------------|------------------------|
| Model Boundaries | • Which models and versions are in scope<br>• Testing limitations for specific models<br>• Performance impact constraints | Clearly document specific model versions, endpoints, and allowed testing volumes |
| Testing Methods | • Allowed adversarial techniques<br>• Rate limiting considerations<br>• Automated testing boundaries<br>• Multi-modal testing parameters | Detail specific allowed testing methods with clear boundaries for automation and scale |
| Data Considerations | • Test data parameters<br>• Personally identifiable information (PII) constraints<br>• Synthetic data requirements<br>• Output data handling | Establish clear guidelines for data usage in testing, with specific PII and sensitive data constraints |
| Infrastructure Elements | • API endpoints in scope<br>• Supporting services inclusion/exclusion<br>• Cloud infrastructure boundaries<br>• Developer tools and resources | Map specific infrastructure elements with network boundaries and clear demarcation of in-scope systems |
| Out-of-Scope Elements | • Explicitly excluded systems<br>• Prohibited testing techniques<br>• Third-party service exclusions<br>• Compliance-related exclusions | Provide detailed exclusions with rationale to prevent researcher confusion |
### Scope Documentation Framework
Standardized approach to scope documentation:
```yaml
program_scope:
# Models and systems in scope
in_scope_systems:
- name: "ProductName AI Assistant v2.1"
type: "Text-based LLM"
endpoints:
- "api.example.com/v1/completions"
- "api.example.com/v1/chat"
testing_constraints:
- "Max 100 requests per minute"
- "No PII in prompts"
- name: "ProductName Image Generator v1.5"
type: "Text-to-Image Model"
endpoints:
- "api.example.com/v1/images/generate"
testing_constraints:
- "Max 50 requests per hour"
- "No automated batch testing"
# Explicitly out of scope
out_of_scope:
systems:
- "Internal admin interfaces"
- "Billing systems"
- "Third-party authentication services"
techniques:
- "Denial of service testing"
- "Physical security testing"
- "Social engineering against employees"
impacts:
- "Performance degradation of production systems"
- "Testing affecting other users"
# Testing methods explicitly allowed
allowed_testing_methods:
- "Manual API interaction"
- "Prompt engineering techniques"
- "Custom script automation within rate limits"
- "Content policy boundary testing"
# Testing methods explicitly prohibited
prohibited_testing_methods:
- "Credential brute forcing"
- "Infrastructure vulnerability scanning"
- "Testing with illegal content"
- "Automated testing exceeding rate limits"
Vulnerability Taxonomy for Bounty Programs
AI-Specific Vulnerability Categories
Taxonomy of vulnerability categories specific to AI systems:
| Category | Description | Example Vulnerabilities |
|---|---|---|
| Prompt Injection | Vulnerabilities allowing manipulation of model behavior through crafted inputs | • Instruction override • System prompt disclosure • Context manipulation |
| Model Security Bypass | Vulnerabilities allowing circumvention of security controls | • Content policy evasion • Safety fine-tuning bypass • Filter circumvention |
| Data Extraction | Vulnerabilities allowing unauthorized access to training data or model information | • Training data extraction • Parameter inference • Membership inference |
| Model Functionality Abuse | Vulnerabilities allowing misuse of legitimate model capabilities | • Tool call manipulation • Function injection • Plugin/extension abuse |
| Infrastructure Vulnerabilities | Vulnerabilities in supporting infrastructure | • API vulnerabilities • Service configuration issues • Dependency vulnerabilities |
Vulnerability Acceptance Criteria
Clear criteria for vulnerability inclusion in the program:
| Criteria | Description | Assessment Guidance |
|---|---|---|
| Reproducibility | Vulnerability can be consistently reproduced | Require clear reproduction steps and validation across multiple attempts |
| Realistic Exploitation | Vulnerability has realistic exploitation potential | Assess practical exploitability in real-world contexts |
| Security Impact | Vulnerability has meaningful security impact | Evaluate against security objectives and potential harm |
| Novel Finding | Vulnerability represents a new finding | Compare against known issues and previous reports |
| In-Scope Target | Vulnerability affects in-scope systems | Verify affected systems against defined program scope |
Vulnerability Exclusions
Categories of findings typically excluded from bounty programs:
| Exclusion Category | Rationale | Example |
|---|---|---|
| Theoretical Vulnerabilities | Lack practical exploitability | Pure speculative vulnerabilities without proof of concept |
| Known Limitations | Represent known model constraints rather than vulnerabilities | Publicly documented model limitations |
| Content Policy Disagreements | Represent policy perspectives rather than vulnerabilities | Disagreements with content filtering thresholds |
| UI/UX Issues | Represent design choices rather than security vulnerabilities | Usability issues without security impact |
| Third-Party Vulnerabilities | Beyond program control | Issues in dependent services not maintained by program owner |
Rewards Framework
Reward Structure Models
Different approaches to structuring bounty rewards:
| Reward Model | Description | Advantages | Considerations |
|---|---|---|---|
| Fixed Reward Tiers | Predetermined reward amounts based on severity levels | • Clear expectations • Consistent awards • Simple administration |
• Less flexibility • May undervalue exceptional findings • Can become outdated |
| Dynamic Assessment | Case-by-case determination based on multiple factors | • Precise valuation • Recognition of exceptional work • Adaptability |
• Less predictability • Higher administrative overhead • Potential for researcher disputes |
| Impact-Based Rewards | Rewards tied directly to potential security impact | • Aligned with risk reduction • Focuses researcher effort • Clear value communication |
• Assessment complexity • Impact measurement challenges • Potential model complexity |
| Hybrid Structures | Combination of tiers with adjustment factors | • Balances clarity with flexibility • Adaptable to unique findings • Maintains consistency |
• Requires clear documentation • More complex communication • Potential perception of arbitrariness |
Reward Determination Factors
Key factors influencing reward amounts:
| Factor | Description | Assessment Approach |
|---|---|---|
| Vulnerability Severity | Overall severity rating | Use structured severity calculation methodologies (LLMVS) |
| Exploitation Difficulty | Technical complexity of exploitation | Evaluate technical sophistication and exploitation prerequisites |
| Impact Potential | Potential harm or security impact | Assess alignment with key risk scenarios and potential outcomes |
| Report Quality | Clarity, completeness, and actionability | Evaluate reproduction steps, proof of concept, and remediation guidance |
| Novel Discovery | Uniqueness and innovation | Compare against known techniques and previous reports |
| Affected Scope | Range of affected systems | Determine breadth of impact across systems and users |
Sample Reward Structure for AI Vulnerabilities
Example reward structure specifically for AI system vulnerabilities:
| Severity | Description | Reward Range | Example Vulnerabilities |
|---|---|---|---|
| Critical | Severe vulnerabilities with significant security impact | $10,000 - $50,000+ | • Unauthorized model training data access • Complete safety system bypass • Persistent system prompt override |
| High | Significant vulnerabilities with substantial security implications | $5,000 - $10,000 | • Partial safety system evasion • Effective prompt injection with meaningful impact • Consistent PII extraction techniques |
| Medium | Moderate vulnerabilities with limited security implications | $1,000 - $5,000 | • Limited content policy evasion • Temporary system instruction modification • Constrained unauthorized capability access |
| Low | Minor vulnerabilities with minimal security impact | $250 - $1,000 | • Edge case content policy bypass • Limited information disclosure • Minor security control weaknesses |
Bonuses and Incentives
Additional rewards to incentivize high-value contributions:
| Bonus Type | Description | Implementation Guidance |
|---|---|---|
| Exceptional Quality | Rewards for outstanding reports | Define clear criteria for exceptional quality with examples |
| Novel Techniques | Bonuses for innovative attack methods | Document originality criteria and evaluation process |
| Chaining Bonus | Rewards for combining multiple vulnerabilities | Establish requirements for effective vulnerability chains |
| Critical System Bonus | Enhanced rewards for critical system findings | Clearly designate high-priority systems with enhanced rewards |
| Remediation Insights | Bonuses for valuable fix recommendations | Define criteria for valuable remediation guidance |
Implementation Considerations
Key factors in effective program implementation:
1. Program Messaging and Positioning
Strategic considerations for program communication:
- Value Proposition: Clearly articulate researcher benefits beyond financial rewards
- Security Commitment: Frame program as demonstration of security investment
- Transparency Commitment: Establish clear expectations around disclosure and credit
- Community Engagement: Position program within broader security community
2. Researcher Experience Design
Creating a positive researcher experience:
- Clear Guidelines: Provide comprehensive but accessible program documentation
- Efficient Communication: Establish responsive communication channels and expectations
- Timely Assessment: Create efficient triage and assessment workflows
- Recognition Systems: Develop multiple forms of researcher recognition
3. Legal and Compliance Considerations
Important legal factors in program establishment:
- Safe Harbor Provisions: Clearly define legal protections for good-faith research
- Terms and Conditions: Establish comprehensive program terms with legal review
- Jurisdictional Considerations: Address international legal considerations
- Regulatory Alignment: Ensure program aligns with relevant regulatory requirements
4. Launch Strategy
Approaches to effective program launch:
- Phased Implementation: Consider graduated approach to program scale and scope
- Initial Researcher Pool: Determine initial access strategy (open vs. invited)
- Communications Plan: Develop comprehensive communications strategy
- Success Metrics: Establish clear program success measures
For detailed implementation guidance, templates, and practical examples, refer to the associated documentation in this bounty program framework section.
## Vulnerability Assessment & Impact Classification
```markdown
# Vulnerability Assessment & Impact Classification
This document provides a comprehensive methodology for assessing, classifying, and determining the severity of vulnerabilities reported through AI security bounty programs, with specific focus on issues unique to LLMs and multi-modal AI systems.
## Vulnerability Assessment Process
### Assessment Workflow
Systematic approach to vulnerability evaluation:
1. **Initial Triage**
- Verify report completeness
- Confirm in-scope systems
- Validate reproducibility
- Assign preliminary severity
2. **Technical Validation**
- Reproduce reported issue
- Confirm technical details
- Test exploitation constraints
- Document reproduction steps
3. **Impact Analysis**
- Determine security implications
- Assess potential harm scenarios
- Evaluate exploitation requirements
- Document attack scenarios
4. **Root Cause Analysis**
- Identify underlying causes
- Determine vulnerability class
- Assess broader implications
- Document technical findings
5. **Severity Determination**
- Apply severity framework
- Calculate severity score
- Determine reward tier
- Document severity rationale
### Assessment Team Composition
Recommended expertise for effective assessment:
| Role | Expertise | Assessment Responsibilities |
|------|-----------|----------------------------|
| AI Security Specialist | • LLM security<br>• Adversarial techniques<br>• AI vulnerability patterns | • Technical validation<br>• Attack scenario analysis<br>• AI-specific severity assessment |
| Model Engineer | • Model architecture<br>• Training methodology<br>• Model behavior analysis | • Root cause analysis<br>• Technical validation<br>• Remediation guidance |
| Security Engineer | • Application security<br>• Exploit development<br>• Security controls | • Exploitation validation<br>• Security impact assessment<br>• Control effectiveness analysis |
| Product/Legal Representative | • Product knowledge<br>• Legal/compliance expertise<br>• Risk management | • Business impact assessment<br>• Regulatory implications<br>• Public disclosure considerations |
### Assessment Tooling
Tools and resources for effective vulnerability assessment:
| Tool Category | Purpose | Example Tools |
|---------------|---------|---------------|
| Vulnerability Reproduction | Controlled environment for validation | • Isolated test environments<br>• API testing frameworks<br>• Model testing harnesses |
| Impact Analysis | Tools for understanding potential impact | • Attack simulation frameworks<br>• Threat modeling tools<br>• Impact assessment templates |
| Documentation | Structured documentation of findings | • Vulnerability documentation templates<br>• Evidence collection systems<br>• Assessment worksheets |
| Communication | Researcher and stakeholder communication | • Secure messaging platforms<br>• Vulnerability tracking systems<br>• Disclosure management tools |
## AI-Specific Vulnerability Impact Framework
### Impact Dimensions
Key dimensions for assessing AI vulnerability impact:
| Impact Dimension | Description | Assessment Considerations |
|------------------|-------------|---------------------------|
| Information Disclosure | Unauthorized access to sensitive information | • Type of information exposed<br>• Volume of potential disclosure<br>• Sensitivity of exposed data<br>• Persistence of access |
| System Integrity | Compromise of system intended behavior | • Degree of behavior manipulation<br>• Persistence of manipulation<br>• Detection difficulty<br>• Scope of affected functionality
### Impact Dimensions (continued)
| Impact Dimension | Description | Assessment Considerations |
|------------------|-------------|---------------------------|
| System Integrity | Compromise of system intended behavior | • Degree of behavior manipulation<br>• Persistence of manipulation<br>• Detection difficulty<br>• Scope of affected functionality |
| Authorization Bypass | Circumvention of access controls or permissions | • Level of unauthorized access gained<br>• Authorization boundary affected<br>• Authentication requirement evasion<br>• Privilege elevation potential |
| Safety Mechanism Evasion | Bypassing AI safety controls | • Type of content policy evaded<br>• Consistency of evasion<br>• Scope of safety bypass<br>• Potential harm from bypass |
| Resource Manipulation | Unauthorized use or manipulation of resources | • Computational resource impact<br>• Data resource manipulation<br>• Financial resource implications<br>• Service availability effects |
### Attack Scenario Development
Methodology for understanding potential exploitation:
| Scenario Element | Description | Assessment Approach |
|------------------|-------------|---------------------|
| Attacker Profile | Characterization of potential attackers | • Technical capability requirements<br>• Resource requirements<br>• Motivation factors<br>• Access prerequisites |
| Exploitation Path | Steps required for successful exploitation | • Exploitation complexity<br>• Prerequisite conditions<br>• Technical sophistication<br>• Detection avoidance requirements |
| Impact Scenario | Potential harm or impact from exploitation | • Direct consequences<br>• Secondary effects<br>• Scaling potential<br>• Persistence characteristics |
| Mitigation Difficulty | Complexity of addressing the vulnerability | • Fix complexity<br>• Deployment challenges<br>• Verification difficulties<br>• Side effect potential |
### AI-Specific Impact Categories
Specialized impact assessment for AI vulnerabilities:
| Category | Description | Example Scenarios |
|----------|-------------|-------------------|
| Model Behavior Manipulation | Causing a model to produce unintended outputs | • Safety alignment bypass allowing harmful content<br>• Context manipulation causing false information<br>• Persona manipulation resulting in inappropriate responses |
| Training Data Extraction | Extracting data used to train the model | • Verbatim training data retrieval<br>• Inference of confidential training examples<br>• Reconstruction of protected information |
| Model Knowledge Inference | Inferring model capabilities or configuration | • System prompt extraction<br>• Model parameter inference<br>• Capability boundary mapping |
| Abuse Amplification | Amplifying potential for abuse or misuse | • Automating harmful content generation<br>• Scaling content policy evasion<br>• Enhancing manipulation effectiveness |
| Deployment Context Exploitation | Exploiting the environment where model is deployed | • Context window poisoning<br>• Integration point manipulation<br>• Environment variable exploitation |
## Severity Classification Framework
### LLMVS: Language Model Vulnerability Scoring
Specialized scoring system for LLM vulnerabilities:
| Component | Weight | Description | Assessment Criteria |
|-----------|--------|-------------|---------------------|
| Exploitation Ease | 20% | How easily the vulnerability can be exploited | • Technical complexity<br>• Required resources<br>• Reproducibility<br>• Prerequisites |
| Impact Severity | 35% | Potential negative impact from exploitation | • Harm potential<br>• Scope of impact<br>• Affected users<br>• Persistence |
| Detection Resistance | 15% | Difficulty of detecting exploitation | • Monitoring evasion<br>• Behavioral indicators<br>• Signature development<br>• Detection complexity |
| Model Applicability | 15% | Breadth of affected models or systems | • Model type coverage<br>• Version applicability<br>• Architecture sensitivity<br>• Implementation specificity |
| Remediation Complexity | 15% | Difficulty of addressing the vulnerability | • Fix complexity<br>• Implementation challenges<br>• Verification difficulty<br>• Potential side effects |
### Severity Calculation
Structured approach to calculating vulnerability severity:
```python
# Pseudocode for LLMVS severity calculation
def calculate_severity(assessment):
# Component scores (0-10 scale)
exploitation_ease = assess_exploitation_ease(assessment)
impact_severity = assess_impact_severity(assessment)
detection_resistance = assess_detection_resistance(assessment)
model_applicability = assess_model_applicability(assessment)
remediation_complexity = assess_remediation_complexity(assessment)
# Weighted score calculation
severity_score = (
(exploitation_ease * 0.20) +
(impact_severity * 0.35) +
(detection_resistance * 0.15) +
(model_applicability * 0.15) +
(remediation_complexity * 0.15)
) * 10 # Scale to 0-100
# Severity category determination
if severity_score >= 80:
severity_category = "Critical"
elif severity_score >= 60:
severity_category = "High"
elif severity_score >= 40:
severity_category = "Medium"
else:
severity_category = "Low"
return {
"score": severity_score,
"category": severity_category,
"components": {
"exploitation_ease": exploitation_ease,
"impact_severity": impact_severity,
"detection_resistance": detection_resistance,
"model_applicability": model_applicability,
"remediation_complexity": remediation_complexity
}
}
Severity Level Descriptions
Detailed description of severity categories:
| Severity | Score Range | Description | Response Expectations |
|---|---|---|---|
| Critical | 80-100 | Severe vulnerabilities with broad impact potential and significant harm | • Immediate triage • Rapid remediation plan • Executive notification • Comprehensive mitigation |
| High | 60-79 | Significant vulnerabilities with substantial security implications | • Priority triage • Rapid assessment • Prioritized remediation • Interim mitigations |
| Medium | 40-59 | Moderate vulnerabilities with limited security implications | • Standard triage • Scheduled assessment • Planned remediation • Standard mitigations |
| Low | 0-39 | Minor vulnerabilities with minimal security impact | • Batch triage • Prioritized assessment • Backlog remediation • Documentation updates |
Reward Determination Process
Reward Calculation Framework
Structured approach to determining appropriate rewards:
| Factor | Weight | Description | Assessment Criteria |
|---|---|---|---|
| Base Severity | 60% | Foundational reward based on severity | • LLMVS score and category • Standardized severity tiers • Base reward mapping |
| Report Quality | 15% | Quality and clarity of vulnerability report | • Reproduction clarity • Documentation thoroughness • Evidence quality • Remediation guidance |
| Technical Sophistication | 15% | Technical complexity and innovation | • Novel technique development • Research depth • Technical creativity • Implementation sophistication |
| Program Alignment | 10% | Alignment with program priorities | • Priority area targeting • Program objective advancement • Strategic vulnerability focus • Key risk area impact |
Quality Multiplier Framework
Adjustments based on report quality and researcher contribution:
| Quality Level | Multiplier | Criteria | Example |
|---|---|---|---|
| Exceptional | 1.5x | • Outstanding documentation • Novel research • Comprehensive analysis • Valuable remediation guidance |
Detailed report with novel technique discovery, proof-of-concept code, impact analysis, and specific fix recommendations |
| Excellent | 1.25x | • Above-average documentation • Strong analysis • Good remediation insight • Thorough testing |
Well-documented report with clear reproduction steps, multiple test cases, and thoughtful mitigation suggestions |
| Standard | 1.0x | • Adequate documentation • Clear reproduction • Basic analysis • Functional report |
Basic report with sufficient information to reproduce and understand the vulnerability |
| Below Standard | 0.75x | • Minimal documentation • Limited analysis • Poor clarity • Incomplete information |
Report requiring significant back-and-forth to understand, with unclear reproduction steps or limited evidence |
Reward Calculation Process
Step-by-step process for determining bounty rewards:
Determine Base Reward
- Calculate LLMVS score
- Map severity category to base reward range
- Establish initial position within range based on score
Apply Quality Adjustments
- Assess report quality
- Evaluate technical sophistication
- Determine program alignment
- Calculate composite quality score
Calculate Final Reward
- Apply quality multiplier to base reward
- Consider special circumstances or bonuses
- Finalize reward amount
- Document calculation rationale
Review and Approval
- Conduct peer review of calculation
- Obtain appropriate approval based on amount
- Document final determination
- Prepare researcher communication