fixture-worker

name	fixture-worker
description	Creates intentionally vulnerable and clean test fixture apps in tests/fixtures/ for validating VibeGuard scanner rules across all supported stacks.

Fixture Worker

Creates realistic but minimal test fixture applications — both intentionally vulnerable and clean — used to validate that VibeGuard scanner rules correctly detect (or skip) vulnerability patterns across all supported stacks.

When to Use This Skill

• Creating new vulnerable test fixture apps (e.g., tests/fixtures/vulnerable_flask_app/)
• Creating clean test fixture apps for false-positive testing
• Adding new vulnerability patterns to existing fixtures
• Ensuring specific vulnerability categories (A–P) are covered by fixture files
• Updating fixtures when rule detection logic changes

Required Skills

None

Work Procedure

1. Read Which Vulnerability Categories the Fixture Must Cover

• Read the task description to identify:
  • Which stack the fixture targets (Supabase, Firebase, Next.js, Express, Flask, Django)
  • Which vulnerability categories (A–P) the fixture must contain
  • Whether this is a vulnerable fixture or a clean fixture (for false-positive testing)
• Review docs/vibeguard-spec.json for the full rule definitions, including detection patterns and examples for each category.
• Cross-reference the milestone spec for coverage requirements:
  • vulnerable_supabase_app — covers B (RLS), C (secrets), I (.env), L (session storage)
  • vulnerable_firebase_app — covers C (secrets), J (Firebase rules), I (.env)
  • vulnerable_nextjs_app — covers A (client-side auth), D (CSRF), E (headers), F (SSRF), G (authz), K (rate limit), P (debug)
  • vulnerable_express_app — covers D (CSRF), F (SSRF), G (authz), H (business logic), K (rate limit), N (CORS), O (input validation)
  • vulnerable_flask_app — covers D (CSRF), F (SSRF), G (authz), H (business logic), K (rate limit), O (input validation), P (debug)
  • vulnerable_django_app — covers D (CSRF), E (headers), G (authz), K (rate limit), O (input validation), P (debug)

2. Create Realistic but Minimal Fixture Files

• Each fixture is a directory under tests/fixtures/ containing source files only (not a runnable app).

