ptai-v2

Fork ptai 1.2.1 — rozwijany samodzielnie. Determinystyczny rdzeń skanera + skrypty równoległe.

Dlaczego fork (audyt 2026-08-22)

ptai 1.2.1 miał 7 udokumentowanych wad (docs/audyt-ptai.md):

1. predykaty trafień = sam status HTTP (false positives),
2. http_post_json bez allow_redirects=False (200 z redirectu = "hit"),
3. brak fingerprintingu (Juice Shop payloady strzelane do Apache),
4. native probes exempt z prove-or-kill,
5. raport ubogi (bez dowodów/CVSS/coverage),
6. brak macierzy "co przetestowano",
7. LLM w wyborze akcji = losowość.

Architektura (engine2/)

scanner.py     orchestrator: fingerprint → fazy → parse → probes → raport
http_client.py warstwa HTTP redirect-aware (is_login, hops, allow_redirects=False)
fingerprint.py sygnatury aplikacji → gating probe'ów (business_logic tylko e-commerce)
matrix.py      macierz 50 narzędzi per faza (budżety, capy)
runner.py      równoległy runner (Semaphore(8), subprocess bez shella, timeout+kill)
probes_v2.py   deterministyczne probe'y z dowodami (hit_on_real_response)
report_v2.py   raport v2: Exec Summary (Hetzner narracja), metodologia+coverage,
               severity+CVSS/CWE, findings z dowodem, raw appendix

LLM (Hetzner Qwen3.6-35B) używany TYLKO do narracji executive summary. Rdzeń jest w 100% deterministyczny.

Użycie

python -m engine2.scanner https://cel.pl --out raport.md

Wymagane: aiohttp (venv-spider lub venv ptai). Narzędzia skanujące z PATH (subfinder, naabu, nmap, ffuf, nuclei, ...).

Decyzje projektowe

• Forma: fork w repo peer-karo/ptai-v2 na Forgejo (xanadu:3000).
• LLM: deterministyczny rdzeń + Hetzner tylko do narracji (rekomendacja operatora).
• Testowanie: bez labu — od razu na strukturze firmowej (prod, autoryzowane).