Inconsistent Styling on Chrome Extension Page & The About Page (Theme & Layout Mismatch)

[Pritz395]

The Chrome Extension landing page had inconsistent styling between sections. Some areas displayed dark theme styles, while others unexpectedly switched to light backgrounds, causing noticeable visual mismatch across the hero, mid-sections, CTAs, and footer.

Additional Issue Found:
Similar theme consistency issues on the About page with the main container and benefit cards not properly supporting dark mode.

Screen Recordings:

• Initial issue demonstration (Extension page scrolling)
• Additional issue demonstration (About page)

Extension Page:

Screen.Recording.2025-11-20.at.2.35.37.PM.mov

About us Page:

Screen.Recording.2025-11-20.at.3.51.11.PM.mov

[Pritz395]

/assign

[github-actions]

Hello @Pritz395! You've been assigned to OWASP-BLT/BLT issue #4911. You have 24 hours to complete a pull request.

---

This comment was generated by OWASP BLT-Action

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash

# Search for GitHub-related models
echo "=== Searching for GitHubIssue and GitHubReview models ==="
rg -n "class GitHubIssue" -A 5
echo ""
rg -n "class GitHubReview" -A 5

echo ""
echo "=== Searching for Issue model with CVE fields ==="
rg -n "class Issue" -A 20 | grep -E "(class Issue|cve_id|cve_score)"

echo ""
echo "=== Searching for giveBacon function ==="
rg -n "def giveBacon" -A 3

echo ""
echo "=== Searching for Badge and UserBadge models ==="
rg -n "class Badge" -A 5
echo ""
rg -n "class UserBadge" -A 5

echo ""
echo "=== Searching for LeaderboardBase ==="
rg -n "class LeaderboardBase" -A 5

echo ""
echo "=== Searching for DailyChallenge model ==="
rg -n "class DailyChallenge" -A 10

echo ""
echo "=== Searching for CHALLENGE_TYPE_CHOICES ==="
rg -n "CHALLENGE_TYPE_CHOICES"

echo ""
echo "=== Searching for check_and_complete_challenges ==="
rg -n "def check_and_complete_challenges" -A 3

echo ""
echo "=== Searching for webhook handlers ==="
rg -n "def handle_review_event" -A 3
echo ""
rg -n "def handle_issue_event" -A 3

echo ""
echo "=== Searching for test_github_webhook.py ==="
fd "test_github_webhook.py"

echo ""
echo "=== Searching for feed_signals.py ==="
fd "feed_signals.py"

Length of output: 7378

---

🏁 Script executed:

#!/bin/bash

# Check Issue model for CVE-related fields
echo "=== Checking Issue model fields for CVE ==="
rg -n "class Issue\(" -A 50 website/models.py | head -60

echo ""
echo "=== Checking for cve_score field ==="
rg -n "cve_score" -C 3

echo ""
echo "=== Checking context around CHALLENGE_TYPE_CHOICES ==="
rg -n "CHALLENGE_TYPE_CHOICES" -B 10 -A 5

echo ""
echo "=== Searching for DailyChallenge or Challenge-related models ==="
rg -n "class.*Challenge.*\(models.Model\)" -A 10

echo ""
echo "=== Checking PRs #4937 and #5169 mentioned in proposal ==="
gh pr view 4937 --json title,body,state,url 2>/dev/null || echo "PR #4937 not found or error accessing"
echo ""
gh pr view 5169 --json title,body,state,url 2>/dev/null || echo "PR #5169 not found or error accessing"

echo ""
echo "=== Checking GitHubIssue model fields ==="
rg -n "class GitHubIssue\(models.Model\)" -A 30 website/models.py

echo ""
echo "=== Checking for CVE pattern in codebase ==="
rg -n "CVE-\\\\d\{4\}" -C 2 | head -20

Length of output: 22788

---

🏁 Script executed:

#!/bin/bash

# Let's search for any daily challenge related code
echo "=== Searching for daily challenge patterns ==="
rg -n -i "daily.*challenge" -C 3

echo ""
echo "=== Searching for Challenge model usage patterns ==="
rg -n "Challenge\(" -C 2 | head -40

echo ""
echo "=== Checking Issue.get_cve_score and related methods ==="
rg -n "def get_cve" -A 15 website/models.py

echo ""
echo "=== Checking for contributor field in GitHubIssue ==="
rg -n "contributor" website/models.py | grep -i github