• Use realistic filenames and structure for the target stack:

  Python stacks (Flask/Django):

  • app.py or views.py, settings.py, urls.py, requirements.txt, .env

  Node.js stacks (Next.js/Express):

  • package.json, server.js or app.js, next.config.js, .env, source files in src/ or pages/

  BaaS stacks (Supabase/Firebase):

  • package.json, supabase/migrations/*.sql, firestore.rules, storage.rules, .env, client source files

• Keep files minimal — include only enough code to demonstrate the vulnerability pattern. Typically 20–80 lines per file.

• Use clear comments to mark vulnerable sections:

# VULNERABLE: Debug mode enabled in production
app.run(debug=True)

// VULNERABLE: No CSRF token validation on state-changing endpoint
app.post('/api/transfer', (req, res) => {

3. Include Both Vulnerable and Clean Patterns

• For each vulnerability category in the fixture, include:

  • At least one vulnerable pattern that the scanner rule should detect
  • At least one clean pattern (nearby or in a separate file) that the scanner should NOT flag

• Example for Rule K (Missing Rate Limiting):

  # VULNERABLE: Login endpoint with no rate limiting
  @app.route('/login', methods=['POST'])
  def login():
      # ... direct auth check, no rate limiter ...
  
  # CLEAN: Login endpoint with rate limiting applied
  @limiter.limit("5 per minute")
  @app.route('/secure-login', methods=['POST'])
  def secure_login():
      # ... rate-limited auth check ...
  

• For clean fixture apps (zero vulnerabilities), create a separate directory (e.g., tests/fixtures/clean_flask_app/) that implements all security best practices. This validates the scanner reports zero findings (false-positive rate < 5%).

4. Verify Fixtures Contain Expected Patterns

Use grep / rg to confirm that vulnerability patterns are present in the fixture files:

# Verify Rule P patterns exist in Flask fixture
rg "debug=True" tests/fixtures/vulnerable_flask_app/
rg "DEBUG = True" tests/fixtures/vulnerable_django_app/

# Verify Rule C secret patterns exist
rg "sk-[a-zA-Z0-9]" tests/fixtures/vulnerable_nextjs_app/
rg "AKIA[0-9A-Z]" tests/fixtures/vulnerable_express_app/

# Verify Rule B RLS patterns exist in Supabase fixture
rg "CREATE TABLE" tests/fixtures/vulnerable_supabase_app/
rg -v "ENABLE ROW LEVEL SECURITY" tests/fixtures/vulnerable_supabase_app/

# Verify clean patterns also exist (for false-positive testing)
rg "CLEAN:" tests/fixtures/vulnerable_flask_app/

# Verify fixture directory structure is correct
find tests/fixtures/vulnerable_flask_app/ -type f

Confirm each required vulnerability category has at least one detectable pattern in the fixture.

5. Commit Changes

Stage and commit all fixture files with a descriptive message:

git add -A
git commit -m "test(fixtures): add vulnerable <stack> app fixture covering rules <list>"

Example Handoff

{
  "salientSummary": "Created vulnerable Flask app fixture covering 7 vulnerability categories (D, F, G, H, K, O, P) with 12 source files. Includes both vulnerable and clean patterns for false-positive validation.",
  "whatWasImplemented": [
    "tests/fixtures/vulnerable_flask_app/app.py — main app with CSRF, SSRF, authz, rate limit, debug vulnerabilities",
    "tests/fixtures/vulnerable_flask_app/routes/orders.py — business logic flaws (negative quantities, zero-amount payments)",
    "tests/fixtures/vulnerable_flask_app/routes/api.py — missing input validation on 3 endpoints",
    "tests/fixtures/vulnerable_flask_app/requirements.txt — dependency list with known vulnerable versions",
    "tests/fixtures/vulnerable_flask_app/.env — exposed environment file with placeholder secrets",
    "tests/fixtures/vulnerable_flask_app/secure_routes.py — clean implementations for false-positive testing"
  ],
  "whatWasLeftUndone": [
    "Clean Flask fixture (tests/fixtures/clean_flask_app/) not yet created — planned for separate task",
    "Rule M (vulnerable dependencies) patterns not included — requires mock pip-audit data"
  ],
  "verification": {
    "commandsRun": [
      "rg 'debug=True' tests/fixtures/vulnerable_flask_app/ — found in app.py line 45 (Rule P)",
      "rg 'requests.get.*request.args' tests/fixtures/vulnerable_flask_app/ — found in app.py line 22 (Rule F)",
      "rg '@app.route.*POST' tests/fixtures/vulnerable_flask_app/ — found 5 POST endpoints, 4 without CSRF (Rule D)",
      "rg 'CLEAN:' tests/fixtures/vulnerable_flask_app/ — found 4 clean patterns across 2 files",
      "find tests/fixtures/vulnerable_flask_app/ -type f | wc -l — 12 files total"
    ],
    "interactiveChecks": []
  },
  "tests": {
    "added": []
  },
  "discoveredIssues": [
    "Rule H (business logic) requires realistic e-commerce code — created a minimal order processing module with negative quantity and zero-amount payment paths",
    "Django fixture will need manage.py and settings.py with INSTALLED_APPS to be recognizable by the stack detector"
  ]
}

When to Return to Orchestrator

• All required fixture files exist in the correct directory structure
• Each specified vulnerability category has at least one detectable pattern
• Clean/secure patterns are included for false-positive testing
• Patterns are verified via grep/rg to confirm detectability
• Changes are committed
• Handoff summary is complete with all fields populated
• If blocked (e.g., unclear what pattern a rule should detect, need rule spec clarification), return immediately with the blocker described in discoveredIssues