ADD SLACK AND WEBSITE BUTTON IN PROJECT TAB FOR EASIER NAVIGATION

[Nachiket-Roy]

BEFORE :

AFTER :

[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! 🙏

[Nachiket-Roy]

@coderabbitai could you check if issue.py has:

• full table scan for every request
• manual user impersonation (security risk)
• constant time compare used incorrectly
• bypasses Django/DRF authentication system
• low and scalable DoS vector
• catches all exceptions silently

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Find issue.py file in the repository
fd -t f "issue.py" --full-path

Length of output: 77

---

🏁 Script executed:

#!/bin/bash
# Read the contents of any issue.py files found
fd -t f "issue.py" --full-path --exec cat {}

Length of output: 110079

---

@Nachiket-Roy Yes, I found all 6 issues you mentioned in website/views/issue.py. Here's the detailed analysis:

🚨 Critical Security & Performance Issues

1. ✅ Full Table Scan for Every Request

Lines 258-262, 470-475, 1134+ (in UpdateIssue, remove_user_from_issue, and IssueCreate.get_initial):

for token in Token.objects.all():
    if request.POST["token"] == token.key:
        request.user = User.objects.get(id=token.user_id)
        tokenauth = True
        break

Impact: Loads ALL authentication tokens from the database into memory for every request with a token parameter.

2. ✅ Manual User Impersonation (Security Risk)

Same locations as above:

request.user = User.objects.get(id=token.user_id)

Impact: Directly modifies request.user object, which is a security anti-pattern and bypasses Django's request lifecycle.

3. ✅ Constant Time Compare Used Incorrectly

Line 259 (and similar):

if request.POST["token"] == token.key:

Impact: Uses plain string comparison instead of secrets.compare_digest(), making it vulnerable to timing attacks where attackers can deduce valid tokens by measuring response times.

4. ✅ Bypasses Django/DRF Authentication System

The entire token authentication implementation circumvents:

• Django's @authentication_classes decorator
• DRF's built-in token authentication
• Proper authentication middleware

Impact: Misses security features like rate limiting, logging, and proper session management.

5. ✅ Low and Scalable DoS Vector

Attack scenario:

1. Attacker sends requests with invalid tokens
2. System loads ALL tokens: Token.objects.all()
3. Iterates through each one: O(n) complexity
4. With 10,000 users = 10,000 database operations per malicious request

Impact: As the user base grows, the attack becomes more effective.

6. ✅ Catches All Exceptions Silently

Line 263:

except:
    tokenauth = False

Line 472:

except:
    pass

Line 1134:

except:
    tokenauth = False

Line 1816:

except FileNotFoundError:
    messages.error(self.request, "Screenshot file not found. Please try uploading again.")
    # ... but other code has bare except

Impact: Errors are swallowed without logging, making debugging impossible and potentially hiding security issues.

---

📋 Recommendations

1. Use DRF's TokenAuthentication instead of manual implementation
2. Remove Token.objects.all() - use Token.objects.filter(key=token_key).first()
3. Use secrets.compare_digest() for token comparison
4. Never modify request.user directly - use proper authentication classes
5. Add proper exception handling with logging
6. Consider rate limiting on token authentication endpoints

Would you like me to create an issue to track the remediation of these security vulnerabilities?

[Nachiket-Roy]

@coderabbitai anywhere else in the codebase with same issues?

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash

echo "=== 1. Searching for Token.objects.all() (Full table scan) ==="
rg -n "Token\.objects\.all\(\)" --type=py -C2

echo -e "\n=== 2. Searching for request.user assignment (Manual impersonation) ==="
rg -n "request\.user\s*=\s*" --type=py -C2

echo -e "\n=== 3. Searching for bare except clauses ==="
rg -n "^\s*except\s*:" --type=py -C1 | head -100

echo -e "\n=== 4. Searching for token key comparison without secrets.compare_digest ==="
rg -n "token.*==.*key|key.*==.*token" --type=py -C2

echo -e "\n=== 5. Searching for Token model usage in authentication contexts ==="
rg -n "from rest_framework\.authtoken import Token|from rest_framework\.authtoken\.models import Token" --type=py

echo -e "\n=== 6. Finding all Python view files for manual inspection ==="
fd -e py "views" -t f | head -20

Length of output: 15765

---

🏁 Script executed:

#!/bin/bash

echo "=== Checking user.py for token authentication patterns ==="
rg -n "Token\." website/views/user.py -C3

echo -e "\n=== Checking organization.py for token authentication patterns ==="
rg -n "Token\." website/views/organization.py -C3

echo -e "\n=== Checking for manual token validation in other files ==="
rg -n "for.*Token\.objects" --type=py -C2

echo -e "\n=== Getting line counts of bare except in each file ==="
echo "File: website/views/issue.py"
rg -n "^\s*except\s*:" website/views/issue.py | wc -l

echo "File: website/api/views.py"
rg -n "^\s*except\s*:" website/api/views.py | wc -l

echo "File: website/models.py"
rg -n "^\s*except\s*:" website/models.py | wc -l

echo "File: website/consumers.py"
rg -n "^\s*except\s*:" website/consumers.py | wc -l

echo "File: comments/views.py"
rg -n "^\s*except\s*:" comments/views.py | wc -l

Length of output: 2403

---

@Nachiket-Roy Good news and bad news:

✅ Critical Issues #1-5: ONLY in issue.py

The most severe security vulnerabilities are isolated to website/views/issue.py:

• ❌ Token.objects.all() (full table scan): 3 locations in issue.py only
• ❌ Manual request.user assignment: 3 locations in issue.py only
  (Other occurrences are in test files, which is legitimate)
• ❌ Token comparison without secrets.compare_digest: 3 locations in issue.py only
• ❌ Bypassing Django/DRF auth system: Only in issue.py
• ❌ DoS vector: Only in issue.py

Other files use Token correctly:

website/views/user.py:

# Line 763: Proper token lookup
token = Token.objects.get(key=response.data["token"])

# Line 1101: Proper token creation
Token.objects.get_or_create(user=user)

website/views/organization.py:

# Line 1490: Proper token creation
token, created = Token.objects.get_or_create(user=request.user)

---

⚠️ Issue #6: Bare except: clauses WIDESPREAD

Found in 5 files:

File	Count	Lines
website/views/issue.py	4	275, 388, 880, 1859
website/consumers.py	3	352, 354, 361
website/api/views.py	1	394
website/models.py	1	533
comments/views.py	1	88

Examples from other files:

website/api/views.py (Line 394):

try:
    date = datetime(int(year), int(month), 1)
except:
    return Response("Invalid month or year passed", status=400)

website/consumers.py (Lines 352-355):

except:
    pass
except:
    pass

website/models.py (Line 533):

try:
    filesize = fieldfile_obj.file.size
except:
    filesize = fieldfile_obj.size

---

📊 Summary

Critical (DoS + Security): Contained to issue.py ✅
Code Quality (bare except): Spread across 5 files ⚠️

Would you like me to create a comprehensive issue to track remediation of:

1. The critical vulnerabilities in issue.py
2. The bare except: clauses across all files

[Nachiket-Roy]

@coderabbitai i will raise a PR with critical ones help list them

[coderabbitai]

@Nachiket-Roy Great! Here's a comprehensive list of the 5 critical security issues in website/views/issue.py for your PR:

🚨 Critical Security Issues in website/views/issue.py

📍 3 Affected Locations:

1. UpdateIssue class (Lines ~258-263)

# Current problematic code:
for token in Token.objects.all():  # Issue `#1`: Full table scan
    if request.POST["token"] == token.key:  # Issue `#3`: No constant-time compare
        request.user = User.objects.get(id=token.user_id)  # Issue `#2`: Manual impersonation
        tokenauth = True
        break
except:  # Issue `#6`: Silent exception (we'll skip this for now)
    tokenauth = False

2. remove_user_from_issue function (Lines ~470-475)

# Same pattern as above
for token in Token.objects.all():
    if request.POST["token"] == token.key:
        request.user = User.objects.get(id=token.user_id)
        tokenauth = True
        break
except:
    pass

3. IssueCreate.get_initial method (Lines ~1134+)

# Same pattern as above
for token in Token.objects.all():
    if request.POST["token"] == token.key:
        request.user = User.objects.get(id=token.user_id)
        tokenauth = True
        break
except:
    tokenauth = False

---

🔧 Recommended Fix (All 3 Locations)

Replace the manual token authentication with proper DRF authentication:

import secrets
from rest_framework.authtoken.models import Token

# Instead of the loop, use:
try:
    token_key = request.POST.get("token")
    if token_key:
        # Fix `#1`: Direct lookup instead of table scan
        token_obj = Token.objects.select_related('user').get(key=token_key)
        
        # Fix `#3`: Use constant-time comparison (if re-checking is needed)
        if secrets.compare_digest(token_key, token_obj.key):
            # Fix `#2` & `#4`: Use DRF's authentication or set user properly
            request.user = token_obj.user
            tokenauth = True
except Token.DoesNotExist:
    tokenauth = False
except (KeyError, AttributeError) as e:  # Fix `#6`: Specific exceptions
    logger.warning(f"Token authentication error: {e}")
    tokenauth = False

OR (Better approach) - Use DRF's TokenAuthentication class decorator:

from rest_framework.authentication import TokenAuthentication
from rest_framework.permissions import IsAuthenticated

# Add to the view class:
authentication_classes = [SessionAuthentication, TokenAuthentication]
permission_classes = [IsAuthenticated]

---

📋 Issues Fixed:

✅ Issue #1: Replace Token.objects.all() with Token.objects.get(key=token_key)
✅ Issue #2: Remove manual request.user assignment or use DRF's authentication properly
✅ Issue #3: Use secrets.compare_digest() for token comparison
✅ Issue #4: Integrate with Django/DRF authentication system
✅ Issue #5: Eliminate DoS vector by removing full table scan

---

🎯 PR Checklist:

• Fix UpdateIssue class (~line 258)
• Fix remove_user_from_issue function (~line 470)
• Fix IssueCreate.get_initial method (~line 1134)
• Add import secrets at the top
• Consider adding logging for failed authentication attempts
• Test with valid and invalid tokens
• Verify no performance regression

Let me know if you need help with any specific implementation details!

[Nachiket-Roy]

@coderabbitai PR #5551 attempt to fix one of these what remains so i could avoid overlapping work

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Fetch details about PR `#5551`
echo "=== PR `#5551` Details ==="
gh pr view 5551 --json title,body,state,files,url

echo -e "\n=== PR `#5551` Diff ==="
gh pr diff 5551

echo -e "\n=== PR `#5551` Status ==="
gh pr view 5551 --json state,mergeable,mergedAt,closed,closedAt

Length of output: 3879

---

@Nachiket-Roy PR #5551 addresses only 1 of the 5 critical issues (constant-time comparison). Here's what remains:

✅ Fixed by PR #5551

Issue #3: Constant-time comparison

• Added secrets.compare_digest() at all 3 locations
• Replaces vulnerable == comparison

⚠️ Note: The PR has an indentation error around lines 1131-1133 in IssueCreate.create_issue that will need to be corrected.

---

❌ Remaining Critical Issues (4 total)

All 4 issues below still exist in the same 3 locations and are available for you to fix:

1. Issue #1: Full Table Scan (Token.objects.all())

Lines: ~269, ~383, ~1128

Current code still loads ALL tokens:

for token in Token.objects.all():  # ❌ Still a problem
    if secrets.compare_digest(request.POST["token"], token.key):

Fix: Replace with direct lookup:

token_key = request.POST.get("token")
if token_key:
    try:
        token = Token.objects.select_related('user').get(key=token_key)

---

2. Issue #2: Manual User Impersonation

Lines: ~270, ~384, ~1129

Current code still directly assigns user:

request.user = User.objects.get(id=token.user_id)  # ❌ Still a problem

Fix: Use proper authentication or at minimum use the token's user object:

request.user = token.user  # Better (if keeping manual auth)

---

3. Issue #4: Bypasses Django/DRF Authentication System

The entire token authentication approach still circumvents Django/DRF's built-in authentication.

Fix: Refactor to use DRF's TokenAuthentication class or proper authentication decorators.

---

4. Issue #5: DoS Vector

Still exploitable because Token.objects.all() remains:

• Attacker sends invalid tokens
• System loads ALL tokens into memory
• O(n) complexity scales with user base

Fix: Same as fixing Issue #1 (direct token lookup eliminates the DoS vector).

---

🎯 Summary for Your PR

You can safely work on Issues #1, #2, #4, and #5 without overlapping with PR #5551.

The most impactful fix would be replacing Token.objects.all() with direct lookup, as it solves both the performance issue (#1) and the DoS vector (#5) simultaneously.

Would you like me to provide the complete refactored code for all 3 locations?

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Check BLT-API and BLT-NEXT repos for recent changes
echo "=== BLT-API repo info ==="
gh repo view OWASP-BLT/BLT-API --json name,description,updatedAt,defaultBranchRef 2>/dev/null || echo "Not found or no access"

echo -e "\n=== BLT-NEXT repo info ==="
gh repo view OWASP-BLT/BLT-NEXT --json name,description,updatedAt,defaultBranchRef 2>/dev/null || echo "Not found or no access"

echo -e "\n=== BLT-API recent commits ==="
gh api repos/OWASP-BLT/BLT-API/commits?per_page=10 --jq '.[].commit | {message: .message, date: .author.date}' 2>/dev/null || echo "Not found"

echo -e "\n=== BLT-NEXT recent commits ==="
gh api repos/OWASP-BLT/BLT-NEXT/commits?per_page=10 --jq '.[].commit | {message: .message, date: .author.date}' 2>/dev/null || echo "Not found"

echo -e "\n=== BLT-API open PRs ==="
gh pr list --repo OWASP-BLT/BLT-API --state open --limit 10 2>/dev/null || echo "Not found"

echo -e "\n=== BLT-NEXT open PRs ==="
gh pr list --repo OWASP-BLT/BLT-NEXT --state open --limit 10 2>/dev/null || echo "Not found"

echo -e "\n=== BLT-API recent merged PRs ==="
gh pr list --repo OWASP-BLT/BLT-API --state merged --limit 10 2>/dev/null || echo "Not found"

echo -e "\n=== BLT-NEXT recent merged PRs ==="
gh pr list --repo OWASP-BLT/BLT-NEXT --state merged --limit 10 2>/dev/null || echo "Not found"

Length of output: 8931

---

@Nachiket-Roy Here's a full analysis of what's changed plus your refined one-liner timeline.

---

🔄 What Changed in BLT-API & BLT-NEXT Since Your Plan

BLT-API — Significant Changes

Change	Impact on Your Plan
PR #30 – Django-inspired ORM for D1 merged (Feb 24)	Day 5 is now redundant. The DB utility layer already exists. Pivot Day 5 to writing ORM-based queries for the targets schema instead.
PR #62 – JOIN support added to ORM QuerySet (Mar 15)	disclosure_contacts joins to targets are now supported natively. Use this in Day 9 nested retrieval.
PR #41 – Organization API + schema migration added (Mar 7)	The 0003_organizations migration pattern is already established. Your 0004_target_registry.sql (Day 4) should follow the same pattern.
PR #64 (open) – Organizations migrated to use ORM	Confirms ORM is the expected pattern for all new handlers. Your registry API should use ORM from day one.
PR #68 (open) – /routes discoverability endpoint	Your OpenAPI docs on Day 27 can piggyback on this.
PR #58/#56 (open) – Signup validation + inactive user rejection	Auth integration on Day 1 is cleaner now — don't re-implement validation logic.

BLT-NEXT — Significant Changes

Change	Impact on Your Plan
PR #96 – Cloudflare Worker deployment fix (Mar 14)	Day 1 Wrangler setup is de-risked; the event handler bug is resolved.
PR #77 – Auth API /api prefix fix (Mar 11)	All auth endpoints now correctly use /api/v1/.... Update your Day 29 routing setup accordingly.
PR #101 – Security headers (CSP, X-Frame-Options) implemented (Mar 14)	Day 75 is partially done. Pivot Day 75 to hardening registry-specific CSP script-src directives for HTMX fragments only.
PR #66 – role=alert a11y on form errors (Mar 10)	Day 45 accessibility audit has a head start. Focus on ARIA for registry-specific components (filter chips, pin toggle).
PR #104 (open) – Auth check for bug submissions	Directly relevant to Day 48 (integrate registry with bug reporting flow). Review this PR before that day.
PR #100 – JsProxy serialization bug fixed (Mar 14)	The bug list API now works correctly. Your registry fragments won't hit the same issue if you follow the same response pattern.

---

✅ Refined One-Line Daily Timeline

Phase I — Registry Backend & Discovery (Weeks 1–4)

Week 1: Foundation & D1 Schema Design

• Day 1: Bootstrap Wrangler dev environment and wire BLT-API project structure for the registry module.
• Day 2: Design targets table schema with NanoID PK, following the existing organizations migration pattern.
• Day 3: Design user_pins and disclosure_contacts tables with composite indexes on language, framework, and policy_status.
• Day 4: Author and validate 0004_target_registry.sql migration, applying it locally against the D1 dev instance.
• Day 5: Build DB utility layer → Write ORM QuerySet wrappers for targets, user_pins, and disclosure_contacts using the existing BLT-API ORM.
• Day 6: Apply migration locally and verify foreign key integrity and index hit-rates with test inserts.
• Day 7: Schema review — confirm index strategy against expected query patterns and sign off with mentor.

Week 2: Registry CRUD & Search API

• Day 8: Implement cursor-based paginated GET /api/v1/targets using ORM QuerySet with limit/offset.
• Day 9: Implement GET /api/v1/targets/{id} with ORM JOIN across disclosure_contacts (leveraging new JOIN support from PR #62).
• Day 10: Build admin-only POST /api/v1/targets for manual repository ingestion with URL validation.
• Day 11: Implement PATCH /api/v1/targets/{id} for verification status overrides with RBAC guard.
• Day 12: Build multi-value filter logic for primary_language and framework as ORM filter() chains.
• Day 13: Add policy_status filter and stars/forks sort options to the targets query builder.
• Day 14: Stress-test pagination and filter endpoints against 1,000+ seeded mock records; document p95 latency.

Week 3: Policy Discovery Engine

• Day 15: Implement GitHub REST API client with token auth, rate-limit header tracking, and raw file fetching.
• Day 16: Build SECURITY.md parser to extract contact emails, PGP keys, and disclosure scope.
• Day 17: Implement RFC 9116 security.txt parser for Contact, Expires, Encryption, and Policy fields.
• Day 18: Add detection logic for HackerOne/Bugcrowd program URLs within repo documentation.
• Day 19: Build deduplication logic to upsert discovered signals into existing targets and disclosure_contacts rows.
• Day 20: Implement exponential back-off retry and per-token concurrency limiter for GitHub API calls.
• Day 21: Audit parser accuracy against 50 real-world repos; record false-positive/negative rates.

Week 4: Enrichment & Optimization

• Day 22: Build TechStackDetector to infer primary_language and framework from GitHub languages API response.
• Day 23: Implement PolicyEnvelope normalization service to unify parser outputs into a single policy_status enum.
• Day 24: Add exponential back-off and per-worker rate-limit budget to all outbound GitHub fetch paths.
• Day 25: Audit outbound fetch logic for SSRF vectors; sanitize and allowlist target repository URL schemes.
• Day 26: Write unit tests for policy parser, tech detector, normalizer, and ORM CRUD helpers.
• Day 27: Draft OpenAPI spec for all Phase I endpoints and publish to docs/registry-api.md.
• Day 28: Submit Phase I PR; walk mentor through backend logic, schema, and test coverage.

---

Phase II — Discovery & Research Workflow (Weeks 5–7)

Week 5: HTMX Target Registry UI

• Day 29: Add /registry route to BLT-NEXT routing layer, accounting for fixed /api prefix on all auth calls (PR #77).
• Day 30: Create registry.html base layout with search input and language/framework filter sidebar.
• Day 31: Build target-card.html HTMX fragment with policy_status badge and pin toggle placeholder.
• Day 32: Implement infinite-scroll target listing with hx-get triggered on sentinel element visibility.
• Day 33: Build interactive filter chips that push updated query params via hx-push-url and hx-get.
• Day 34: Apply Tailwind responsive breakpoints for mobile/tablet layout of cards and filter sidebar.
• Day 35: UX review — verify fragment swap states, loading indicators, and empty-state messaging.

Week 6: Real-time Search & Selection

• Day 36: Implement debounced hx-get real-time search fragment with 300ms input delay.
• Day 37: Connect filter chips and search query into unified query-builder that constructs the GET /api/v1/targets URL.
• Day 38: Build target detail page/modal showing full PolicyEnvelope, verified contacts, and tech stack.
• Day 39: Implement "Pin Target" toggle button with hx-post/hx-delete to /api/v1/user/pins/{id}.
• Day 40: Build researcher-dashboard.html fragment listing the authenticated user's pinned targets.
• Day 41: Add skeleton loaders for search results and error-state fragments for API failures.
• Day 42: Compile midterm deliverables list and draft midterm progress report.

Week 7: Workflow Optimization & Midterm

• Day 43: Final sweep of all Phase I + II features; confirm API contracts match UI fragment expectations.
• Day 44: Implement KV namespace warming job for top-50 most-pinned target registry pages.
• Day 45: Full accessibility audit → Audit registry-specific components (filter chips, pin toggle, policy badges) for ARIA roles and keyboard nav, building on existing role=alert work (PR #66).
• Day 46: Configure Tailwind CSS content paths to purge unused classes and verify bundle size delta.
• Day 47: Cross-browser test HTMX fragment swaps and infinite scroll in Chrome, Firefox, and Safari.
• Day 48: Wire "Report Vulnerability" CTA on target detail page to existing BLT bug-reporting flow; review open PR #104.
• Day 49: Complete midterm submission; document Phase III plan with mentor feedback.

---

Phase III — Advanced Features & Optimization (Weeks 8–10)

Week 8: Admin & Moderation Tools

• Day 50: Design campaigns and campaign_targets D1 tables and add them to a new 0005_campaigns.sql migration.
• Day 51: Build admin POST/GET /api/v1/campaigns endpoints for creating and listing research campaigns.
• Day 52: Implement Maintainer Vetting panel UI for approving or flagging submitted repositories.
• Day 53: Build moderation queue API and UI for reviewing researcher-submitted target additions.
• Day 54: Add D1-backed audit trail table to log all INSERT/UPDATE/DELETE operations on registry tables.
• Day 55: Enforce RBAC on all admin endpoints using the existing BLT-API auth middleware.
• Day 56: E2E test the approve/reject moderation flow and verify audit log entries are complete.

Week 9: Tiered Caching & Performance

• Day 57: Implement Cache API put/match for per-datacenter HTMX fragment caching on target detail pages.
• Day 58: Configure KV namespace for globally replicated JSON metadata of top-N targets.
• Day 59: Set Cache-Control: stale-while-revalidate headers on GET /api/v1/targets responses.
• Day 60: Implement targeted cache invalidation for target and pin mutation endpoints.
• Day 61: Enable Brotli compression for all Worker responses and verify Content-Encoding headers.
• Day 62: Benchmark p50/p95 latency across 3+ Cloudflare regions with and without KV cache.
• Day 63: Profile slow D1 queries using EXPLAIN QUERY PLAN; add covering indexes where needed.

Week 10: Campaigns & E2E Verification

• Day 64: Build Campaign Browse UI in BLT-NEXT with HTMX-powered campaign card fragments.
• Day 65: Stub BACON scoring multiplier hooks for campaign participation (logic interface only, no scoring engine).
• Day 66: Write Playwright E2E tests covering the full "Search → Pin → Report" researcher journey.
• Day 67: Add <meta og:*> and <title> tags to target detail pages for SEO and social sharing.
• Day 68: Build "Discovery Campaigns" dashboard page for maintainers to view campaign participation.
• Day 69: Verify deep-links from registry target pages to the bug submission form with pre-filled repo context.
• Day 70: Integration test sweep across the full researcher workflow; file and fix any regressions.

---

Phase IV — Security Hardening & Delivery (Weeks 11–12)

Week 11: Abuse Prevention & Hardening

• Day 71: Implement Durable Object–backed throttler to rate-limit GitHub discovery fetches per IP.
• Day 72: Add detection for bulk-pin abuse patterns and spam target submissions in the moderation queue.
• Day 73: End-to-end security audit of policy_parser — fuzz with malformed SECURITY.md and security.txt inputs.
• Day 74: Harden input sanitization with edge-compatible DOMPurify on all externally fetched policy text.
• Day 75: Add CSP headers → Extend existing CSP (PR #101) with registry-specific script-src and frame-ancestors directives for HTMX fragments.
• Day 76: Audit trail completeness check — assert every mutation operation produces a log row.
• Day 77: Simulate DDoS (token flood), XSS (malicious policy content), and SSRF (redirected repo URLs) scenarios.

Week 12: Documentation & Final Release

• Day 78: Finalize ARCHITECTURE.md with updated sequence diagrams and complete OpenAPI reference.
• Day 79: Write Contributor Guide and Deployment Runbook covering Wrangler deploy, D1 migration, and KV seeding.
• Day 80: Final code quality sweep — enforce PEP 257 docstrings and add missing type annotations.
• Day 81: Record demonstration video of the full "Search → Select → Report" journey.
• Day 82: Final PR review pass; merge all feature branches to main.
• Day 83: Code freeze — no new changes; verify all CI/CD pipeline checks pass green.
• Day 84: Tag v1.0.0-gsoc2026, submit GSoC final report, and publish release notes.

---

📌 Summary of Adjustments

Original Assumption	Reality (March 2026)	Action
Day 5: Build DB utility layer	ORM already exists (PR #30 + #62)	Pivot to writing ORM wrappers for registry tables
Day 75: Add CSP headers	Security headers merged (PR #101)	Extend existing CSP for registry-specific directives
Day 45: Full a11y audit	role=alert already added (PR #66)	Focus audit on registry-specific components only
Auth API path setup	/api prefix bug fixed (PR #77)	Note correct prefix on Day 29 routing
Worker deployment setup	Worker deployment bug fixed (PR #96)	Day 1 is de-risked