echo ""
echo "=== Check github webhook view imports ==="
cat website/views/user.py | grep -A 5 "def.*webhook"

Length of output: 2440

---

🏁 Script executed:

#!/bin/bash

# Check for contributor field in GitHubIssue model
echo "=== Checking GitHubIssue model full definition ==="
rg -n "class GitHubIssue" -A 60 website/models.py | head -70

echo ""
echo "=== Checking if there are any existing daily challenge implementations ==="
fd -e py | xargs rg -l "DailyChallenge" 2>/dev/null

echo ""
echo "=== Check for any Challenge-related views ==="
rg -n "Challenge" website/views/ -l

echo ""
echo "=== Check giveBacon function implementation ==="
rg -n "def giveBacon" -A 30 website/feed_signals.py

echo ""
echo "=== Check for BACON-related badge logic ==="
rg -n "Badge\|UserBadge" website/feed_signals.py -C 2 | head -30

Length of output: 3918

---

🏁 Script executed:

#!/bin/bash

# Check the full webhook handler implementations
echo "=== Checking handle_review_event implementation ==="
rg -n "def handle_review_event" -A 40 website/views/user.py

echo ""
echo "=== Checking handle_issue_event implementation ==="
rg -n "def handle_issue_event" -A 40 website/views/user.py

echo ""
echo "=== Check for existing GitHub webhook handlers ==="
rg -n "def handle_.*_event" website/views/user.py -A 2

echo ""
echo "=== Check for any existing security leaderboard or contribution tracking ==="
rg -n "security.*leaderboard\|security.*contribution" -i

echo ""
echo "=== Check if GitHubReview model has reviewer fields ==="
rg -n "class GitHubReview" -A 20 website/models.py

Length of output: 5583

---

@Pritz395 I've completed a thorough fact-check of your GSoC 2026 proposal against the BLT codebase. Here's my analysis:

✅ Existing Infrastructure (Correctly Referenced)

Your proposal accurately builds on these existing systems:

1. GitHub Models - GitHubIssue and GitHubReview models exist with proper fields including contributor, reviewer, and reviewer_contributor
2. CVE Infrastructure - The Issue model has both cve_id (CharField) and cve_score (DecimalField) fields, plus get_cve_score() and get_cve_severity() methods
3. CVE Pattern - The CVE-\d{4}-\d{4,7} regex pattern exists in the codebase
4. Webhook Handlers - handle_review_event(), handle_issue_event(), and handle_pull_request_event() all exist in website/views/user.py
5. Reward System - giveBacon() function exists in website/feed_signals.py with proper signature
6. Badge System - Both Badge and UserBadge models exist
7. Leaderboard Base - LeaderboardBase class exists in website/views/user.py
8. Testing Infrastructure - website/tests/test_github_webhook.py exists
9. ARIA/Dark Mode Patterns - 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 are both merged ✅

⚠️ Issue Identified: Daily Challenges

Your proposal mentions:

• DailyChallenge.CHALLENGE_TYPE_CHOICES
• check_and_complete_challenges() function
• "my daily challenges work"

However, the codebase only has a generic Challenge model (lines 2038-2051 in website/models.py) with CHALLENGE_TYPE_CHOICES for single/team challenges. I found no DailyChallenge model or check_and_complete_challenges() function.

Could you clarify:

• Is this work in a pending PR?
• Is this part of what you'll build?
• Or should the proposal reference the existing Challenge model instead?

✅ New Components (Buildable from Scratch)

These components don't exist yet but are architecturally sound:

1. GitHubSecurityContribution model - New model to link GitHub contributions to CVE data
2. Security leaderboards - Extending LeaderboardBase for CVE-focused rankings
3. Security dashboard UI - New SecurityContributionDashboardView
4. Security analytics - New SecurityAnalyticsView with ORM aggregations
5. Automated CVE-based BACON rewards - Integration of existing giveBacon() with webhook handlers for CVE contributions

🎯 Architectural Assessment

Feasibility: HIGH ✅

• The proposal follows existing Django patterns in the codebase
• Extending webhook handlers is straightforward
• CVE scoring logic already exists on the Issue model
• Badge/BACON systems are mature and well-documented
• The 350-hour estimate seems reasonable for the scope

Concerns:

1. CVE detection from PR/issue bodies requires robust parsing (GitHub doesn't guarantee format consistency)
2. Spam prevention via "maintainer verification" needs clear definition (webhook payload analysis?)
3. The cve_score field in Issue uses max_digits=2, decimal_places=1 (max value 9.9), but CVSS scores go up to 10.0

📝 Recommendation

The proposal is solid and builds correctly on existing systems, with one clarification needed about the daily challenges component. The new security contribution tracking is well-scoped and architecturally feasible. Consider addressing the cve_score database field constraint if you plan to store scores of 10.0.

[Pritz395]

@coderabbitai check if there are existing PRs working on the daily challenges component. There should be an active PR by me that's working on this. Also One thought / question about this. Are PRs / issues to fix CVEs usually made public?

ethical and responsible disclosure usually means disclosure is done privately to project leaders If PRs are submitted, wouldn't they typically be done on confidential issues?
So connecting the dots:
How would we actually find and track these issues and PRs in order to give credit?

Is there a way to allow the github api to see all of your issues and PRs even if they are confidential? (Genuine question- I don't know its capabilities)

This project proposal overall needs mentor approval so everything needs to be clear scoped and what can be done how within the gsoc timeline.

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash

# Search for PRs by Pritz395 mentioning daily challenge
echo "=== Searching for PRs by Pritz395 with 'daily challenge' ==="
gh pr list --author Pritz395 --state all --limit 100 --json number,title,state,body | \
  jq '.[] | select(.title | test("daily|challenge"; "i")) | {number, title, state}'

echo ""
echo "=== Alternative search: All PRs by Pritz395 (last 50) ==="
gh pr list --author Pritz395 --state all --limit 50 --json number,title,state,createdAt | \
  jq '.[] | {number, title, state, created: .createdAt}'

echo ""
echo "=== Search for any daily challenge related PRs in the repo ==="
gh pr list --search "daily challenge" --state all --limit 20 --json number,title,author,state | \
  jq '.[] | {number, title, author: .author.login, state}'

Length of output: 6134

---

🌐 Web query:

GitHub security advisory API private vulnerabilities

💡 Result:

Short answer:

• GitHub supports private vulnerability reporting for public repositories (reporters submit private advisories that maintainers can accept and convert to draft security advisories). Documented in GitHub Docs. [1]

• Programmatic access: use the GitHub GraphQL SecurityAdvisory / securityVulnerabilities fields (and related REST endpoints for repository advisories) to query advisories and vulnerabilities in the Advisory Database and repository advisories. See the GraphQL queries reference (securityAdvisory, securityVulnerabilities) and the repository-advisories REST schema. [2]

• Important: GitHub removed the ability to create or keep security advisories in private repositories (deprecation announced / effective 2024). Only public-repo advisories and the Advisory Database remain accessible via the API. [3]

If you want example GraphQL queries or REST calls to list advisories/vulnerabilities (including scopes/permissions required), tell me which language or tool (curl, gh, GraphQL) and I’ll return examples.

Sources: [1] GitHub Docs — Privately reporting a security vulnerability. [2] GitHub GraphQL queries / SecurityAdvisory & securityVulnerabilities (API docs). [3] GitHub changelog — deprecation notice: security advisories in private repositories.

---

🌐 Web query:

GitHub API access private security advisories CVE

💡 Result:

Short answer

• GitHub removed support for security advisories in private repositories (deprecated/disabled May 15, 2024). You cannot create or retrieve private repository advisories or get CVEs for a private advisory anymore. [1][2]

What you can do via the API

• Public repo advisories (and published advisories with CVEs) are accessible via GitHub’s REST and GraphQL advisory endpoints. You can:
  • List/create/update repository security advisories (REST endpoints /repos/{owner}/{repo}/security-advisories). [3]
  • Request a CVE for a repository advisory (only for public repos). That REST endpoint requires the repository_advisories:write or repo scope and that the caller be a repo security manager/administrator. [3][4]
  • Use the GraphQL API for advisories (Advisory objects available in GraphQL). [3]

Permissions / token scopes

• To read or manage advisories you need appropriate repo permissions plus one of:
  • repo or repository_advisories:read / repository_advisories:write scopes (or equivalent fine-grained GitHub App/installation tokens). Unpublished advisories require you be a security manager/admin or a collaborator on that advisory. [3][4]

If you want exact API calls or example curl/GraphQL queries to (a) list advisories for a repo, (b) request a CVE, or (c) create an advisory for a public repo, tell me which and I’ll provide the snippet.

Sources

• GitHub deprecation notice (security advisories in private repositories) — GitHub Blog / Changelog (May 15, 2024). [1]
• About repository security advisories (CVE behavior, public vs private). [2]
• REST API docs: Repository security advisories endpoints (including request CVE, scopes, temporary private forks). [3]
• REST API permissions/details for request-a-CVE and token scopes. [4]

---

🌐 Web query:

responsible disclosure CVE fix PRs public or private

💡 Result:

Short answer: keep CVE/fix work private (use coordinated disclosure, draft security advisory or private report/fork/branch and private CI) until a fixed release and public advisory/CVE are ready; only then make PRs and commits public. [1][2][3][4][5]

Recommended minimal workflow

• Receive/report privately (SECURITY.md contact, private vulnerability report, or vendor/security channel). [1][2]
• Create a draft security advisory / request CVE if needed; use the advisory/private fork or private branch for the fix. [2][1]
• Develop and test the fix in private (private forks/branches and private CI). Avoid public commits, issues, or PRs that reveal the vulnerability. [5][4]
• Coordinate an embargo / disclosure timeline with stakeholders (reporter, CNAs, vendors, distros) and get a CVE if appropriate. [3][4]
• Publish the patched release, the security advisory, and then make the PR/commit history public. After public release and notification, disclose technical details. [2][3]

Why: public PRs or commits that clearly indicate they fix a vulnerability can leak details before users are patched and are treated as an embargo breach by major vendors. Use established coordinated-disclosure practices to protect users and preserve CVE/embargo processes. [4][5][3]

If you want, I can draft a short SECURITY.md disclosure template and checklist (private reporting channel, expected response times, embargo policy, contact email).

---

@Pritz395 Great questions! Here's what I found:

✅ Daily Challenges PR Found

PR #5245: "Add Daily Challenges Feature with 24-Hour Reset Timer" by you is currently OPEN (created Dec 10, 2025). This confirms the daily challenges infrastructure you referenced in your proposal exists in an active PR.

🔐 Critical Architectural Issue: CVE Disclosure Practices

You've identified a fundamental scope problem for the GSoC proposal. Here's the reality:

How CVE Fixes Actually Work (Responsible Disclosure)

CVE fixes follow coordinated disclosure: work is kept private (using draft security advisories, private forks/branches, and private CI) until a patched release and public advisory are ready, then PRs and commits are made public.

Timeline:

1. Private phase → Vulnerability reported privately → Fix developed in private fork/branch → No public PRs/issues
2. Disclosure phase → Patch released → Security advisory published → CVE assigned → Details made public

GitHub API Limitations

GitHub deprecated security advisories in private repositories in May 2024. The API can only access public repository advisories via REST and GraphQL endpoints.

What this means for tracking:

• ❌ Cannot track private security work via webhooks/API (by design - it's secret!)
• ❌ Cannot access private forks or draft advisories programmatically
• ✅ Can track published security advisories and CVEs after disclosure
• ✅ Can track public PRs that reference CVE IDs in commit messages/descriptions

🎯 Suggested Scope Adjustments

Option A: Post-Disclosure Tracking (Realistic)

Track CVE contributions after they're made public:

• Monitor published GitHub Security Advisories via GraphQL SecurityAdvisory/securityVulnerabilities fields and REST repository-advisories endpoints
• Parse commit messages and PR descriptions for CVE references (e.g., CVE-2024-1234)
• Credit contributors when fixes are merged to public branches
• Limitation: No tracking during private development phase

Option B: Self-Reporting (Hybrid)

• Allow contributors to self-report CVE work with proof links
• Maintainer verification after disclosure
• Retroactive BACON rewards when advisories are published

Option C: Focus on Public Security Improvements

Shift focus to publicly-trackable security work:

• Security tool integration fixes (Dependabot, CodeQL alerts)
• Security-labeled issues/PRs
• Dependency updates addressing known CVEs

📋 Next Steps for GSoC Proposal

You need mentor guidance on:

1. Which scope is acceptable for GSoC timeline?
2. Is post-disclosure tracking sufficient, or should you pivot to different security metrics?
3. Should the proposal focus on public security contributions instead of CVE disclosure tracking?

The technical implementation is sound, but the scope needs clarification around what types of security contributions can realistically be tracked given responsible disclosure practices.

Would you like me to help draft revised scope language for your proposal based on one of these options?

[Pritz395]

@coderabbitai but isn't there another active PR by me thats working on CVE related updates as we speak? Also how would bacon be awarded upon PR verification? That logic is kinda vague? Contributor's can fake it or etc..I need you to fact-check implementability and practicality of my proposal.