Skanowanie bezpieczeństwa i testowanie podatności

Twój audyt zależności pokazuje 14 podatności o wysokim poziomie istotności, z czego trzy są w pakietach importowanych bezpośrednio, a jedenaście jest tranzytywnych. Zespół bezpieczeństwa chce planu naprawczego do piątku. Możesz spędzić dwa dni czytając raporty CVE i śledząc łańcuchy zależności, albo możesz pozwolić narzędziu AI przeanalizować całe drzewo zależności, ocenić które podatności są faktycznie eksploatowalne w Twoim codebase, i wygenerować priorytetyzowany plan naprawczy w 30 minut.

Czego się nauczysz

Zautomatyzowane workflow skanowania OWASP Top 10 zintegrowane z Twoim cyklem deweloperskim
Audyt podatności zależności z oceną ryzyka wspomaganą AI
Wzorce promptów do przeglądu kodu skoncentrowanego na bezpieczeństwie łapiącego prawdziwe zagrożenia
Integracja z pipeline’em CI dla ciągłego skanowania bezpieczeństwa
Wzorce testów penetracyjnych, które deweloperzy mogą uruchamiać bez ekspertyzy bezpieczeństwa

Zautomatyzowane skanowanie OWASP Top 10

Prompt do skopiowania — skanowanie OWASP:

Perform a security audit of /src/api/ against the OWASP Top 10 (2021):

For each vulnerability category, check EVERY file in the directory:

A01 Broken Access Control:
- Are all routes protected by authentication middleware?
- Do endpoints check authorization (not just authentication)?
- Can users access other users' resources by changing IDs in the URL?

A02 Cryptographic Failures:
- Are passwords hashed with bcrypt/argon2 (not MD5/SHA1)?
- Are API tokens generated with cryptographically secure randomness?
- Is sensitive data encrypted at rest in the database?

A03 Injection:
- Are ALL database queries parameterized (no string concatenation)?
- Is user input validated and sanitized before processing?
- Are file paths validated to prevent path traversal?

For each finding, provide:
- Severity: Critical / High / Medium / Low
- Exact file and line number
- The vulnerable code snippet
- A concrete fix (not generic advice)
- A test case that would catch this vulnerability

Zarządzanie podatnościami zależności

Audit our project dependencies for security vulnerabilities:

1. Run npm audit and analyze the results
2. For each high/critical vulnerability:
   - Is it in a direct dependency or transitive?
   - Is the vulnerable code path actually reachable in our application?
   - What is the fix (upgrade, replace, or accept risk)?
3. Create a prioritized remediation plan:
   - P0: Exploitable in our code, fix immediately
   - P1: Potentially exploitable, fix this sprint
   - P2: Not exploitable but should fix for hygiene
   - P3: Accept risk with documentation

Check package-lock.json for the full dependency tree.
Show the upgrade path for each fixable vulnerability.

claude "Run a complete dependency security audit:
1. Execute: npm audit --json > /tmp/audit.json
2. Analyze the results and categorize by exploitability
3. For each critical/high finding, check if our code actually calls
   the vulnerable function (trace the import chain)
4. Generate a fix script that upgrades safe dependencies
5. For breaking upgrades, document what changes are needed
6. Create a summary report in /docs/security-audit.md

Run the fix script after generating it. Verify the build still passes."

Prompt audytu jest taki sam jak w pozostałych narzędziach — różni się tylko powierzchnia. Uruchom go headless w CI przez codex exec albo odpal jako zadanie Codex Cloud, które otworzy PR z poprawkami:

codex exec --sandbox workspace-write \
  "Perform a dependency security audit:
  1. Run: npm audit --json
  2. Trace each high/critical vuln to determine if it's reachable in our code
  3. Generate safe dependency upgrades and apply them
  4. Run the test suite after upgrades to verify nothing broke
  5. Write an audit report to docs/security-audit.md

  Prioritize exploitable vulnerabilities over theoretical ones."

Na powierzchni Cloud/IDE skieruj to samo zadanie na gałąź i pozwól Codeksowi otworzyć PR naprawczy do przeglądu.

Aby uzyskać statyczną analizę na poziomie AST zamiast przeglądu opartego wyłącznie na promptach, dodaj serwer Semgrep MCP (GitHub: semgrep/mcp). Pozwala on agentowi uruchamiać prawdziwe reguły Semgrep na Twoim diffie — wyłapując przepływy taint i sinki injection, które skan promptem pomija — a następnie dostrajasz zestaw reguł, zanim oprzesz na nim bramkę CI. To serwer zdalny/Python (uruchamiany przez uvx semgrep-mcp lub hostowany endpoint), a nie pakiet npm, i działa identycznie w Cursor, Claude Code i Codex. Do szybkiej selekcji wybierz podejście oparte tylko na promptach; po powtarzalne, oparte na regułach skanowanie sięgnij po Semgrep MCP. Lżejszą alternatywą jest Agent Skill semgrep (npx skills add trailofbits/skills), który uczy agenta obsługi Semgrep CLI bez utrzymywania trwałego połączenia z serwerem.

Przegląd kodu skoncentrowany na bezpieczeństwie

Prompt do skopiowania — przegląd bezpieczeństwa kodu:

Review this pull request as a security engineer. You are looking for vulnerabilities
that could be exploited by a malicious user, not code style issues.

Check specifically for:
1. SQL injection: Any query built with string concatenation or template literals?
2. XSS: Any user input rendered without escaping?
3. CSRF: Any state-changing endpoint missing CSRF protection?
4. Auth bypass: Any endpoint that checks authentication but not authorization?
5. IDOR: Can a user access resources by guessing/iterating IDs?
6. Mass assignment: Are request bodies validated or passed directly to the database?
7. Rate limiting: Are sensitive endpoints (login, password reset) rate-limited?
8. Information disclosure: Do error responses leak internal details?
9. File upload: Are uploaded files validated for type, size, and content?
10. Secrets: Are any API keys, tokens, or credentials hardcoded?

