dumped.

[Pritz395]

[github-actions]

  🚫 **Please do not create new issues**  
  We currently have **many open issues** to focus on, some even with $5 bounties.
  
  If you believe your issue is important and should be solved,  
  please create a new topic in the BLT forum page instead.  
  Thanks for understanding! 🙏

[Pritz395]

@coderabbitai review my gsoc draft proposal by reviewing practicality of being built + also for the 8 milestones give the realistic approach to working on it. # GitHub Security Contribution Gamification & Recognition Platform - GSoC Proposal

Building on: BLT's existing GitHubIssue/GitHubReview/webhook infrastructure, CVE fields, BACON, badges, and daily challenges work (PR #5245).

Goal: Track security-focused GitHub PRs/reviews/issues (especially post-disclosure CVE fixes), link them to existing CVE data via NVD API validation, reward contributors with BACON/badges after maintainer verification, and surface impact-based leaderboards, dashboards, and challenges around security work.

Post-Disclosure Scope: This system tracks CVE contributions after public disclosure (respects responsible disclosure practices). Cannot track private/embargoed security work due to GitHub API limitations (private advisories deprecated May 2024) and ethical disclosure practices. Most CVE work eventually becomes public, making post-disclosure tracking practical and secure.

---

System Architecture

Architecture Diagram

graph TB
    subgraph "GitHub Integration Layer"
        GH[GitHub Webhook]
        GHPR[Pull Request Events]
        GHREV[Review Events]
    end

    subgraph "BLT Webhook Handler (Existing)"
        WEBHOOK[github_webhook view]
        PRHANDLER[handle_pull_request_event]
        REVHANDLER[handle_review_event]
    end

    subgraph "CVE Detection & Validation"
        CVEDETECT[CVE Pattern Matcher]
        NVDAPI[NVD API Client<br/>nvdlib]
        CVESCORE[CVE Severity Calculator]
    end

    subgraph "Database Models (Existing + New)"
        GHI[GitHubIssue<br/>Existing]
        GHR[GitHubReview<br/>Existing]
        ISSUE[Issue<br/>cve_id, cve_score<br/>Existing]
        GHSC[GitHubSecurityContribution<br/>NEW MODEL]
        USER[User/UserProfile<br/>Existing]
        CONTRIB[Contributor<br/>Existing]
        REPO[Repo<br/>Existing]
    end

    subgraph "Verification Workflow"
        VERIFYVIEW[SecurityContributionVerificationView<br/>NEW VIEW]
        VERIFIER[Maintainer/Verifier<br/>can_verify_security_contributions]
        VERIFYSTATUS[verification_status<br/>pending/verified/rejected/disputed]
        RATELIMIT[Rate Limiting<br/>5/month per contributor]
    end

    subgraph "Reward System (Existing)"
        SIGNAL[post_save signal<br/>on verification]
        GIVEBACON[giveBacon function<br/>feed_signals.py]
        BACON[BaconEarning<br/>Existing]
        BADGE[Badge/UserBadge<br/>Existing]
    end

    subgraph "Leaderboard System (Existing + Extension)"
        LBASE[LeaderboardBase<br/>Existing]
        SECLB[SecurityLeaderboardView<br/>EXTENDS LeaderboardBase]
        GLOBLB[GlobalLeaderboardView<br/>Existing]
    end

    subgraph "Challenge System (Existing + Extension)"
        CHALLENGE[Challenge Model<br/>Existing]
        CHALSIG[challenge_signals.py<br/>update_challenge_progress]
        SECCHAL[Security Daily Challenges<br/>EXTENDS Challenge]
    end

    subgraph "Analytics & Security"
        RATELIMITMW[Rate Limiting Middleware<br/>Existing]
        SPAMDETECT[Spam Detection<br/>Duplicate Check<br/>Reputation Tracking]
        ANALYTICS[Security Analytics Dashboard<br/>Chart.js Visualizations<br/>NEW VIEW]
    end

    subgraph "UI Components"
        SECDASH[Security Dashboard<br/>NEW TEMPLATE]
        VERIFYDASH[Verification Dashboard<br/>NEW TEMPLATE]
        LEADERBOARDUI[Leaderboard UI<br/>Existing]
    end

    %% Flow connections
    GH -->|POST webhook| WEBHOOK
    WEBHOOK -->|routes| PRHANDLER
    WEBHOOK -->|routes| REVHANDLER

    PRHANDLER -->|creates/updates| GHI
    REVHANDLER -->|creates/updates| GHR

    PRHANDLER -->|detects CVE in PR| CVEDETECT
    CVEDETECT -->|extracts CVE ID| NVDAPI
    NVDAPI -->|validates & fetches| CVESCORE
    CVESCORE -->|creates| GHSC

    GHSC -->|references| GHI
    GHSC -->|references| GHR
    GHSC -->|references| USER
    GHSC -->|references| CONTRIB
    GHSC -->|references| REPO
    GHSC -->|cve_id links to| ISSUE

    GHSC -->|status: pending| VERIFYVIEW
    VERIFIER -->|reviews in| VERIFYVIEW
    VERIFYVIEW -->|updates| VERIFYSTATUS

    VERIFYSTATUS -->|verified| SIGNAL
    SIGNAL -->|triggers| GIVEBACON
    GIVEBACON -->|awards| BACON
    SIGNAL -->|awards| BADGE

    GHSC -->|aggregated| SECLB
    SECLB -->|extends| LBASE
    LBASE -->|used by| GLOBLB

    GHSC -->|tracks| SECCHAL
    SECCHAL -->|extends| CHALLENGE
    CHALLENGE -->|updates via| CHALSIG

    GHSC -->|monitored by| RATELIMIT
    GHSC -->|analyzed by| SPAMDETECT
    GHSC -->|displayed in| ANALYTICS

    VERIFYVIEW -->|renders| VERIFYDASH
    ANALYTICS -->|renders| SECDASH
    SECLB -->|renders| LEADERBOARDUI

    style SECLB fill:#e74c3c,stroke:#c0392b,stroke-width:2px,color:#fff

    style GHSC fill:#e74c3c,stroke:#c0392b,stroke-width:3px,color:#fff
    style VERIFYVIEW fill:#e74c3c,stroke:#c0392b,stroke-width:2px,color:#fff
    style NVDAPI fill:#e74c3c,stroke:#c0392b,stroke-width:2px,color:#fff
    style SECCHAL fill:#e74c3c,stroke:#c0392b,stroke-width:2px,color:#fff

Loading

Database Entity Relationship Diagram

