Skanowanie bezpieczeństwa z Codex

Badacz bezpieczeństwa właśnie złożył raport w ramach odpowiedzialnego ujawniania: twoje API zwraca wewnętrzne szczegóły błędów w odpowiedziach produkcyjnych, a flow resetowania hasła jest podatny na ataki enumeracyjne. Masz 48 godzin zanim raport stanie się publiczny. Musisz zaudytować całą bazę kodu pod kątem podobnych problemów, naprawić zgłoszone, i skonfigurować ciągłe skanowanie, aby to się nie powtórzyło. Codex może skanować bazę kodu z wielu kątów jednocześnie, naprawić krytyczne problemy i zautomatyzować bieżące monitorowanie bezpieczeństwa.

Co wyniesiesz z tej lekcji

• Prompty do kompleksowych audytów bezpieczeństwa obejmujących trasy API, uwierzytelnianie i obsługę danych
• Workflow równoległego skanowania za pomocą worktree do audytu różnych domen bezpieczeństwa jednocześnie
• Wytyczne recenzji AGENTS.md wyłapujące problemy bezpieczeństwa na każdym PR
• Przepis na automatyzację codziennych skanowań bezpieczeństwa

Workflow

Krok 1: Przeprowadź natychmiastowy audyt

Dla zgłoszonych problemów użyj CLI do szybkiego, ukierunkowanego badania:

Wskazówka

Gotowy prompt do celowanego audytu bezpieczeństwa:

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 równoległych worktree

Podczas gdy naprawiasz zgłoszone problemy, uruchom równoległe audyty bezpieczeństwa w worktree, aby wyłapać podobne problemy w całej bazie kodu.

Worktree 1: Audyt walidacji danych wejściowych

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 zależności 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 bezpieczeństwa do AGENTS.md

Po audycie skodyfikuj swoje standardy bezpieczeństwa, aby Codex wyłapywał problemy na każdym przyszłym 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 bezpieczeństwa

Skonfiguruj automatyzację uruchamianą codziennie, która raportuje wyniki do twojej skrzynki:

Wskazówka

Gotowy prompt automatyzacji do codziennego skanowania bezpieczeństwa:

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 bezpieczeństwa na PR z @codex

Dla każdego PR dotykającego kodu wrażliwego na bezpieczeństwo uzyskaj automatyczną recenzję bezpieczeństwa na GitHub:

@codex review for security vulnerabilities and security concerns

Codex czyta diff PR, stosuje wytyczne bezpieczeństwa z twojego AGENTS.md i publikuje recenzję kodu skoncentrowaną konkretnie na bezpieczeństwie. To wyłapuje problemy zanim trafią do głównej gałęzi.

Dla zaplanowanych kompleksowych recenzji użyj 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 coś się nie uda

Codex zgłasza false positive. Skanowanie bezpieczeństwa ma wbudowany wskaźnik false positive. Jeśli Codex oznacza sparametryzowane zapytania jako ryzyko SQL injection, może nie rozumieć zachowania escapowania ORM. Dołącz “Drizzle ORM queries are parameterized by default. Do not flag standard Drizzle .where() calls as SQL injection” w swoim AGENTS.md.

Automatyczne aktualizacje zależności psują build. Jeśli Codex aktualizuje zależność, aby naprawić CVE, a nowa wersja ma breaking changes, build nie przechodzi. Zawsze dołącz “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 dużo szumu. Jeśli każde skanowanie raportuje te same 15 średnio krytycznych znalezisk npm audit, które już przetriażowałeś, raporty stają się bezużyteczne. Dodaj uznane problemy do listy ignorowania i powiedz Codex: “Skip vulnerabilities listed in .security-ignore.json. Only report new findings.”

Środowisko chmurowe pomija problemy bezpieczeństwa specyficzne dla środowiska. Uniwersalny kontener chmurowy nie replikuje twojej infrastruktury produkcyjnej (load balancer, WAF, polityki sieciowe). Skanowania chmurowe wyłapują problemy na poziomie kodu, ale nie bezpieczeństwo na poziomie wdrożenia. Użyj chmury do audytów kodu i uzupełniaj narzędziami skanowania infrastruktury.

Co dalej

Optymalizacja wydajności Zoptymalizuj kod, który właśnie zabezpieczyłeś, pod kątem wydajności produkcyjnej

CI/CD z GitHub Action Codex Osadź skanowanie bezpieczeństwa w pipeline CI