Skanowanie bezpieczenstwa z Codex

Badacz bezpieczenstwa wlasnie zlozyl raport w ramach odpowiedzialnego ujawniania: twoje API zwraca wewnetrzne szczegoly bledow w odpowiedziach produkcyjnych, a flow resetowania hasla jest podatny na ataki enumeracyjne. Masz 48 godzin zanim raport stanie sie publiczny. Musisz zaudytowac cala baze kodu pod katem podobnych problemow, naprawic zgloszne, i skonfigurowac ciagale skanowanie, aby to sie nie powtorzylo. Codex moze skanowac baze kodu z wielu katow jednoczesnie, naprawic krytyczne problemy i zautomatyzowac biezace monitorowanie bezpieczenstwa.

Co wyniesiesz z tej lekcji

• Prompty do kompleksowych audytow bezpieczenstwa obejmujacych trasy API, uwierzytelnianie i obsluge danych
• Workflow rownoleglego skanowania za pomoca worktree do audytu roznych domen bezpieczenstwa jednoczesnie
• Wytyczne recenzji AGENTS.md wylapujace problemy bezpieczenstwa na kazdym PR
• Przepis na automatyzacje codziennych skanowan bezpieczenstwa

Workflow

Krok 1: Przeprowadz natychmiastowy audyt

Dla zgloszonych problemow uzyj CLI do szybkiego, ukierunkowanego badania:

Wskazówka

Gotowy prompt do celowanego audytu bezpieczenstwa:

Security audit for two reported vulnerabilities:

1. Information disclosure: API error responses include stack traces and internal file paths in production. Find every error handler in src/routes/ and src/middleware/ that returns internal details. List the file, line number, and the exact data being leaked.

2. User enumeration: The password reset endpoint at POST /api/auth/reset-password returns different responses for existing vs non-existing email addresses. Find the handler and show me the response differentiation.

For each issue:
- Show the vulnerable code
- Propose a minimal fix
- Explain the security impact

Do NOT apply fixes yet. I need to review them first.

Krok 2: Kompleksowe skanowanie w rownoleglych worktree

Podczas gdy naprawiasz zgloszne problemy, uruchom rownolegle audyty bezpieczenstwa w worktree, aby wylapac podobne problemy w calej bazie kodu.

Worktree 1: Audyt walidacji danych wejsciowych

Audit every API endpoint in src/routes/ for input validation vulnerabilities:

1. SQL injection: any raw SQL or string interpolation in database queries
2. XSS: any user input rendered without sanitization
3. Path traversal: any file operations using user-provided paths
4. Command injection: any shell commands using user input
5. Mass assignment: any endpoints that pass request body directly to database updates

For each finding, report:
- File path and line number
- Severity (Critical, High, Medium, Low)
- Proof of concept showing how it could be exploited
- Recommended fix

Fix all Critical and High severity findings. Add input validation tests for each fix.
Run tests after all fixes to verify nothing broke.

Worktree 2: Audyt uwierzytelniania i autoryzacji

Audit the authentication and authorization system:

1. Check every protected route has auth middleware applied
2. Verify JWT token validation (algorithm, expiration, issuer)
3. Check for broken access control (user A accessing user B's resources)
4. Verify session management (token rotation, revocation, expiry)
5. Check password handling (hashing algorithm, salt, minimum complexity)
6. Verify rate limiting on auth endpoints (login, register, reset-password)
7. Check for timing attacks on login (constant-time comparison for passwords)

For each finding, report severity and recommended fix.
Fix Critical and High issues. Add tests for each fix.

Worktree 3: Audyt zaleznosci i konfiguracji

Audit dependencies and configuration for security issues:

1. Run npm audit and report all vulnerabilities with severity
2. Check for outdated dependencies with known CVEs
3. Verify no secrets in source code (API keys, passwords, tokens in .ts/.js files)
4. Check .env.example does not contain real values
5. Verify .gitignore covers sensitive files (.env, private keys, credentials)
6. Check HTTP security headers (CORS, CSP, HSTS, X-Frame-Options)
7. Verify TLS configuration if any

For dependencies with Critical or High vulnerabilities, update them if possible. If the update requires breaking changes, report what needs to change.

Krok 3: Dodaj wytyczne recenzji bezpieczenstwa do AGENTS.md

Po audycie skodyfikuj swoje standardy bezpieczenstwa, aby Codex wylapywal problemy na kazdym przyszlym PR:

## Review guidelines - Security

### P0 (Block merge)
- Raw SQL or string interpolation in database queries (use parameterized queries only)
- User input in shell commands, file paths, or eval() calls
- Missing authentication middleware on non-public endpoints
- Secrets, API keys, or credentials in source code
- Error responses that expose stack traces, file paths, or internal details

### P1 (Require fix before merge)
- Missing input validation on API endpoints
- Missing rate limiting on authentication endpoints
- Broken access control (user accessing another user's data)
- Insecure password handling (weak hashing, missing salt)
- Missing security headers in HTTP responses

Krok 4: Zautomatyzuj codzienne skanowanie bezpieczenstwa

Skonfiguruj automatyzacje uruchamiana codziennie, ktora raportuje wyniki do twojej skrzynki:

Wskazówka

Gotowy prompt automatyzacji do codziennego skanowania bezpieczenstwa:

Daily security scan:

1. Run npm audit and check for new vulnerabilities since yesterday
2. Scan for any new files containing patterns that look like secrets (API keys, tokens, passwords) using regex patterns for common secret formats
3. Check that all API endpoints added in the last 24 hours have:
   - Input validation
   - Authentication middleware (unless explicitly public)
   - Proper error handling that does not leak internals
4. Verify no new dependencies were added that have known Critical CVEs

If any issues are found, report them with file paths and severity.
If the scan is clean, report that no new security issues were detected.

Krok 5: Recenzja bezpieczenstwa na PR z @codex

Dla kazdego PR dotykajacego kodu wrazliwego na bezpieczenstwo uzyskaj automatyczna recenzje bezpieczenstwa na GitHub:

@codex review for security vulnerabilities and security concerns

Codex czyta diff PR, stosuje wytyczne bezpieczenstwa z twojego AGENTS.md i publikuje recenzje kodu skoncentrowana konkretnie na bezpieczenstwie. To wylapuje problemy zanim trafia do glownej galezi.

Dla zaplanowanych kompleksowych recenzji uzyj Codex GitHub Action:

name: Security review
on:
  pull_request:
    paths:
      - 'src/routes/**'
      - 'src/middleware/auth*'
      - 'src/lib/db/**'

jobs:
  security-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          prompt: |
            Review this PR specifically for security issues:
            - Input validation completeness
            - Authentication and authorization correctness
            - SQL injection or NoSQL injection risks
            - Sensitive data exposure in responses or logs
            - Dependency security (new packages with known vulnerabilities)
            Report only P0 and P1 security findings.
          sandbox: read-only

Gdy cos sie nie uda

Codex zglasza false positive. Skanowanie bezpieczenstwa ma wbudowany wskaznik false positive. Jesli Codex oznacza sparametryzowane zapytania jako ryzyko SQL injection, moze nie rozumiec zachowania escapowania ORM. Dolacz “Drizzle ORM queries are parameterized by default. Do not flag standard Drizzle .where() calls as SQL injection” w swoim AGENTS.md.

Automatyczne aktualizacje zaleznosci psuja build. Jesli Codex aktualizuje zaleznosc, aby naprawic CVE, a nowa wersja ma breaking changes, build nie przechodzi. Zawsze dolacz “run the full test suite after updating dependencies. If tests fail, report the failures instead of committing broken code” w swoim prompcie.

Codzienne skanowanie generuje za duzo szumu. Jesli kazde skanowanie raportuje te same 15 srednio krytycznych znalezisk npm audit, ktore juz przetriazowales, raporty staja sie bezuzyteczne. Dodaj uznane problemy do listy ignorowania i powiedz Codex: “Skip vulnerabilities listed in .security-ignore.json. Only report new findings.”

Srodowisko chmurowe pomija problemy bezpieczenstwa specyficzne dla srodowiska. Uniwersalny kontener chmurowy nie replikuje twojej infrastruktury produkcyjnej (load balancer, WAF, polityki sieciowe). Skanowania chmurowe wylapuja problemy na poziomie kodu, ale nie bezpieczenstwo na poziomie wdrozenia. Uzyj chmury do audytow kodu i uzupelniaj narzediami skanowania infrastruktury.

Co dalej

Optymalizacja wydajnosci Zoptymalizuj kod, ktory wlasnie zabezpieczyles, pod katem wydajnosci produkcyjnej

CI/CD z GitHub Action Codex Osadz skanowanie bezpieczenstwa w pipeline CI