erDiagram
    User ||--o{ UserProfile : has
    User ||--o{ UserBadge : "earns"
    User ||--o{ BaconEarning : "accumulates"
    User ||--o{ GitHubSecurityContribution : "creates"

    UserProfile ||--o{ GitHubIssue : "creates"
    UserProfile ||--o{ GitHubReview : "reviews"
    UserProfile ||--o{ Issue : "reports"

    Contributor ||--o{ GitHubIssue : "contributes"
    Contributor ||--o{ GitHubReview : "reviews"
    Contributor ||--o{ GitHubSecurityContribution : "contributes"

    Repo ||--o{ GitHubIssue : "contains"
    Repo ||--o{ GitHubSecurityContribution : "tracks"

    GitHubIssue ||--o{ GitHubReview : "has"
    GitHubIssue ||--o{ GitHubSecurityContribution : "references"

    Issue ||--o{ GitHubSecurityContribution : "linked via CVE"

    Badge ||--o{ UserBadge : "awarded as"

    Challenge ||--o{ GitHubSecurityContribution : "tracks"

    User {
        int id PK
        string username
        string email
    }

    UserProfile {
        int id PK
        int user_id FK
        string github_url
        boolean is_verifier
    }

    Contributor {
        int id PK
        int github_id UK
        string name
        string github_url
    }

    Repo {
        int id PK
        string repo_url UK
        string name
    }

    GitHubIssue {
        bigint id PK
        bigint issue_id
        int repo_id FK
        int user_profile_id FK
        int contributor_id FK
        string type
        boolean is_merged
        datetime merged_at
    }

    GitHubReview {
        bigint id PK
        bigint review_id UK
        bigint pull_request_id FK
        int reviewer_id FK
        int reviewer_contributor_id FK
        string state
    }

    Issue {
        int id PK
        int user_id FK
        string cve_id
        decimal cve_score
    }

    GitHubSecurityContribution {
        int id PK
        bigint github_issue_id FK
        bigint github_review_id FK
        int contributor_id FK
        int repo_id FK
        string cve_id
        decimal cve_score
        string severity
        string verification_status
        int verifier_id FK
        datetime verified_at
        datetime created_at
    }

    Badge {
        int id PK
        string title
        string type
    }

    UserBadge {
        int id PK
        int user_id FK
        int badge_id FK
        int awarded_by_id FK
        datetime awarded_at
    }

    BaconEarning {
        int id PK
        int user_id FK
        int tokens_earned
    }

    Challenge {
        int id PK
        string title
        string challenge_type
        int bacon_reward
    }

Loading

Note on Field Types:

• Contributor.github_id: Currently IntegerField in codebase. Consider migrating to BigIntegerField for GitHub IDs > 2^31 (future-proofing).
• Issue.cve_score: Currently max_digits=2 in codebase. Requires migration to max_digits=3 to support CVSS scores up to 10.0 (see Database Changes section below).

---

Complete Workflow Sequence

Main Flow: PR Merge to BACON Award

sequenceDiagram
    participant GH as GitHub
    participant WH as Webhook Handler<br/>(github_webhook)
    participant PRH as PR Event Handler<br/>(handle_pull_request_event)
    participant CVED as CVE Detector<br/>(NEW)
    participant NVD as NVD API<br/>(nvdlib)
    participant DB as Database<br/>(GitHubSecurityContribution)
    participant VER as Verification View<br/>(SecurityContributionVerificationView)
    participant MAINT as Maintainer<br/>(is_verifier=True)
    participant SIG as Django Signal<br/>(post_save)
    participant BACON as giveBacon<br/>(feed_signals.py)
    participant BADGE as Badge System<br/>(Existing)
    participant CHAL as Challenge System<br/>(challenge_signals.py)
    participant LB as Leaderboard<br/>(SecurityLeaderboardView)

    Note over GH,MAINT: Phase 1: PR Merge Detection
    GH->>WH: POST /github-webhook/<br/>pull_request event<br/>(action=closed, merged=true)
    WH->>WH: Validate HMAC signature
    WH->>PRH: Route to handle_pull_request_event()

    Note over PRH,DB: Phase 2: CVE Detection & Validation
    PRH->>PRH: Extract PR data<br/>(title, body, merged_at)
    PRH->>PRH: Update/create GitHubIssue record
    PRH->>CVED: Check for CVE pattern<br/>(CVE-YYYY-NNNNN)

    alt CVE Pattern Found
        CVED->>CVED: Extract CVE ID from PR text
        CVED->>NVD: GET /rest/json/cves/2.0?cveId={cve_id}
        NVD-->>CVED: CVE data + CVSS score

        CVED->>CVED: Calculate severity<br/>(Critical/High/Medium/Low)
        CVED->>DB: Create GitHubSecurityContribution<br/>status='pending'<br/>severity={calculated}<br/>cve_score={from NVD}

        Note over DB: Links to:<br/>- GitHubIssue<br/>- Contributor<br/>- Repo
    else No CVE Found
        PRH->>PRH: Continue normal PR processing
    end

    Note over VER,MAINT: Phase 3: Maintainer Verification
    DB->>VER: Query pending contributions<br/>(verification_status='pending')
    VER->>MAINT: Display verification dashboard<br/>(SecurityContributionVerificationView)

    MAINT->>VER: Review contribution details<br/>(CVE ID, PR link, severity)
    MAINT->>VER: Click "Verify" or "Reject"

    alt Verified
        VER->>DB: Update GitHubSecurityContribution<br/>verification_status='verified'<br/>verifier_id={maintainer}<br/>verified_at={now}

        Note over SIG,BADGE: Phase 4: Reward Distribution
        DB->>SIG: post_save signal triggered<br/>(verification_status='verified')
        SIG->>BACON: Calculate BACON reward<br/>(Critical=100, High=75,<br/>Medium=50, Low=25)
        BACON->>BACON: Update BaconEarning<br/>tokens_earned += reward_amount

        SIG->>BADGE: Check badge criteria<br/>(e.g., "First CVE Fix",<br/>"Critical Security Expert")
        alt Badge Criteria Met
            BADGE->>BADGE: Create UserBadge record
        end

        Note over CHAL,LB: Phase 5: Challenge & Leaderboard Updates
        SIG->>CHAL: update_challenge_progress()<br/>challenge_title="Fix 5 CVEs"<br/>model=GitHubSecurityContribution
        CHAL->>CHAL: Check if challenge completed
        alt Challenge Completed
            CHAL->>BACON: Award challenge BACON reward
        end

        SIG->>LB: Update SecurityLeaderboardView<br/>Aggregate by contributor
        LB->>LB: Recalculate rankings

        VER-->>MAINT: Success: Contribution verified<br/>BACON awarded
    else Rejected
        VER->>DB: Update GitHubSecurityContribution<br/>verification_status='rejected'<br/>verifier_id={maintainer}<br/>verified_at={now}
        VER-->>MAINT: Contribution rejected<br/>(no rewards)
    end

    Note over GH,LB: End: Contribution tracked in<br/>leaderboards, challenges, and user profile

Loading

---

Integration with Existing BLT Infrastructure

Key Integration Points

1. GitHub Webhook System (website/views/user.py)

   • Extends handle_pull_request_event() to detect CVE references
   • Extends handle_review_event() for review-based contributions
   • No changes to webhook routing or signature validation

2. Database Models

   • New: GitHubSecurityContribution model
   • Uses: Existing GitHubIssue, GitHubReview, Contributor, Repo, UserProfile
   • Links to: Existing Issue model via cve_id field

3. Reward System (website/feed_signals.py)

   • Uses existing giveBacon() function
   • Integrates with existing BaconEarning model
   • Extends badge system via Badge/UserBadge models

4. Leaderboard System (website/views/user.py)

   • Extends LeaderboardBase class (no modifications to base)
   • New SecurityLeaderboardView inherits all base functionality
   • Integrates with existing GlobalLeaderboardView

5. Challenge System (website/challenge_signals.py)

   • Uses existing update_challenge_progress() function
   • Extends Challenge model (no schema changes)
   • Integrates with existing challenge completion flow

6. Verification System

   • Uses existing UserProfile.is_verifier field
   • New view follows existing BLT view patterns
   • No changes to user permission system

---

Database Changes Required

Migration 1: Fix Issue.cve_score Field Constraint

Current: Issue.cve_score = models.DecimalField(max_digits=2, decimal_places=1)
Problem: Max value is 9.9, but CVSS scores go up to 10.0
Fix: Change to max_digits=3, decimal_places=1 to support scores 0.0-10.0

# Migration needed in website/migrations/
class Migration(migrations.Migration):
    operations = [
        migrations.AlterField(
            model_name='issue',
            name='cve_score',
            field=models.DecimalField(max_digits=3, decimal_places=1, blank=True, null=True),
        ),
    ]

Migration 2: Contributor.github_id Field Type (Optional)

Current: Contributor.github_id = models.IntegerField()
Note: GitHub user IDs can exceed 32-bit integer limits (2^31). Consider migrating to BigIntegerField if needed for future-proofing, though current IntegerField works for most cases.

---

Files to Create/Modify

New Files

1. website/models.py - Add GitHubSecurityContribution model
2. website/security_signals.py - Signal handlers for rewards
3. website/services/cve_service.py - NVD API integration
4. website/views/security.py - Verification dashboard view
5. website/templates/security/verification_dashboard.html - Maintainer UI
6. website/templates/leaderboard_security.html - Security leaderboard UI
7. website/templates/security/dashboard.html - User-facing dashboard
8. website/static/js/security-dashboard.js - Client-side interactions
9. website/migrations/XXXX_create_github_security_contribution.py - Database migration

Modified Files

1. website/views/user.py - Extend webhook handlers, add SecurityLeaderboardView
2. website/challenge_signals.py - Add security challenge handlers
3. blt/urls.py - Add security routes
4. website/admin.py - Register new model
5. blt/settings.py - Add NVD API config

Dependencies

[tool.poetry.dependencies]
nvdlib = "^0.3.0"  # NVD API client

---

Implementation Timeline (~350-370h total)

Milestone 1: CVE Detection & Tracking

• Extract CVE IDs from merged PR/issue content using CVE-\d{4}-\d{4,7} regex pattern (to be created)
• Create CVE regex pattern utility function
• Link to Issue.cve_id, store in new GitHubSecurityContribution model
• Wire into github_webhook handlers
• Update handle_pull_request_event(), handle_review_event(), handle_issue_event() to detect CVE references
• Post-disclosure scope: Track CVE contributions after public disclosure (respects responsible disclosure practices)

Milestone 2: NVD API Validation & Pre-Screening

• Integrate nvdlib (NIST NVD API wrapper) to validate CVE IDs exist
• Fetch severity scores (CRITICAL/HIGH/MEDIUM/LOW) and descriptions
• Pre-screen contributions to block:
  • Fake CVE IDs
  • Documentation-only PRs claiming CVE credit
  • Duplicate submissions
  • Contributors with spam history
• Rate limiting: Max 5 CVE contribution claims per contributor per month (Django cache)

Milestone 3: Maintainer Verification Workflow

• Build SecurityContributionVerificationView admin dashboard for maintainers
• New model fields: verification_status, verified_by, verification_notes
• Permissions: Add can_verify_security_contributions permission
• Dashboard shows: CVE details from NVD, PR diff, contributor history
• Actions: Verify, Reject, Request More Info, Dispute

Milestone 4: Reward Distribution

• Use giveBacon() from feed_signals.py so verified CVE-fix PRs auto-earn BACON
• Scaled by severity: Critical=100, High=75, Medium=50, Low=25
• Security badges via existing Badge/UserBadge models
• Reward gating: BACON only awarded after maintainer verification (via Django signal)
• Tracks bacon_awarded and bacon_amount fields

Milestone 5: Security Leaderboards

• Build leaderboards extending LeaderboardBase
• Rank by impact (cve_score × contribution count)
• Separate views for PRs, reviews, and security issues
• Time-period filtering (monthly, yearly, all-time)
• Contributor reputation metrics

Milestone 6: Security Daily Challenges

• Add GitHub security challenge types to Challenge.CHALLENGE_TYPE_CHOICES (depends on PR Add Daily Challenges Feature with 24-Hour Reset Timer #5245 being merged first)
• Extend update_challenge_progress() to validate via GitHubSecurityContribution
• Examples: "Fix a MEDIUM+ CVE this week", "Review 3 security PRs"

Milestone 7: Security Dashboard UI

• Create accessible, dark-mode SecurityContributionDashboardView
• Shows contributions, badges, verification status, timelines, impact metrics
• Reuse ARIA/dark-mode patterns from PRs Improve accessibility: Added ARIA labels to icon-only buttons and enhance keyboard navigation #4937 and fix: Add dark mode support to organization dashboard pages #5169
• Charts for CVE trends (Chart.js), severity distribution, top contributors

Milestone 8: Analytics, Tests & Docs

• SecurityAnalyticsView with Django ORM aggregations for CVE fixes over time
• Top contributors/orgs analytics
• End-to-end tests extending test_github_webhook.py
• Fraud scenario tests: Fake CVEs, duplicate submissions, trivial PRs, rate limit violations
• Maintainer verification guide
• Contributor CVE claiming guide
• Security audit of verification logic

---

Security & Fraud Prevention

1. Rate Limiting

   • Uses existing middleware (blt/middleware/throttling.py)
   • Prevents spam contribution creation

2. Verification Requirement

   • All contributions require maintainer verification
   • No automatic rewards without verification

3. CVE Validation

   • NVD API validates CVE IDs
   • Invalid CVEs marked as 'Unknown' severity
   • Maintainer can override during verification

4. Audit Trail

   • Tracks verifier and verification timestamp
   • Rejection reasons stored
   • All changes logged

---

Success Criteria

1. CVE detection works for merged PRs
2. NVD API integration validates CVEs
3. Maintainer verification workflow functional
4. BACON rewards awarded correctly (Critical=100, High=75, Medium=50, Low=25)
5. Badges awarded for milestones
6. Security leaderboard displays correctly
7. Challenges track security contributions
8. Fraud prevention measures effective
9. Performance acceptable (<500ms for verification)
10. Documentation complete

---

Scope & Limitations

What This Tracks

• Publicly disclosed CVE fixes (post-disclosure only)
• Merged PRs with CVE references
• Published GitHub Security Advisories
• Security reviews and security-labeled issues
• Security-labeled PRs (if GitHub provides labels)

What This Doesn't Track

• Private/embargoed CVE work (respects responsible disclosure)
• Unpublished security advisories
• Pre-disclosure contributions

Why Post-Disclosure?

• Ethical: Respects responsible disclosure practices
• Secure: No premature vulnerability leaks
• Practical: Most CVE work eventually becomes public
• API Limitation: GitHub deprecated private advisory access (May 2024)

Data Flow Summary

GitHub PR Merge (with CVE reference)
    ↓
Webhook Handler (detects CVE pattern)
    ↓
Pre-Screening:
  - Check rate limit (5/month)
  - Check duplicate submission
  - Check spam history
    ↓
CVE Service (validates via NVD API)
    ↓
Create GitHubSecurityContribution (status='pending')
    ↓
Verification Dashboard (maintainer reviews)
  - Shows CVE details from NVD
  - Shows PR diff
  - Shows contributor history
    ↓
Update status to 'verified' (or 'rejected'/'disputed')
    ↓
Django Signal triggers (only if verified)
    ↓
giveBacon() awards tokens (Critical=100, High=75, Medium=50, Low=25)
    ↓
Badge system awards badges
    ↓
Challenge system updates progress
    ↓
Leaderboard updates rankings

---

UI/UX Considerations

• Uses Tailwind CSS (existing BLT standard)
• Brand color: #e74c3c (red)
• Responsive design with dark-mode support
• Real-time updates via AJAX
• Clear verification workflow
• User-friendly error messages
• Chart.js visualizations for CVE trends, severity distribution
• Accessible design (ARIA patterns from PRs Improve accessibility: Added ARIA labels to icon-only buttons and enhance keyboard navigation #4937 and fix: Add dark mode support to organization dashboard pages #5169)
• Security dashboard shows:
  • Contributions timeline
  • Badges earned
  • Verification status
  • Impact metrics
  • CVE trends charts
  • Top contributors visualization

---

Bonus: MY-GSOC-TOOL Integration

Since we're tracking security contribution data, it could connect to MY-GSOC-TOOL, so students could showcase security PRs in GSoC portfolios. Not part of core scope, but easy to add a REST API endpoint later.

Related Work

• PR Feature: Add CVE Search, Filtering, Caching, and Autocomplete #5057: CVE Search, Filtering, Caching, Autocomplete (Open)
• PR Add Daily Challenges Feature with 24-Hour Reset Timer #5245: Daily Challenges with 24-Hour Reset (Open)
• PR fixed: Add security headers, fix CSRF exemptions, and harden configuration #5371: Security Headers & CSRF (Open)
• PR Add Session Security Flags, Fix Timing Attack Vulnerability, and Enable API Rate Limiting #5351: Session Security, Rate Limiting (Open)

Note: This proposal builds entirely on top of existing BLT infrastructure. No existing features are replaced or removed. All new functionality integrates seamlessly with current systems including GitHub webhooks, BACON rewards, badges, challenges, and leaderboards.

[coderabbitai]

Coding Plan

Approach

Build a GitHub Security Contribution Gamification & Recognition Platform that tracks post-disclosure CVE fixes in GitHub PRs/reviews, validates them via NVD API, requires maintainer verification, and rewards contributors with BACON tokens and badges. Extend existing BLT infrastructure (webhooks, leaderboards, challenges) to surface security impact metrics and prevent fraud.

Observations

BLT is a Django application with an established GitHub webhook system (website/views/user.py) that validates HMAC signatures and routes events to handlers. It uses synchronous external API calls with the requests library, Django signals for reward distribution via giveBacon(), and extends leaderboards through LeaderboardBase. The challenge system uses update_challenge_progress() to track user achievements. There's no async task queue—background jobs run as Django management commands. Rate limiting is manual (sleep delays and Django cache), and verification uses UserProfile.is_verifier permissions.

Assumptions

Assumption 1: NVD API Call Strategy

Options Considered:

• Synchronous API call during webhook processing (matches existing GitHub API pattern)
• Async with Celery background task (better performance but requires new infrastructure)
• Management command for batch processing (defers all validation)

Chosen Option: 1

Rationale: The codebase uses synchronous requests calls for all external APIs (GitHub, SendGrid, OpenAI). Adding Celery would introduce unnecessary infrastructure complexity for a use case that tolerates 1-2 second webhook response times.

Assumption 2: Rate Limiting Implementation

Options Considered:

• Django cache with contributor-keyed counters (matches existing GitHub API rate limit pattern)
• Database model with monthly counter fields
• Django middleware rate limiting

Chosen Option: 1

Rationale: The codebase already uses Django cache for GitHub API rate limit tracking (website/views/core.py). This pattern is established and performant for time-window-based limits.

Assumption 3: CVE Score Field Migration Timing

Options Considered:

• Migrate immediately as first step (cleaner, prevents issues)
• Migrate only when GitHubSecurityContribution model is created (bundled migration)

Chosen Option: 1

Rationale: Fixing the constraint immediately prevents data validation errors during testing and keeps migrations focused. This also allows the Issue model to correctly store CVE scores from NVD API validation in Phase 2.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Core Data Model & CVE Detection Foundation

This phase establishes the fundamental data structures and detection logic needed to identify and track security contributions before any external validation or verification workflows are added.

Task 1: Fix Issue Model CVE Score Constraint

Correct the existing Issue.cve_score field to support the full CVSS score range (0.0-10.0).

• Create migration to alter Issue.cve_score field from max_digits=2 to max_digits=3 in website/models.py
• Verify existing cve_score values won't be affected (max should be 9.9 currently)
• Update model field definition to DecimalField(max_digits=3, decimal_places=1)

Task 2: Create GitHubSecurityContribution Model

Define the central model for tracking security contributions with verification workflow support.

• Add GitHubSecurityContribution model to website/models.py with fields:
  • ForeignKey to GitHubIssue (nullable, for PR-based contributions)
  • ForeignKey to GitHubReview (nullable, for review-based contributions)
  • ForeignKey to Contributor (required, who made the contribution)
  • ForeignKey to Repo (required, which repository)
  • cve_id CharField for CVE identifier
  • cve_score DecimalField(max_digits=3, decimal_places=1) for CVSS score
  • severity CharField with choices (CRITICAL/HIGH/MEDIUM/LOW/UNKNOWN)
  • verification_status CharField with choices (pending/verified/rejected/disputed)
  • ForeignKey to User as verifier (nullable, who verified)
  • verified_at DateTimeField (nullable)
  • bacon_awarded BooleanField (default False)
  • bacon_amount IntegerField (default 0)
  • Timestamps: created_at, updated_at
• Add model methods: get_display_severity(), is_verified(), can_award_bacon()
• Include __str__() method for admin display
• Register model in website/admin.py with list filters for status, severity, repo

Task 3: Create CVE Pattern Detection Utility

Build reusable CVE detection and parsing functions following existing utility patterns.

• Add CVE detection functions to website/utils.py (matches existing utility pattern):
  • extract_cve_ids(text): Uses regex CVE-\d{4}-\d{4,7} to find all CVE IDs in text
  • is_valid_cve_format(cve_id): Validates CVE ID format
  • deduplicate_cve_ids(cve_list): Returns unique CVE IDs
• Return list of CVE ID strings from PR titles, bodies, commit messages
• Handle edge cases: malformed IDs, duplicates, case sensitivity

🤖 Prompt for AI agents

Establish data model and CVE detection foundation for tracking security
contributions.

Migrate Issue.cve_score to support full CVSS range (0.0-10.0) by changing
max_digits from 2 to 3

Create GitHubSecurityContribution model in website/models.py with:
- Foreign keys to GitHubIssue, GitHubReview, Contributor, Repo, and User
(verifier)
- CVE tracking fields: cve_id, cve_score, severity (choices:
CRITICAL/HIGH/MEDIUM/LOW/UNKNOWN)
- Verification workflow fields: verification_status (choices:
pending/verified/rejected/disputed), verifier, verified_at
- Reward tracking fields: bacon_awarded (Boolean), bacon_amount (Integer)
- Timestamps: created_at, updated_at
- Methods: get_display_severity(), is_verified(), can_award_bacon(), __str__()
- Register in admin with filters for status, severity, repo

Add CVE detection utilities to website/utils.py:
- extract_cve_ids(text): regex pattern CVE-\d{4}-\d{4,7} to find all CVE IDs
- is_valid_cve_format(cve_id): validate CVE ID format
- deduplicate_cve_ids(cve_list): return unique CVE IDs
- Handle malformed IDs, duplicates, case sensitivity

Phase 2: Webhook Integration & NVD Validation

This phase connects CVE detection to the existing GitHub webhook flow and validates contributions against the authoritative NVD database before creating security contribution records.

Task 1: Integrate NVD API Client Service

Create a service module for NVD API interactions following synchronous patterns established for GitHub API.

• Create website/services/cve_service.py with NVDService class:
  • validate_cve(cve_id): Calls NVD API using nvdlib.searchCVE(cveId=cve_id)
  • get_cve_score(cve_data): Extracts CVSS baseScore from NVD response
  • calculate_severity(score): Maps score to severity (Critical: 9.0-10.0, High: 7.0-8.9, Medium: 4.0-6.9, Low: 0.1-3.9)
  • Handle API errors gracefully: timeouts, invalid CVEs, rate limits
  • Return dict with exists, score, severity, description keys
• Add NVD_API_KEY setting to blt/settings.py (optional, for higher rate limits)
• Use synchronous requests (matches codebase pattern from GitHub API integration)
• Add retry logic with exponential backoff for transient failures

Task 2: Extend Pull Request Webhook Handler

Modify the existing PR webhook handler to detect CVE references and create security contribution records.

• Update handle_pull_request_event() in website/views/user.py:
  • After GitHubIssue update/creation, check if action == 'closed' and merged == True
  • Call extract_cve_ids() on PR title + body text
  • For each CVE ID found:
    • Validate with NVDService.validate_cve()
    • If valid, create GitHubSecurityContribution record with status='pending'
    • Link to GitHubIssue, Contributor, Repo
    • Store CVE score and severity from NVD response
  • Skip if CVE already tracked for this GitHubIssue (prevent duplicates)
• Maintain existing PR processing logic (badges, merged_at tracking)

Task 3: Implement Rate Limiting & Pre-Screening

Add fraud prevention mechanisms using Django cache to prevent spam and abuse.

• Create website/services/security_screening.py with screening functions:
  • check_rate_limit(contributor_id): Use Django cache key security_contrib:{contributor_id}:{month} with counter
  • Allow max 5 contributions per contributor per month
  • check_duplicate_submission(github_issue_id, cve_id): Query GitHubSecurityContribution for existing record
  • Return validation result with rejection reason if applicable
• Update handle_pull_request_event() to call screening functions before creating contribution
• If rate limit exceeded or duplicate found, log warning but continue normal PR processing (fail gracefully)
• Cache keys expire at end of month (timedelta to next month)

🤖 Prompt for AI agents

Connect CVE detection to GitHub webhook flow and validate against NVD database.

Create website/services/cve_service.py with NVDService class:
- validate_cve(cve_id): call NVD API using nvdlib.searchCVE(cveId=cve_id)
- get_cve_score(cve_data): extract CVSS baseScore from NVD response
- calculate_severity(score): map to CRITICAL (9.0-10.0), HIGH (7.0-8.9), MEDIUM
(4.0-6.9), LOW (0.1-3.9)
- Handle API errors gracefully (timeouts, invalid CVEs, rate limits)
- Return dict with exists, score, severity, description keys
- Add retry logic with exponential backoff
- Add NVD_API_KEY to blt/settings.py

Extend handle_pull_request_event() in website/views/user.py:
- After GitHubIssue update, check if action=='closed' and merged==True
- Call extract_cve_ids() on PR title and body
- For each CVE: validate with NVDService, create GitHubSecurityContribution with
status='pending'
- Link to GitHubIssue, Contributor, Repo; store CVE score and severity
- Skip duplicates, maintain existing PR processing logic

Create website/services/security_screening.py:
- check_rate_limit(contributor_id): Django cache key
security_contrib:{contributor_id}:{month}, max 5/month
- check_duplicate_submission(github_issue_id, cve_id): query existing records
- Call screening before creating contributions in webhook handler
- Fail gracefully: log warnings but continue normal PR processing
- Cache keys expire end of month

Phase 3: Verification Workflow

This phase builds the maintainer-facing verification interface that validates security contributions before any rewards are distributed, establishing the trust boundary for the gamification system.

Task 1: Create Verification View & Dashboard

Build the verification interface following existing admin view patterns in website/views/user.py.

• Create website/views/security.py with SecurityContributionVerificationView:
  • Class-based view extending Django ListView
  • Filter to verification_status='pending' by default
  • Add filters for severity, repo, date range
  • Check request.user.userprofile.is_verifier permission
  • Return 403 if user lacks verification permissions
  • Paginate results (20 per page)
  • Include CVE details, PR link, contributor history in context
• Add verification action endpoints:
  • SecurityContributionVerifyView (POST): Update status to 'verified', set verifier, timestamp
  • SecurityContributionRejectView (POST): Update status to 'rejected', set verifier, timestamp
  • Include CSRF protection and permission checks
• Add URL routes in blt/urls.py under /security/ namespace

Task 2: Build Verification Dashboard Template

Create the UI for maintainer verification following existing BLT Tailwind patterns.

• Create website/templates/security/verification_dashboard.html:
  • Extend existing base template for consistent layout
  • Use Tailwind CSS classes matching brand color #e74c3c
  • Support dark mode (existing pattern from PRs Improve accessibility: Added ARIA labels to icon-only buttons and enhance keyboard navigation #4937, fix: Add dark mode support to organization dashboard pages #5169)
  • Display table with columns: CVE ID, Severity Badge, PR Link, Contributor, Actions
  • Each row shows: Verify button, Reject button, View Details modal trigger
  • Add severity color coding: Critical (red), High (orange), Medium (yellow), Low (green)
  • Include ARIA labels for accessibility
• Create detail modal showing:
  • Full CVE information from NVD (description, score, published date)
  • PR diff link (GitHub)
  • Contributor's previous security contributions
  • Verification notes textarea
• Add AJAX submission for verify/reject actions using existing patterns from website/static/js/

Task 3: Add Verification Permission Management

Leverage existing UserProfile.is_verifier field and extend admin interface for permission management.

• Update website/admin.py to add is_verifier to UserProfile admin fieldsets
• Make field editable in Django admin (currently display-only)
• Add staff action to bulk grant/revoke verifier permissions
• No model changes needed (field already exists)

🤖 Prompt for AI agents

Build maintainer verification interface to validate security contributions
before reward distribution.

Create website/views/security.py with verification views:
- SecurityContributionVerificationView: ListView filtering
verification_status='pending'
- Check request.user.userprofile.is_verifier permission, return 403 if lacking
- Add filters for severity, repo, date range; paginate 20 per page
- Include CVE details, PR link, contributor history in context
- SecurityContributionVerifyView (POST): update status to 'verified', set
verifier and timestamp
- SecurityContributionRejectView (POST): update status to 'rejected', set
verifier and timestamp
- Include CSRF protection and permission checks
- Add URL routes under /security/ namespace in blt/urls.py

Create website/templates/security/verification_dashboard.html:
- Extend base template, use Tailwind CSS with brand color #e74c3c
- Support dark mode (patterns from PRs #4937, #5169)
- Table columns: CVE ID, Severity Badge, PR Link, Contributor, Actions
- Severity color coding: Critical (red), High (orange), Medium (yellow), Low
(green)
- Verify/Reject buttons, View Details modal trigger
- Detail modal: CVE info from NVD, PR diff link, contributor history,
verification notes textarea
- AJAX submission using existing patterns from website/static/js/
- Include ARIA labels for accessibility

Update website/admin.py:
- Add is_verifier to UserProfile admin fieldsets (make editable)
- Add staff action to bulk grant/revoke verifier permissions

Phase 4: Reward Distribution

This phase activates the gamification layer by distributing BACON tokens and badges when contributions are verified, using the existing signal-based reward infrastructure.

Task 1: Create Security Contribution Signal Handler

Extend signal patterns from website/feed_signals.py to trigger rewards on verification.

• Create website/security_signals.py with post_save signal receiver:
  • Trigger on GitHubSecurityContribution model saves
  • Check if verification_status changed to 'verified' and bacon_awarded == False
  • Calculate BACON reward based on severity:
    • Critical: 100 tokens
    • High: 75 tokens
    • Medium: 50 tokens
    • Low: 25 tokens
  • Call existing giveBacon(user, amt=reward_amount) from website/feed_signals.py
  • Set bacon_awarded=True and bacon_amount=reward_amount on contribution record
  • Extract user from contributor's linked UserProfile or GitHubIssue
• Register signal in website/__init__.py or apps.py
• Handle edge case where contributor has no linked User account (skip reward, log)

Task 2: Create Security Badge Definitions

Define security-focused badges using existing Badge model and award them via signals.

• Add badge creation management command or admin fixtures:
  • "First CVE Fix" (automatic, criteria: first verified contribution)
  • "Critical Security Expert" (automatic, criteria: 5+ critical severity fixes)
  • "Security Guardian" (automatic, criteria: 10+ verified contributions)
  • "CVE Hunter" (automatic, criteria: 25+ verified contributions)
• Extend signal handler from Task 4.1 to check badge criteria:
  • Query user's GitHubSecurityContribution count and severity breakdown
  • Use existing Badge.objects.get_or_create() pattern
  • Award via UserBadge.objects.get_or_create(user=user, badge=badge) (existing pattern)
  • Prevent duplicate awards with exists() checks
• Leverage existing notification system to alert users of new badges

Task 3: Add Bacon Tracking to Model

Ensure GitHubSecurityContribution accurately tracks reward distribution state.

• No schema migration needed (fields already defined in Task 1.2)
• Update verification views to display bacon_awarded status
• Add method has_awarded_bacon() to model for cleaner checks
• Include bacon_amount in admin list display

🤖 Prompt for AI agents

Activate gamification by distributing BACON tokens and badges on verification
using existing signal infrastructure.

Create website/security_signals.py with post_save signal receiver:
- Trigger on GitHubSecurityContribution saves
- Check if verification_status changed to 'verified' and bacon_awarded==False
- Calculate BACON: Critical (100), High (75), Medium (50), Low (25)
- Call giveBacon(user, amt=reward_amount) from website/feed_signals.py
- Set bacon_awarded=True and bacon_amount=reward_amount
- Extract user from contributor's linked UserProfile or GitHubIssue
- Handle missing User account: skip reward, log error
- Register signal in website/__init__.py or apps.py

Create badge definitions via management command or fixtures:
- "First CVE Fix" (first verified contribution)
- "Critical Security Expert" (5+ critical severity fixes)
- "Security Guardian" (10+ verified contributions)
- "CVE Hunter" (25+ verified contributions)

Extend signal handler to check badge criteria:
- Query user's GitHubSecurityContribution count and severity breakdown
- Use Badge.objects.get_or_create() and UserBadge.objects.get_or_create()
patterns
- Prevent duplicate awards with exists() checks
- Leverage existing notification system for badge alerts

Update GitHubSecurityContribution model:
- Add has_awarded_bacon() method
- Update verification views to display bacon_awarded status
- Include bacon_amount in admin list display

Phase 5: Leaderboards & Dashboards

This phase surfaces security contributions through leaderboards and dashboards, extending existing LeaderboardBase patterns to showcase impact metrics and CVE trends.

Task 1: Create Security Leaderboard View

Extend LeaderboardBase to aggregate and rank security contributions.

• Add SecurityLeaderboardView class to website/views/user.py:
  • Inherit from existing LeaderboardBase class
  • Override get_leaderboard() method to aggregate GitHubSecurityContribution
  • Calculate impact score: Sum('cve_score') * Count('id') per contributor
  • Filter by verification_status='verified' only
  • Support time-period filtering (month, year, all-time) using existing patterns
  • Group by Contributor, include user profile if linked
  • Return top 100 contributors with: rank, contributor name, GitHub URL, total contributions, total impact score, bacon earned
• Add URL route in blt/urls.py to /leaderboard/security/
• Reuse existing leaderboard serialization patterns for API endpoints

Task 2: Build Leaderboard UI Template

Create leaderboard visualization following existing template patterns.

• Create website/templates/leaderboard_security.html:
  • Extend existing leaderboard base template for consistency
  • Display ranked table with columns: Rank, Contributor, Contributions, Impact Score, BACON Earned
  • Add severity breakdown visualization (pie chart showing Critical/High/Medium/Low distribution)
  • Use Chart.js for visualizations (matches existing charting approach)
  • Include time-period filter dropdown (monthly, yearly, all-time)
  • Maintain dark mode and responsive design
• Update navigation to include "Security Leaderboard" link in existing leaderboard menu

Task 3: Create User Security Dashboard

Build individual user dashboard showing personal security contribution metrics.

• Add SecurityDashboardView to website/views/security.py:
  • Filter GitHubSecurityContribution by contributor linked to request.user
  • Aggregate: total contributions, total bacon earned, severity breakdown, verification status counts
  • Recent contributions list (last 10)
  • Time series data for CVE fixes over past 12 months
  • Badge progress tracking (e.g., "7/10 contributions to Security Guardian badge")
• Create website/templates/security/dashboard.html:
  • Stats cards showing totals with icons
  • Line chart for contribution timeline using Chart.js
  • Bar chart for severity distribution
  • Verification status indicators (pending/verified/rejected badges)
  • Recent contributions table with CVE links
  • Badges earned section
• Add route to /security/dashboard/ in blt/urls.py
• Link dashboard from user profile page

Task 4: Add Security Analytics View

Create admin-facing analytics view for platform-wide security metrics.

• Add SecurityAnalyticsView to website/views/security.py:
  • Require staff or verifier permissions
  • Aggregate platform-wide statistics:
    • Total CVEs fixed per month (time series)
    • Top repositories by security contributions
    • Top contributors by impact
    • Average verification time
    • Rejection rate by severity
  • Use Django ORM aggregation with Count, Sum, Avg
• Create website/templates/security/analytics.html:
  • Dashboard layout with multiple charts
  • Trend line for CVE fixes over time
  • Top 10 repositories bar chart
  • Verification funnel visualization (pending → verified/rejected)
  • Use Chart.js for all visualizations
• Add route to /security/analytics/ for staff users

🤖 Prompt for AI agents

Surface security contributions through leaderboards and dashboards extending
LeaderboardBase patterns.

Create SecurityLeaderboardView in website/views/user.py:
- Inherit from LeaderboardBase
- Override get_leaderboard() to aggregate GitHubSecurityContribution
- Calculate impact score: Sum('cve_score') * Count('id') per contributor
- Filter verification_status='verified' only
- Support time-period filtering (month, year, all-time)
- Group by Contributor, include user profile if linked
- Return top 100: rank, name, GitHub URL, contributions, impact score, bacon
earned
- Add route /leaderboard/security/ in blt/urls.py
- Reuse existing serialization patterns for API endpoints

Create website/templates/leaderboard_security.html:
- Extend leaderboard base template
- Table columns: Rank, Contributor, Contributions, Impact Score, BACON Earned
- Pie chart for severity breakdown (Critical/High/Medium/Low) using Chart.js
- Time-period filter dropdown (monthly, yearly, all-time)
- Dark mode and responsive design
- Update navigation to include Security Leaderboard link

Create SecurityDashboardView in website/views/security.py:
- Filter GitHubSecurityContribution by contributor linked to request.user
- Aggregate: total contributions, bacon earned, severity breakdown, verification
status counts
- Recent contributions (last 10), time series (12 months)
- Badge progress tracking

Create website/templates/security/dashboard.html:
- Stats cards with totals and icons
- Line chart for contribution timeline (Chart.js)
- Bar chart for severity distribution
- Verification status indicators (pending/verified/rejected badges)
- Recent contributions table with CVE links, badges earned section
- Add route /security/dashboard/ in blt/urls.py
- Link from user profile page

Create SecurityAnalyticsView in website/views/security.py:
- Require staff or verifier permissions
- Aggregate: CVEs fixed per month, top repos, top contributors, avg verification
time, rejection rate by severity
- Use Django ORM Count, Sum, Avg

Create website/templates/security/analytics.html:
- Dashboard layout with multiple Chart.js visualizations
- Trend line for CVE fixes, top 10 repos bar chart
- Verification funnel (pending → verified/rejected)
- Add route /security/analytics/ for staff users

Phase 6: Challenge Integration & Comprehensive Testing

This phase completes the gamification loop by extending the daily challenge system and ensures system reliability through comprehensive testing of fraud scenarios and end-to-end workflows.

Task 1: Extend Challenge System for Security Contributions

Add security-focused challenge types to existing Challenge model and tracking.

• Update website/challenge_signals.py to add security challenge handlers:
  • Import GitHubSecurityContribution model
  • Add challenge type definitions: "Fix a Medium+ CVE", "Complete 3 security reviews", "Fix 5 CVEs this month"
  • Extend update_challenge_progress() calls:
    • On GitHubSecurityContribution post_save (when verified), call with model_class=GitHubSecurityContribution
    • Filter by severity threshold for challenge criteria
    • Support both single and team challenge types
• Create challenge definitions via admin or fixtures:
  • Daily: "Submit 1 security PR" (50 BACON reward)
  • Weekly: "Fix a Medium+ CVE" (100 BACON reward)
  • Monthly: "Earn Security Guardian badge" (200 BACON reward)
• No model schema changes needed (Challenge model supports generic model tracking)

Task 2: Add Webhook Tests for CVE Detection

Extend existing webhook test suite with CVE-specific scenarios.

• Create test cases in website/tests/test_github_webhook.py or new test_security_webhooks.py:
  • Test CVE pattern extraction from PR body, title, commits
  • Test NVD API validation (mock nvdlib responses)
  • Test rate limiting enforcement (5/month limit)
  • Test duplicate submission blocking
  • Test security contribution creation on PR merge
  • Use existing helper functions for HMAC signature generation
• Mock external NVD API calls using unittest.mock or responses library
• Assert GitHubSecurityContribution records created with correct fields
• Test webhook continues to work when NVD API is unavailable (graceful degradation)

Task 3: Create Fraud Prevention Test Suite

Validate security measures against abuse scenarios.

• Add fraud test cases to website/tests/ directory:
  • Fake CVE Test: Submit PR with invalid CVE ID (CVE-9999-99999), verify it's marked as 'UNKNOWN' severity or rejected
  • Duplicate Submission Test: Submit same CVE ID twice for same PR, verify second attempt is blocked
  • Rate Limit Test: Create 6 contributions in one month for same contributor, verify 6th is rejected
  • Trivial PR Test: Verify maintainer can reject contributions claiming CVE credit for documentation-only PRs
  • Spam History Test: Contributors with high rejection rate are flagged in verification dashboard
• Test verification workflow:
  • Only verifiers can access verification views (test permission checks)
  • Bacon only awarded after verification (test signal doesn't trigger on 'pending' status)
  • Rejected contributions don't award rewards
• Test audit trail: verifier, timestamp, status transitions are recorded

Task 4: Integration and Documentation

Complete end-to-end testing and create operational documentation.

• End-to-end test scenarios:
  • Full workflow from PR merge → CVE detection → NVD validation → verification → BACON award → leaderboard update
  • Challenge completion when user reaches threshold (e.g., 5 CVEs fixed)
  • Badge awarding on milestone achievements
• Update documentation:
  • Create docs/security_contributions.md (or similar) with:
    • Maintainer guide: How to verify contributions, what to look for, rejection criteria
    • Contributor guide: How CVE detection works, post-disclosure scope, how to claim credit properly
    • Admin guide: Setting up verifier permissions, monitoring fraud attempts
  • Update API documentation if REST endpoints are added
  • Add inline code comments for CVE detection logic and NVD validation
• Performance testing:
  • Measure webhook response time with NVD API call (target <2 seconds)
  • Test leaderboard query performance with 10,000+ contributions
  • Verify Django cache hit rates for rate limiting
• Security audit checklist:
  • HMAC signature validation remains intact
  • No SQL injection vectors in filtering/aggregation
  • NVD API responses are sanitized before storage
  • Verification permissions properly enforced
  • CSRF protection on all POST endpoints

🤖 Prompt for AI agents

Complete gamification loop with challenge integration and comprehensive testing
of fraud scenarios and workflows.

Extend challenge system in website/challenge_signals.py:
- Import GitHubSecurityContribution model
- Add challenge types: "Fix a Medium+ CVE", "Complete 3 security reviews", "Fix
5 CVEs this month"
- Extend update_challenge_progress() calls on GitHubSecurityContribution
post_save (when verified)
- Filter by severity threshold for challenge criteria
- Support single and team challenge types
- Create challenge definitions via admin/fixtures: Daily ("Submit 1 security
PR", 50 BACON), Weekly ("Fix a Medium+ CVE", 100 BACON), Monthly ("Earn Security
Guardian badge", 200 BACON)

Create webhook tests in website/tests/test_github_webhook.py or
test_security_webhooks.py:
- Test CVE pattern extraction from PR body, title, commits
- Test NVD API validation (mock nvdlib responses)
- Test rate limiting (5/month), duplicate submission blocking
- Test security contribution creation on PR merge
- Use existing HMAC signature helpers
- Mock external NVD API calls (unittest.mock or responses library)
- Assert GitHubSecurityContribution records created correctly
- Test graceful degradation when NVD API unavailable

Create fraud prevention test suite in website/tests/:
- Fake CVE test (CVE-9999-99999): verify UNKNOWN severity or rejection
- Duplicate submission test: verify second attempt blocked
- Rate limit test: 6 contributions in month, verify 6th rejected
- Trivial PR test: maintainer can reject documentation-only PRs
- Spam history test: high rejection rate flagged in dashboard
- Verification workflow tests: permission checks, bacon only after verification,
rejected contributions no rewards
- Audit trail tests: verifier, timestamp, status transitions recorded

End-to-end testing and documentation:
- Full workflow test: PR merge → CVE detection → NVD validation → verification →
BACON award → leaderboard update
- Challenge completion test (5 CVEs fixed threshold)
- Badge awarding on milestones
- Create docs/security_contributions.md: maintainer guide (verification,
rejection criteria), contributor guide (CVE detection, post-disclosure scope,
credit claiming), admin guide (verifier permissions, fraud monitoring)
- Update API documentation if REST endpoints added
- Add inline comments for CVE detection and NVD validation
- Performance testing: webhook response time (<2 seconds), leaderboard query
(10,000+ contributions), cache hit rates
- Security audit: HMAC validation, SQL injection prevention, NVD response
sanitization, verification permissions, CSRF protection

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Establish data model and CVE detection foundation for tracking security
contributions.

Migrate Issue.cve_score to support full CVSS range (0.0-10.0) by changing
max_digits from 2 to 3

Create GitHubSecurityContribution model in website/models.py with:
- Foreign keys to GitHubIssue, GitHubReview, Contributor, Repo, and User
(verifier)
- CVE tracking fields: cve_id, cve_score, severity (choices:
CRITICAL/HIGH/MEDIUM/LOW/UNKNOWN)
- Verification workflow fields: verification_status (choices:
pending/verified/rejected/disputed), verifier, verified_at
- Reward tracking fields: bacon_awarded (Boolean), bacon_amount (Integer)
- Timestamps: created_at, updated_at
- Methods: get_display_severity(), is_verified(), can_award_bacon(), __str__()
- Register in admin with filters for status, severity, repo

Add CVE detection utilities to website/utils.py:
- extract_cve_ids(text): regex pattern CVE-\d{4}-\d{4,7} to find all CVE IDs
- is_valid_cve_format(cve_id): validate CVE ID format
- deduplicate_cve_ids(cve_list): return unique CVE IDs
- Handle malformed IDs, duplicates, case sensitivity
===============================================================================

Task: 2

Connect CVE detection to GitHub webhook flow and validate against NVD database.

Create website/services/cve_service.py with NVDService class:
- validate_cve(cve_id): call NVD API using nvdlib.searchCVE(cveId=cve_id)
- get_cve_score(cve_data): extract CVSS baseScore from NVD response
- calculate_severity(score): map to CRITICAL (9.0-10.0), HIGH (7.0-8.9), MEDIUM
(4.0-6.9), LOW (0.1-3.9)
- Handle API errors gracefully (timeouts, invalid CVEs, rate limits)
- Return dict with exists, score, severity, description keys
- Add retry logic with exponential backoff
- Add NVD_API_KEY to blt/settings.py

Extend handle_pull_request_event() in website/views/user.py:
- After GitHubIssue update, check if action=='closed' and merged==True
- Call extract_cve_ids() on PR title and body
- For each CVE: validate with NVDService, create GitHubSecurityContribution with
status='pending'
- Link to GitHubIssue, Contributor, Repo; store CVE score and severity
- Skip duplicates, maintain existing PR processing logic

Create website/services/security_screening.py:
- check_rate_limit(contributor_id): Django cache key
security_contrib:{contributor_id}:{month}, max 5/month
- check_duplicate_submission(github_issue_id, cve_id): query existing records
- Call screening before creating contributions in webhook handler
- Fail gracefully: log warnings but continue normal PR processing
- Cache keys expire end of month
===============================================================================

Task: 3

Build maintainer verification interface to validate security contributions
before reward distribution.

Create website/views/security.py with verification views:
- SecurityContributionVerificationView: ListView filtering
verification_status='pending'
- Check request.user.userprofile.is_verifier permission, return 403 if lacking
- Add filters for severity, repo, date range; paginate 20 per page
- Include CVE details, PR link, contributor history in context
- SecurityContributionVerifyView (POST): update status to 'verified', set
verifier and timestamp
- SecurityContributionRejectView (POST): update status to 'rejected', set
verifier and timestamp
- Include CSRF protection and permission checks
- Add URL routes under /security/ namespace in blt/urls.py

Create website/templates/security/verification_dashboard.html:
- Extend base template, use Tailwind CSS with brand color #e74c3c
- Support dark mode (patterns from PRs #4937, #5169)
- Table columns: CVE ID, Severity Badge, PR Link, Contributor, Actions
- Severity color coding: Critical (red), High (orange), Medium (yellow), Low
(green)
- Verify/Reject buttons, View Details modal trigger
- Detail modal: CVE info from NVD, PR diff link, contributor history,
verification notes textarea
- AJAX submission using existing patterns from website/static/js/
- Include ARIA labels for accessibility

Update website/admin.py:
- Add is_verifier to UserProfile admin fieldsets (make editable)
- Add staff action to bulk grant/revoke verifier permissions
===============================================================================

Task: 4

Activate gamification by distributing BACON tokens and badges on verification
using existing signal infrastructure.

Create website/security_signals.py with post_save signal receiver:
- Trigger on GitHubSecurityContribution saves
- Check if verification_status changed to 'verified' and bacon_awarded==False
- Calculate BACON: Critical (100), High (75), Medium (50), Low (25)
- Call giveBacon(user, amt=reward_amount) from website/feed_signals.py
- Set bacon_awarded=True and bacon_amount=reward_amount
- Extract user from contributor's linked UserProfile or GitHubIssue
- Handle missing User account: skip reward, log error
- Register signal in website/__init__.py or apps.py

Create badge definitions via management command or fixtures:
- "First CVE Fix" (first verified contribution)
- "Critical Security Expert" (5+ critical severity fixes)
- "Security Guardian" (10+ verified contributions)
- "CVE Hunter" (25+ verified contributions)

Extend signal handler to check badge criteria:
- Query user's GitHubSecurityContribution count and severity breakdown
- Use Badge.objects.get_or_create() and UserBadge.objects.get_or_create()
patterns
- Prevent duplicate awards with exists() checks
- Leverage existing notification system for badge alerts

Update GitHubSecurityContribution model:
- Add has_awarded_bacon() method
- Update verification views to display bacon_awarded status
- Include bacon_amount in admin list display
===============================================================================

Task: 5

Surface security contributions through leaderboards and dashboards extending
LeaderboardBase patterns.

Create SecurityLeaderboardView in website/views/user.py:
- Inherit from LeaderboardBase
- Override get_leaderboard() to aggregate GitHubSecurityContribution
- Calculate impact score: Sum('cve_score') * Count('id') per contributor
- Filter verification_status='verified' only
- Support time-period filtering (month, year, all-time)
- Group by Contributor, include user profile if linked
- Return top 100: rank, name, GitHub URL, contributions, impact score, bacon
earned
- Add route /leaderboard/security/ in blt/urls.py
- Reuse existing serialization patterns for API endpoints

Create website/templates/leaderboard_security.html:
- Extend leaderboard base template
- Table columns: Rank, Contributor, Contributions, Impact Score, BACON Earned
- Pie chart for severity breakdown (Critical/High/Medium/Low) using Chart.js
- Time-period filter dropdown (monthly, yearly, all-time)
- Dark mode and responsive design
- Update navigation to include Security Leaderboard link

Create SecurityDashboardView in website/views/security.py:
- Filter GitHubSecurityContribution by contributor linked to request.user
- Aggregate: total contributions, bacon earned, severity breakdown, verification
status counts
- Recent contributions (last 10), time series (12 months)
- Badge progress tracking

Create website/templates/security/dashboard.html:
- Stats cards with totals and icons
- Line chart for contribution timeline (Chart.js)
- Bar chart for severity distribution
- Verification status indicators (pending/verified/rejected badges)
- Recent contributions table with CVE links, badges earned section
- Add route /security/dashboard/ in blt/urls.py
- Link from user profile page

Create SecurityAnalyticsView in website/views/security.py:
- Require staff or verifier permissions
- Aggregate: CVEs fixed per month, top repos, top contributors, avg verification
time, rejection rate by severity
- Use Django ORM Count, Sum, Avg

Create website/templates/security/analytics.html:
- Dashboard layout with multiple Chart.js visualizations
- Trend line for CVE fixes, top 10 repos bar chart
- Verification funnel (pending → verified/rejected)
- Add route /security/analytics/ for staff users
===============================================================================

Task: 6

Complete gamification loop with challenge integration and comprehensive testing
of fraud scenarios and workflows.

Extend challenge system in website/challenge_signals.py:
- Import GitHubSecurityContribution model
- Add challenge types: "Fix a Medium+ CVE", "Complete 3 security reviews", "Fix
5 CVEs this month"
- Extend update_challenge_progress() calls on GitHubSecurityContribution
post_save (when verified)
- Filter by severity threshold for challenge criteria
- Support single and team challenge types
- Create challenge definitions via admin/fixtures: Daily ("Submit 1 security
PR", 50 BACON), Weekly ("Fix a Medium+ CVE", 100 BACON), Monthly ("Earn Security
Guardian badge", 200 BACON)

Create webhook tests in website/tests/test_github_webhook.py or
test_security_webhooks.py:
- Test CVE pattern extraction from PR body, title, commits
- Test NVD API validation (mock nvdlib responses)
- Test rate limiting (5/month), duplicate submission blocking
- Test security contribution creation on PR merge
- Use existing HMAC signature helpers
- Mock external NVD API calls (unittest.mock or responses library)
- Assert GitHubSecurityContribution records created correctly
- Test graceful degradation when NVD API unavailable

Create fraud prevention test suite in website/tests/:
- Fake CVE test (CVE-9999-99999): verify UNKNOWN severity or rejection
- Duplicate submission test: verify second attempt blocked
- Rate limit test: 6 contributions in month, verify 6th rejected
- Trivial PR test: maintainer can reject documentation-only PRs
- Spam history test: high rejection rate flagged in dashboard
- Verification workflow tests: permission checks, bacon only after verification,
rejected contributions no rewards
- Audit trail tests: verifier, timestamp, status transitions recorded

End-to-end testing and documentation:
- Full workflow test: PR merge → CVE detection → NVD validation → verification →
BACON award → leaderboard update
- Challenge completion test (5 CVEs fixed threshold)
- Badge awarding on milestones
- Create docs/security_contributions.md: maintainer guide (verification,
rejection criteria), contributor guide (CVE detection, post-disclosure scope,
credit claiming), admin guide (verifier permissions, fraud monitoring)
- Update API documentation if REST endpoints added
- Add inline comments for CVE detection and NVD validation
- Performance testing: webhook response time (<2 seconds), leaderboard query
(10,000+ contributions), cache hit rates
- Security audit: HMAC validation, SQL injection prevention, NVD response
sanitization, verification permissions, CSRF protection

💡 Iterate on the plan with: @coderabbitai <feedback>

Example Feedback
- @coderabbitai You can skip phase 3. Add a simple unit test case for phase 2.
- @coderabbitai For assumption 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash

# Check GitHub webhook handler to understand repo registration requirements
echo "=== GitHub Webhook Handler ==="
rg -n "github_webhook" -A 10 -B 5 --type=py website/views/user.py | head -100

echo -e "\n=== Repo Model Definition ==="
rg -n "class Repo" -A 30 --type=py website/models.py

echo -e "\n=== Contributor Model and User Linking ==="
rg -n "class Contributor" -A 30 --type=py website/models.py

echo -e "\n=== GitHubIssue Model (PR tracking) ==="
rg -n "class GitHubIssue" -A 40 --type=py website/models.py

echo -e "\n=== BACON Award Logic ==="
rg -n "def giveBacon" -A 20 --type=py website/

echo -e "\n=== Webhook Registration/Setup ==="
rg -n "webhook.*secret\|GITHUB_WEBHOOK" --type=py blt/settings.py website/

Length of output: 8117

---

🏁 Script executed:

#!/bin/bash

# Check how GitHubIssue links contributor to user for BACON
echo "=== How Contributors link to Users ==="
rg -n "user_profile.*contributor|contributor.*user" -C 5 --type=py website/models.py | head -80

echo -e "\n=== Webhook event handling for PRs ==="
rg -n "handle_pull_request_event" -A 50 --type=py website/views/user.py | head -100

echo -e "\n=== How repos are registered/created ==="
rg -n "Repo.objects.create|Repo.objects.get_or_create" -C 3 --type=py website/ | head -80

echo -e "\n=== Check if UserProfile links to GitHub ==="
rg -n "class UserProfile" -A 40 --type=py website/models.py | head -60

echo -e "\n=== NVD API usage in codebase (if any) ==="
rg -n "nvd|NVD" --type=py website/

Length of output: 11958

---

@Pritz395 Great questions! Let me clarify the registration requirements and address the NVD API misunderstanding:

Registration Requirements

For Contributors (Users):

• ✅ Must be signed up with BLT to receive BACON rewards
• The system works like this:
  1. Contributor records are created automatically from GitHub webhook data (github_id, github_url, avatar)
  2. BACON is only awarded if the Contributor can be matched to a BLT User via UserProfile.github_url
  3. If no User match exists, contribution is tracked but no BACON awarded

For Organizations/Repos:

• ❌ Do NOT need to be "registered" in advance
• Repo records are created dynamically via get_or_create() when webhooks fire
• However, the webhook must be configured on the GitHub repository pointing to BLT's endpoint

Critical Clarification: NVD API vs GitHub API

NVD API provides:

• CVE validation (does CVE-2024-12345 exist?)
• CVSS severity scores (9.8 = Critical)
• CVE descriptions and publication dates
• Does NOT provide: PR data, diffs, commits, or any GitHub information

GitHub Webhooks/API provide:

• PR content (title, body, diffs)
• Contributor information
• Merge status and timestamps
• All the actual code contribution data

In the current BLT codebase, you can see the NVD API is only used for CVE lookup (website/models.py line 677), not for tracking contributions.

Future-Proofing: Tracking Unregistered Organizations

Current Limitation:
To track contributions from ANY repository, that repo must have:

1. GitHub webhook configured pointing to https://blt-instance/github-webhook/
2. Webhook secret matching BLT's GITHUB_WEBHOOK_SECRET
3. This requires repository admin access

For Your Proposal:
This doesn't require fundamental changes, but you should clarify:

• Post-disclosure CVE tracking works for any repo WITH webhooks configured
• Contributors from unregistered orgs can still earn BACON if they have BLT accounts
• The limitation is webhook setup, not "organization registration"

Alternative Approach (Not in Current Proposal):
To truly help secure projects without their active participation, you'd need:

• Periodic GitHub API polling (instead of webhooks)
• Search for merged PRs with CVE references across all public repos
• This would require significant infrastructure changes and API rate limit management

Recommendation

Your current proposal is solid and doesn't need fundamental changes. I'd suggest:

1. Update the "Scope & Limitations" section to clarify webhook requirements
2. Remove mentions of "NVD API pulling diff files" (that's GitHub's job)
3. Add a note that repos need webhook configuration to be tracked
4. Consider a "Phase 2" for webhook-less tracking via GitHub API polling

Would you like me to help update those sections of your proposal?

[Pritz395]

@coderabbitai so basically if we want to future proof it so that even unregistered orgs with blt can benefit from security work how would we do that and is that within the current project scope?

[coderabbitai]

🧩 Analysis chain

🌐 Web query:

GitHub API rate limits for searching pull requests and commits

💡 Result:

Short answer:

• GitHub Search API (including searching commits, issues/PRs, code, repos, users) uses a custom limit: authenticated requests — 30 requests per minute; unauthenticated — 10 requests per minute. [1][2]

Notes / related limits:

• Most other REST endpoints use the standard limit: authenticated ≈ 5,000 requests/hour (unauthenticated 60/hour). Search requests do not count against that core quota. [1][3]
• GraphQL has a separate, cost-based rate system (different from both core and Search). Check the GraphQL docs if you use it. [1]

If you want links to the exact docs or how to check your current remaining quota via the Rate Limit API, say so.

Sources: [1] GitHub REST rate-limit docs, [2] GitHub Search API docs (search rate limit), [3] standard REST rate-limit summary.

---

@Pritz395 Great question! Let me break down what future-proofing for unregistered orgs would require and whether it fits your GSoC scope.

Polling Architecture for Unregistered Orgs

To track CVE contributions without webhooks, you'd need:

New Components Required

1. Scheduled Search Task (Django management command or Celery task)

   • Periodically search GitHub for merged PRs with CVE references
   • Query: is:pr is:merged "CVE-" in:title,body,comments
   • Filter by date range to only process recent merges

2. Rate Limit Management

   • GitHub Search API allows 30 requests/minute for authenticated requests
   • That's 43,200 searches per day - sufficient for comprehensive scanning
   • Implement backoff and queue system to stay within limits

3. Deduplication System

   • Track processed PR IDs to avoid reprocessing
   • Store last scan timestamp per repository
   • Handle edge cases where same PR appears in multiple searches

4. Repository Discovery

   • Start with curated list of popular security-critical repos
   • Optionally expand to trending repos or user-submitted targets
   • Store repo metadata for prioritization

5. Data Reconciliation

   • Merge webhook-tracked and search-tracked contributions
   • Prioritize webhook data (real-time) over search data (delayed)
   • Handle conflicts where both sources exist

Architecture Changes

# New files needed:
website/management/commands/scan_github_cve_contributions.py  # Search task
website/services/github_search_service.py  # Search API wrapper
website/models.py  # Add ScanLog model for tracking

# Modified files:
blt/settings.py  # Add GITHUB_SEARCH_ENABLED, SCAN_INTERVAL configs
website/services/security_screening.py  # Extend duplicate detection

Estimated Additional Effort

Component	Hours
GitHub Search API integration	12-15h
Rate limit management	8-10h
Deduplication logic	10-12h
Repository discovery system	8-10h
Data reconciliation	12-15h
Testing & edge cases	10-12h
Documentation	5-8h
Total	65-82h

Scope Recommendation

Option 1: Keep Current Scope (Recommended for GSoC)

Total: 350-370 hours

• Focus on webhook-based tracking (reliable, real-time)
• Build solid foundation: verification, rewards, leaderboards, fraud prevention
• Document webhook setup process clearly
• Rationale: Better to deliver a polished, production-ready core system than add experimental polling

Option 2: Add as Optional Milestone 9 (Stretch Goal)

Total: 415-452 hours

• Complete Milestones 1-8 first
• If ahead of schedule, implement basic polling
• Deliver whatever subset is complete (search task + basic dedup minimum)
• Rationale: Shows ambition but doesn't risk core deliverables

Option 3: Position as Phase 2 / Future Work

Total: 350-370 hours for GSoC

• Mention polling in proposal as "Future Enhancements"
• Explain architectural approach but don't commit to implementation
• Potential follow-up project or post-GSoC contribution
• Rationale: Sets realistic expectations, demonstrates long-term thinking

My Recommendation

Go with Option 1 or 3 for your GSoC proposal:

1. In your "Scope & Limitations" section, add:

   Current Approach: Webhook-based tracking (requires repository owner to configure webhook)

   Future Enhancement (Post-GSoC): GitHub Search API polling to discover CVE contributions across all public repositories without webhook configuration. This would require rate limit management, scheduled tasks, and deduplication logic (estimated 65-80 additional hours).

2. In your proposal narrative, frame it positively:

   "The webhook-based approach ensures real-time, reliable tracking for participating projects. This aligns with BLT's existing GitHub integration architecture and guarantees data accuracy. Future iterations could expand to polling-based discovery for broader ecosystem visibility."

3. Benefits of webhook-first approach:

   • ✅ Real-time tracking (no polling delay)
   • ✅ Complete data (all PR events, not just merged)
   • ✅ Reliable (no rate limits to manage)
   • ✅ Matches existing BLT patterns
   • ✅ Maintainer buy-in (webhook = intentional participation)

Reality Check

GSoC typically expects ~350 hours over 12 weeks. Your current 8-milestone plan is perfectly scoped. Adding polling would:

• Push you to 415-450 hours (risky)
• Introduce complexity that could derail core features
• Require significant testing/edge case handling

Evaluators prefer: "Delivered polished core system with excellent docs" over "Attempted everything, completed 70%"

Would you like me to help you draft the updated "Scope & Limitations" and "Future Enhancements" sections to properly position this?

[Pritz395]

@coderabbitai so how would we actually verify if the CVE number being tracked is legit and is a valid CVE related thing

[coderabbitai]

@Pritz395 Great question! CVE validation is crucial for preventing fraud. Your proposal already includes a robust multi-layer validation approach:

Layer 1: Format Validation (Instant)

First, check if the CVE ID matches the official format using regex:

# From your proposal's CVE detection utility
pattern = r'CVE-\d{4}-\d{4,7}'

Valid examples:

• CVE-2024-12345 ✅
• CVE-2023-0001 ✅
• CVE-2025-1234567 ✅ (7-digit for high-volume years)

Invalid examples:

• CVE-2024-123 ❌ (too few digits)
• CVE-24-12345 ❌ (wrong year format)
• CVE-2024-ABCD ❌ (letters not allowed)

This catches typos and obvious fakes immediately.

---

Layer 2: NVD API Validation (1-2 seconds)

Your proposal uses nvdlib to query NIST's official National Vulnerability Database:

# From Phase 2, Task 1 of your proposal
from nvdlib import searchCVE

def validate_cve(cve_id):
    try:
        # Query official NIST database
        result = searchCVE(cveId=cve_id)
        if result:
            return {
                'exists': True,
                'score': result.v3score,  # CVSS score (0.0-10.0)
                'severity': calculate_severity(result.v3score),
                'description': result.descriptions[0].value,
                'published': result.published
            }
    except Exception:
        return {'exists': False, 'severity': 'UNKNOWN'}

What this catches:

Scenario	NVD Response	System Action
CVE-2024-12345 (real)	✅ Returns data	Create contribution with severity from NVD
CVE-9999-99999 (fake)	❌ Not found	Mark as 'UNKNOWN' severity, flag for review
CVE-2024-00001 (reserved)	⚠️ Exists but no score	Mark as 'UNKNOWN', awaiting publication
CVE-2020-12345 (real but old)	✅ Returns data	Normal processing

Why NVD is authoritative:

• NIST maintains the official CVE database
• All legitimate CVEs are published there
• Includes CVSS scores calculated by security experts
• API is free (optional key for higher rate limits)

---

Layer 3: Maintainer Verification (Human Review)

Even with NVD validation, your proposal includes mandatory maintainer verification (Phase 3):

What maintainers verify:

1. Relevance: Does the PR actually fix this CVE?

   • Check if code changes address the vulnerability described in NVD
   • Reject documentation-only PRs claiming CVE credit

2. Substantive Fix: Is it a real security improvement?

   • Reject trivial changes (whitespace, typos)
   • Reject PRs just adding CVE ID to changelog

3. Contributor Intent: Is this legitimate or gaming the system?

   • Check contributor's history (spam patterns?)
   • Review PR discussion/review comments

4. CVE Association: Is the CVE reference appropriate?

   • Some PRs mention CVEs as "related work" not "fixes"
   • Verify the project maintainers acknowledge this as a fix

Verification Dashboard shows:

• CVE details from NVD (description, severity, publish date)
• Full PR diff link to review actual code changes
• Contributor's previous security contribution history
• Verification action: Verify ✅ / Reject ❌ / Dispute ⚠️

---

Edge Cases Handled

1. Reserved but Unpublished CVEs

Scenario: CVE-2024-XXXXX exists in CVE system but no details published yet
NVD Response: Exists but no CVSS score
System Action: Mark as 'UNKNOWN' severity, maintainer decides

2. Duplicate CVE Claims

Scenario: Multiple PRs claim to fix the same CVE
System Action: Pre-screening (Phase 2, Task 3) blocks duplicates
Only first claim proceeds to verification

3. Rate Limit Abuse

Scenario: Contributor submits 10 CVE claims in one month
System Action: Django cache tracks claims, blocks after 5/month
Maintainer can override for legitimate high-volume contributors

4. Documentation PRs

Scenario: PR adds CVE-2024-12345 to security advisory but no code fix
NVD Validation: ✅ CVE exists
Maintainer Verification: ❌ Rejects (no actual fix)

---

Complete Validation Flow

graph TD
    A[PR mentions CVE-2024-12345] --> B{Format Valid?}
    B -->|No| C[Ignore - Invalid Format]
    B -->|Yes| D[Query NVD API]
    D --> E{CVE Exists in NVD?}
    E -->|No| F[Mark UNKNOWN - Flag for Review]
    E -->|Yes| G[Extract Score & Description]
    G --> H[Create GitHubSecurityContribution pending]
    H --> I[Maintainer Reviews]
    I --> J{Real Fix?}
    J -->|Yes| K[Verify - Award BACON]
    J -->|No| L[Reject - No Reward]
    F --> I

Loading

---

Fraud Prevention Summary

Your proposal's defense-in-depth approach:

1. ✅ Automated filtering catches format errors and fake CVE IDs
2. ✅ NVD API validates against authoritative source
3. ✅ Rate limiting prevents spam submissions
4. ✅ Duplicate detection blocks repeated claims
5. ✅ Human verification ensures substantive contributions
6. ✅ Audit trail tracks verifier, timestamp, rejection reasons

Result: Very difficult to game the system. Even if someone gets past automated checks, maintainer verification is the final gate before any BACON is awarded.

---

Example: Real vs Fake

Legitimate Contribution:

PR: "Fix SQL injection in login endpoint (CVE-2024-12345)"
Format Check: ✅ Valid format
NVD Lookup: ✅ CVE exists, CVSS 9.8 (Critical)
Code Review: ✅ Actually patches the vulnerability
Maintainer: ✅ Verifies → Award 100 BACON

Attempted Fraud:

PR: "Add security notice for CVE-9999-99999"
Format Check: ✅ Valid format
NVD Lookup: ❌ CVE doesn't exist
System: ⚠️ Flagged as UNKNOWN
Maintainer: ❌ Rejects → No reward

Does this answer your validation concerns? The key insight is that NVD API validation + maintainer verification creates a trust boundary that's very hard to exploit.

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash

# Search for beginner-friendly labels in the repository
echo "=== Available Labels in BLT Repository ==="
gh label list --repo OWASP-BLT/BLT --limit 100 | grep -iE "good|first|beginner|easy|starter|help"

echo -e "\n=== Open Issues with 'good first issue' label ==="
gh issue list --repo OWASP-BLT/BLT --label "good first issue" --state open --limit 10 --json number,title,labels,updatedAt,comments

echo -e "\n=== Open Issues with 'help wanted' label ==="
gh issue list --repo OWASP-BLT/BLT --label "help wanted" --state open --limit 10 --json number,title,labels,updatedAt,comments

echo -e "\n=== Recently created open issues (last 30 days, simple ones) ==="
gh issue list --repo OWASP-BLT/BLT --state open --limit 20 --json number,title,labels,createdAt,updatedAt,comments | jq '.[] | select(.labels | length > 0) | {number, title, labels: [.labels[].name], createdAt, comments}'

echo -e "\n=== Check for UI/frontend issues (often beginner-friendly) ==="
gh issue list --repo OWASP-BLT/BLT --label "frontend" --state open --limit 10 --json number,title,labels,updatedAt

echo -e "\n=== Check for documentation issues ==="
gh issue list --repo OWASP-BLT/BLT --label "documentation" --state open --limit 10 --json number,title,labels,updatedAt

Length of output: 274817

---

🏁 Script executed:

#!/bin/bash
set -e

REPO="OWASP-BLT/BLT"

echo "=== All labels (top 100) ==="
gh label list --repo "$REPO" --limit 100

echo -e "\n=== Open 'good first issue' (unassigned, low comments) ==="
gh issue list --repo "$REPO" --label "good first issue" --state open --limit 30 --json number,title,assignees,comments,updatedAt,url \
  | jq '[ .[] | select((.assignees|length)==0) | select((.comments|length) <= 3) ]'

echo -e "\n=== Open 'help wanted' (unassigned, low comments) ==="
gh issue list --repo "$REPO" --label "help wanted" --state open --limit 30 --json number,title,assignees,comments,updatedAt,url \
  | jq '[ .[] | select((.assignees|length)==0) | select((.comments|length) <= 3) ]'

echo -e "\n=== Open issues in last 45 days with tiny-change keywords (unassigned) ==="
gh issue list --repo "$REPO" --state open --limit 50 --json number,title,labels,assignees,comments,updatedAt,url \
  | jq --argdate "$(date -u -d '45 days ago' +%Y-%m-%dT%H:%M:%SZ)" '
    [ .[] 
      | select((.assignees|length)==0) 
      | select(.updatedAt >= $date)
      | select(
          (.title|test("doc|readme|typo|spelling|grammar|lint|ruff|flake8|black|pep8|pre-commit|css|padding|margin|spacing|aria|accessib|a11y|alt text|contrast"; "i"))
        )
    ]'

echo -e "\n=== Candidate details (first 6 only) ==="
# Collect up to 6 candidate issue numbers from previous queries for details
CANDIDATES=$(
  {
    gh issue list --repo "$REPO" --label "good first issue" --state open --limit 30 --json number,assignees,comments | jq -r '.[] | select((.assignees|length)==0) | select((.comments|length)<=3) | .number';
    gh issue list --repo "$REPO" --label "help wanted" --state open --limit 30 --json number,assignees,comments | jq -r '.[] | select((.assignees|length)==0) | select((.comments|length)<=3) | .number';
    gh issue list --repo "$REPO" --state open --limit 50 --json number,assignees,updatedAt,title | jq -r --argdate "$(date -u -d '45 days ago' +%Y-%m-%dT%H:%M:%SZ)" '.[] | select((.assignees|length)==0) | select(.updatedAt >= $date) | select(.title|test("doc|readme|typo|spelling|grammar|lint|ruff|flake8|black|pre-commit|css|padding|margin|spacing|aria|accessib|a11y|alt text|contrast"; "i")) | .number'
  } | head -n 6 | sort -u
)
for n in $CANDIDATES; do
  echo -e "\n--- Issue #$n ---"
  gh issue view "$n" --repo "$REPO" --json number,title,body,labels,updatedAt,url
done

Length of output: 4148

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

REPO="OWASP-BLT/BLT"

echo "=== Tiny-labeled open issues (unassigned preferred) ==="
gh issue list --repo "$REPO" --state open --limit 30 \
  --search 'label:tiny is:issue state:open -label:assigned' \
  --json number,title,assignees,labels,updatedAt,url

echo -e "\n=== Good first issue (any), show assignment to gauge availability ==="
gh issue list --repo "$REPO" --state open --limit 30 \
  --search '"good first issue" in:label is:issue state:open' \
  --json number,title,assignees,labels,updatedAt,url

echo -e "\n=== Help wanted (any), prefer unassigned ==="
gh issue list --repo "$REPO" --state open --limit 30 \
  --search 'label:"help wanted" is:issue state:open -label:assigned' \
  --json number,title,assignees,labels,updatedAt,url

echo -e "\n=== Low-effort keyword scan across open issues (typo/docs/ui/a11y) ==="
gh issue list --repo "$REPO" --state open --limit 100 --json number,title,assignees,labels,updatedAt,url \
  | jq '[ .[] 
           | select((.assignees|length)==0) 
           | select(.title|test("typo|docs|documentation|readme|grammar|css|padding|margin|spacing|aria|a11y|alt text|contrast|dark mode|favicon|meta tag|sitemap|robots", "i"))
        ] | .[:8]'

Length of output: 31171

---

@Pritz395 Here’s a realistic path to a couple of quick, low‑critical merges you can do right now. I checked the BLT repo labels/open issues as of January 7, 2026; there aren’t any unassigned “tiny” or truly beginner “good first issue” tickets available, and most “good first issue/help wanted” items are large features already assigned to bots or folks. So, to help you get merges fast without opening new issues (per the repo bot’s guidance), pick from these 3–4 micro‑PRs that are safe, low‑risk, and typically get accepted quickly.

Pick 3–4 micro‑PRs (no new issue needed)

1. Accessibility: rel="noopener noreferrer" for external links

• What: Add rel="noopener noreferrer" to all anchor tags with target="_blank" across templates to prevent reverse‑tabnabbing.
• How:
  • Search: rg -n 'target="_blank"' website/templates
  • Edit each hit to include rel="noopener noreferrer"
• Scope: Only template changes; no backend impact.
• PR title: chore(a11y): add rel="noopener noreferrer" to external links
• Acceptance checks: All target="_blank" links include rel; screenshots not required.

2. Accessibility: ensure all have alt text (or alt="")

• What: Add meaningful alt="" when decorative, or alt="…" when informative.
• How:
  • Search: rg -nP '<img(?![^>]*\balt=)' website/templates
  • Update each match; keep decorative images alt="" and set role="presentation" if purely decorative.
• PR title: chore(a11y): add alt text for images in templates
• Acceptance checks: No lacking alt; visual output unchanged.

3. Keyboard a11y: add a “skip to content” link and main landmark

• What: Improve keyboard navigation with a skip link and explicit main role.
• How (base layout):
  • In website/templates/base.html, near the start of , add:
    • Skip to content
  • Ensure the main container has id="main" and role="main" (e.g., )
• PR title: chore(a11y): add skip-link and main landmark to base layout
• Acceptance checks: Tabbing from page load reveals skip link; no visual regressions.

4. Small mobile polish: consistent horizontal padding on mobile

• What: Prevent “edge‑sticking” of content on narrow screens.
• How (base layout):
  • In website/templates/base.html, ensure the main wrapper uses responsive padding:
    • …
  • If the project already added this recently, skip; otherwise it’s a one‑line fix.
• PR title: ui: add responsive horizontal padding to base layout on mobile
• Acceptance checks: Quick screenshots (375px width) before/after are nice.

Optional fifth (docs-only) if you want a zero‑risk merge

• What: Add a short “How to /assign and 24‑hour auto‑unassign” section plus pre‑commit quickstart to CONTRIBUTING.md.
• How:
  • Confirm if CONTRIBUTING.md mentions the /assign and 24h bot; if not, add a brief subsection and the exact pre‑commit commands the repo uses.
• PR title: docs: clarify /assign auto‑unassign workflow and pre‑commit quickstart

Why these work for quick merges

• They don’t change behavior or data; just a11y/UX polish and docs.
• They respect the “no new issues” guidance—open PRs directly with a clear, tight scope.
• They align with existing stack (Django + Tailwind templates).
• Easy to review and revert if needed.

Execution checklist (keeps momentum and shows professionalism)

• One PR per micro‑change. Title as above; add a one‑paragraph description and, for the UI items, a tiny before/after screenshot if visible.
• Run pre‑commit hooks locally if configured (often present in BLT).
• Add label tiny in the PR description title if permitted; otherwise just keep the scope minimal.
• Optional: mention “no issue – tiny a11y/UX polish” to acknowledge repo policy.

If you prefer to work from existing open issues

• Today’s open “good first issue/help wanted” items are mostly medium/large features and many are auto‑assigned (e.g., Enable reviewers and domain managers to verify reports. #2227, Add to company cyber dashboard: Vulnerability management #2474, Add to company cyber dashboard: news about company #2480, Build Leaderboard for Team Overview Dashboard - Introduce a leaderboard on the Team Overview Dashboard that ranks team members based on their consistency and quality of daily check-ins. #2574, Incorporate Team Goals and Achievements in Weekly Activity - Present team goals and achievements in the weekly summary, encouraging collective progress and competition among teams. #2581). These are not ideal for quick merges. I’d stick to the micro‑PRs above to introduce your mentor swiftly.

Want me to prep diffs?

• Tell me which 2–3 you want to start with and I’ll draft the exact edits (filename + minimal patch) so you can copy/paste and open PRs within an hour.

[github-actions]

Hello @coderabbitai[bot]! You've been assigned to OWASP-BLT/BLT issue #5383. You have 24 hours to complete a pull request.

---

This comment was generated by OWASP BLT-Action