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."

Perform a dependency security audit:
1. Analyze all dependencies for known vulnerabilities
2. Trace each vulnerability to determine if it's reachable in our code
3. Generate safe dependency upgrades
4. Run the test suite after upgrades to verify nothing broke
5. Create a PR with the fixes and an audit report

Prioritize exploitable vulnerabilities over theoretical ones.

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 "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.
        Output JSON: {found: boolean, secrets: [{type, file, line}]}
        Exit 1 if any secrets found."
    - name: Security review
      run: |
        claude -p "Review changed files for security vulnerabilities:
        $(git diff --name-only origin/main...HEAD)
        Focus on: injection, auth bypass, IDOR, XSS.
        Output JSON with severity ratings. Exit 1 if critical issues found."

Skonfiguruj Codex do automatycznego przeglądu bezpieczeństwa na PR:

When reviewing PRs, check for security issues:
1. Scan changed files for common vulnerability patterns
2. Check new dependencies against vulnerability databases
3. Verify authentication on new endpoints
4. Flag any secrets or credentials in the diff
5. Post findings as PR review comments with severity labels

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.