Wprost: ipIII nie jest skanerem i nie stara się nim być. Burp Suite, OWASP ZAP, Nessus i Qualys znajdują podatności — to ich rzemiosło, dojrzałe, przetestowane w tysiącach wdrożeń. ipIII zaczyna pracę po skanie: bierze wynik i orkiestruje dowód — import → evidence → owner → retest → board pack. Ta strona pokazuje uczciwie, gdzie kończy się rola skanera, gdzie zaczyna rola ipIII i które elementy skaner robi lepiej i będzie robić lepiej.
Skaner produkuje raport z listą znalezisk. Bez dalszego workflow raport ląduje w pliku, ginie kontekst właściciela,
terminu i dowodu naprawy. ipIII importuje ten raport i prowadzi go dalej: normalizuje ważność, tworzy evidence-package
z sha256 i chain-of-custody, przypisuje właściciela, pilnuje retestu i buduje pakiet dla zarządu/audytora.
Poniższa tabela nie ocenia „lepszy/gorszy" — pokazuje inny etap tego samego procesu. Kolumna „gdzie się uzupełniają" jest sednem tej strony: to właśnie tam ipIII dodaje wartość, bez dotykania kompetencji skanera.
| Skaner (Burp/ZAP/Nessus/Qualys) | ipIII | Gdzie się uzupełniają |
|---|---|---|
| Aktywnie skanuje aplikację/API (Burp, ZAP) lub infrastrukturę/CVE (Nessus, Qualys) i wykrywa podatności. | Nie skanuje. Importuje plik wyjściowy skanera (Burp XML, ZAP JSON/XML, Nessus/Qualys CSV, generic CSV/JSON). | Skaner musi zadziałać pierwszy — ipIII zaczyna dopiero po jego wyniku. Bez skanera ipIII nie ma czym się zająć. |
| Nadaje własną skalę ważności (np. Critical/High/Medium/Low, CVSS). | Normalizuje różne skale skanerów do jednej wspólnej: P0–P3. | Zespół bezpieczeństwa dostaje jedną wspólną skalę mimo różnych narzędzi wejściowych — bez ipIII trzeba to robić ręcznie w arkuszu. |
| Raport jest plikiem (XML/JSON/CSV/PDF) — statycznym zrzutem stanu w momencie skanu. | Zamienia znalezisko w incydent + evidence-package z sha256 i zapisem chain-of-custody w PostgreSQL. |
Plik skanera nie ginie w poczcie/dysku — trafia do jednego rejestru z dowodem integralności i historią zmian statusu. |
| Nie zna organizacyjnego kontekstu — nie wie, kto ma naprawić ani do kiedy. | Przypisuje właściciela (owner) i termin naprawy do każdego znaleziska. | Skaner dostarcza fakty techniczne; ipIII dokłada warstwę odpowiedzialności organizacyjnej, której skaner z definicji nie modeluje. |
| Kolejny skan może (czasem) pokazać, że podatność zniknęła — ale bez formalnego łańcucha dowodowego „naprawiono, bo...". | Prowadzi retest ze statusem CONFIRMED przed zamknięciem (close-with-evidence). | Ponowny skan skanerem może być właśnie dowodem retestu importowanym do ipIII — obie strony współpracują, nie konkurują. |
| Raport techniczny — czytelny dla inżyniera, rzadko gotowy „na biurko" CISO czy regulatora. | Generuje evidence-package / board pack (JSON + PDF, manifest + package_sha256) dla zarządu/audytu. |
Techniczne dane skanera stają się materiałem wejściowym do czytelnego, dowodowego pakietu decyzyjnego. |
| Ma bogatą, stale aktualizowaną bibliotekę sygnatur/pluginów i silnik testowy rozwijany od lat. | Nie posiada i celowo nie buduje własnego silnika skanującego. | Brak — to obszar wyłącznej kompetencji skanera. ipIII świadomie tego nie duplikuje (patrz sekcja 2). |
Burp/ZAP mają lata rozwoju silników fuzzingu, pasywnego i aktywnego skanowania web/API. Nessus/Qualys mają ogromne, codziennie aktualizowane biblioteki wtyczek CVE. To dojrzałość, której nowy produkt nie odtworzy szybko — i nie próbuje.
Bazy CVE/wtyczek Nessus/Qualys są aktualizowane wielokrotnie dziennie przez zespoły producentów. ipIII dziś wzbogaca CVE offline (hint z seedu) — świeżość online jest jawnie oznaczona jako ROADMAP w rejestrze ograniczeń.
Skanery komercyjne mają dojrzałe API, pluginy CI/CD, community i lata feedbacku od tysięcy klientów. To przewaga skali, której młodszy produkt nie posiada — i nie udaje, że posiada.
Burp Suite Professional czy ZAP mają rozbudowane moduły (np. testy sesji, logiki biznesowej, aktywne ataki fuzzingowe) rozwijane latami przez wyspecjalizowane zespoły. ipIII nie próbuje konkurować w tej niszy.
Każde znalezisko po imporcie ma hash sha256 i chain-of-custody — dowód integralności, nie tylko treść raportu.
Znalezisko bez właściciela i terminu ginie w skrzynce. ipIII wiąże je z odpowiedzialnością i wymusza dowód naprawy przed zamknięciem.
Burp + ZAP + Nessus + Qualys + CSV/JSON trafiają do jednej wspólnej skali P0–P3 i jednego rejestru — zamiast czterech osobnych arkuszy.
Pakiet PDF/JSON gotowy do przekazania zarządowi lub audytorowi — z manifestem i package_sha256, bez ręcznego składania slajdów.
Legal Trigger Engine (decision-support, nie porada prawna) łączy incydent z terminami DORA/NIS2/RODO/AI Act — czego żaden skaner nie robi.
Tam, gdzie ipIII czegoś jeszcze nie robi (np. świeże online CVE lookup), mówimy to wprost — patrz znane ograniczenia.
Import parserów Burp/ZAP/Nessus/Qualys/CSV/JSON, normalizacja P0–P3, evidence-package z hash i chain-of-custody, retest→close-with-evidence oraz board pack (JSON+PDF) są oznaczone jako MVP — działają na żywej PostgreSQL, z dowodem w testach integracyjnych na środowisku staging. Świeże online wzbogacanie CVE (NVD/CISA KEV/EPSS w czasie rzeczywistym), własny silnik skanujący czy podpis PAdES pakietu są jawnie ROADMAP — nieistniejące dziś, nie ukrywane jako gotowe.
Konektory i formaty importu opisane technicznie: /ai-truth/ipIII/connectors. Syntetyczne przykłady plików wejściowych i wyjściowych (bez logowania): /ai-truth/ipIII/samples. Kalkulator pokrycia dowodowego: /ai-truth/ipIII/coverage-score. Szersza analiza pozycjonowania wobec całego ekosystemu narzędzi bankowych (VMDR/DAST/BAS/SIEM/GRC i inne, nie tylko skanery): /ai-truth/ipIII/porownanie.
Powiązane: pełna analiza porównawcza ekosystemu narzędzi bankowych → /porownanie · rejestr znanych ograniczeń → /known-limitations · macierz statusów → /status-matrix.