For each finding, rate the severity and provide an exploit scenario:
"An attacker could... by sending this request: ..."

Integracja bezpieczeństwa z pipeline’em CI

Użyj Background Agent do uruchamiania sprawdzań bezpieczeństwa przed push:

Before I push this branch, run a security checklist:
1. npm audit - any new vulnerabilities introduced?
2. Check the diff for hardcoded secrets (API keys, passwords, tokens)
3. Verify all new API endpoints have authentication middleware
4. Check that no new SQL queries use string interpolation
5. Verify new dependencies are from trusted publishers

If any check fails, tell me what to fix before pushing.

Zintegruj z CI w trybie headless:

security-scan:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - run: npm ci
    - name: Dependency audit
      run: npm audit --audit-level=high
    - name: Secret scanning
      run: |
        claude -p --output-format json \
        --json-schema '{"type":"object","properties":{"found":{"type":"boolean"},"secrets":{"type":"array","items":{"type":"object","properties":{"type":{"type":"string"},"file":{"type":"string"},"line":{"type":"integer"}}}}},"required":["found","secrets"]}' \
        "Scan the git diff for secrets, credentials, or API keys:
        $(git diff origin/main...HEAD)
        Check for: AWS keys (AKIA), GitHub tokens (ghp_), generic API keys,
        passwords in config files, private keys, connection strings with passwords." \
        | jq -e '.found == false'
    - name: Security review
      run: |
        claude -p --output-format json \
        "Review changed files for security vulnerabilities:
        $(git diff --name-only origin/main...HEAD)
        Focus on: injection, auth bypass, IDOR, XSS.
        Output a JSON array of findings with severity ratings."

Użycie --output-format json (oraz --json-schema dla skanu sekretów) daje Twojemu wrapperowi CI wyjście zwalidowane schematem, na którym możesz oprzeć bramkę przez jq, zamiast ufać, że model sformatuje obiekt w bloku inline.

W Codex Cloud skonfiguruj automatyzację przeglądu, która uruchamia się na każdym PR — przegląda diff i publikuje znaleziska jako komentarze PR z etykietami istotności, bez żadnego skryptu-wrappera. Dla self-hosted runnera odwzoruj zadanie Claude Code za pomocą headless codex exec:

# .github/workflows/security.yml (wariant Codex)
- name: Codex security review
  run: |
    codex exec --sandbox read-only --json \
      --output-schema .github/sec-schema.json \
      "Review the changed files ($(git diff --name-only origin/main...HEAD))
      for injection, auth bypass, IDOR, XSS, and hardcoded secrets.
      Return findings with severity ratings." \
      | jq -e 'all(.findings[]; .severity != "critical")'

Prompt jest identyczny jak w zadaniu Claude Code; różnią się tylko powierzchnia CLI i flaga schematu (--output-schema zamiast --json-schema).

Wzorce testów penetracyjnych

Prompt do skopiowania — testy penetracyjne API:

Generate penetration test cases for our REST API. For each endpoint in /src/api/routes/:

1. Authentication bypass:
   - Send requests without Authorization header
   - Send expired/malformed JWT tokens
   - Send tokens from a different user

2. Authorization testing:
   - Access admin endpoints with regular user token
   - Access other users' resources by changing IDs
   - Try privilege escalation by modifying role in the request body

3. Input validation:
   - Send oversized payloads (> 1MB body)
   - Send malformed JSON
   - Send unexpected types (number where string expected)
   - Send SQL injection payloads in every string field
   - Send XSS payloads in every string field

4. Rate limiting:
   - Send 100 requests in 1 second to login endpoint
   - Verify rate limit headers are returned
   - Verify the limit actually blocks requests

Generate as a Playwright API test suite with clear pass/fail criteria.
Save to /tests/security/api-pentest.spec.ts

Gdy coś się zepsuje

“npm audit pokazuje podatności, ale nie możemy aktualizować bez breaking changes.” Użyj npm audit --omit=dev aby filtrować tylko do zależności produkcyjnych. Dla podatności tranzytywnych sprawdź, czy podatna ścieżka jest osiągalna. Użyj npm audit fix --force z ostrożnością i solidnym zestawem testów jako siatka bezpieczeństwa.

“Skany bezpieczeństwa produkują zbyt wiele false positive.” Dostosuj reguły skanowania. Wyłącz pliki testowe, dane mockowe i dokumentację ze skanów bezpieczeństwa. Dostosuj prompt AI do “only report vulnerabilities that could be exploited with a concrete attack scenario, not theoretical issues.”

“Deweloperzy opierają się testowaniu bezpieczeństwa, bo ich spowalnia.” Zrób skanowanie bezpieczeństwa niewidocznym. Uruchamiaj je w CI, nie jako ręczny krok. Blokuj PR-y tylko dla problemów o istotności krytycznej i wysokiej. Pozwól, aby problemy o istotności średniej i niskiej gromadziły się w backlogu bezpieczeństwa przeglądanym miesięcznie.

“Nie mamy ekspertyzy bezpieczeństwa w zespole.” Dokładnie tutaj AI świetnie sobie radzi. Prompty w tym przewodniku kodują ekspertyzę bezpieczeństwa w powtarzalny proces. Zacznij od skanu OWASP Top 10 i audytu zależności — łapią one najczęstsze podatności z minimalną wymaganą ekspertyzą.

Co dalej

Security Compliance Enterprise security standards and regulatory compliance.

CI/CD Pipelines Integrate security gates into your deployment pipeline.

API Testing Functional API testing alongside security testing.