ipIII nie konkuruje ze skanerami, SIEM ani GRC — zajmuje inną, wąską pozycję w tym samym łańcuchu: warstwę dowodowo-regulacyjną między narzędziami detekcji (pentest/AppSec) a zarządem, audytem i regulatorem. Ta strona uczciwie mapuje kategorię, wskazuje lukę rynkową w spięciu i pokazuje model szacunkowy wielkości rynku — jawnie oznaczony jako założenie, nie prognoza.
Nie zamiennik skanera, SIEM ani GRC — komplementarna warstwa, która spina to, czego żaden z nich osobno nie robi end-to-end: finding → dowód (hash + chain-of-custody) → właściciel → obowiązek regulacyjny (DORA/NIS2/AI Act, decision-support) → pakiet dla zarządu/audytora.
Poniższa tabela nie ocenia „lepszy/gorszy". Każda kategoria ma dojrzałą, osobną rolę. Kolumna „czego nie robi wobec ipIII" pokazuje granicę kompetencji — nie brak wartości danej kategorii.
| Kategoria narzędzi | Co robi (dojrzała rola) | Czego nie robi wobec ipIII | Relacja z ipIII |
|---|---|---|---|
| Skanery (Burp/Nessus/Qualys/ZAP) | Aktywnie wykrywa podatności aplikacji/API/infrastruktury. | Nie tworzy trwałego dowodu integralności, nie przypisuje właściciela, nie mapuje na obowiązek regulacyjny, nie generuje pakietu dla zarządu. | Źródło importu (/imports/burp, /imports/nessus, /imports/zap) — komplementarne, szczegóły: /porownanie-vs-scanners. |
| SIEM (Splunk/Sentinel/QRadar) | Detekcja zdarzeń w czasie rzeczywistym, korelacja logów, alerting operacyjny SOC. | Nie prowadzi formalnego workflow dowodu naprawy end-to-end, nie mapuje incydentu na terminy DORA/NIS2, nie buduje board packu dla regulatora. | Docelowe źródło strumienia zdarzeń (konektor ROADMAP S5) — dziś ingest przez plik/webhook. Szczegóły: /porownanie-vs-siem. |
| GRC (ServiceNow/Archer) | Zarządzanie ryzykiem organizacyjnym, rejestry polityk, kwestionariusze audytowe, workflow zatwierdzeń na poziomie zarządu. | Nie łączy się bezpośrednio z technicznym dowodem naprawy pojedynczego findingu (hash, chain-of-custody) ani z surowym importem skanera. | Konsument wyjścia ipIII (evidence-package, mapowanie controls) jako wejście do rejestru ryzyka. Szczegóły: /porownanie-vs-grc. |
| DefectDojo (vuln management) | Agreguje findingi z wielu skanerów, deduplikacja, śledzenie statusu podatności w czasie. | Nie generuje pakietu dowodowego z podpisem/hash dla regulatora, nie ma natywnego mapowania na DORA/NIS2/AI Act, nie obejmuje bezpieczeństwa agentów AI. | Źródło importu (/imports/defectdojo) traktowane jako most AppSec — dane z DefectDojo wzbogacane o evidence-package i legal triggers. |
| ipIII (Evidence Operating Layer) | Spina finding z każdej z powyższych kategorii w jeden łańcuch: import → evidence (hash+chain-of-custody) → owner → retest → mapowanie regulacyjne → board pack. | Nie skanuje, nie koreluje logów w czasie rzeczywistym, nie zarządza pełnym rejestrem ryzyka organizacyjnego samodzielnie — celowo, żeby nie duplikować dojrzałych rynków. | — |
Skaner, SIEM i GRC to trzy osobne systemy z osobnymi bazami danych. Przejście od „znaleziono podatność" do „zarząd/regulator ma dowód naprawy" dziś zwykle wymaga ręcznego składania arkuszy, maili i slajdów — proces podatny na utratę kontekstu i brak dowodu integralności.
Ani skaner, ani SIEM, ani GRC nie prowadzi natywnie łańcucha: finding → hash + chain-of-custody → właściciel + SLA → mapowanie DORA/NIS2/AI Act → pakiet PDF/JSON dla zarządu z jednym package_sha256.
Żadna z trzech dojrzałych kategorii nie została zbudowana pod chain-of-custody działań agenta AI ani inwentaryzację narzędzi MCP — to nowy wymiar ryzyka, rosnący równolegle z regulacją AI Act.
DORA/NIS2/AI Act wymagają dowodu i terminowości, nie tylko wykrycia. Skaner/SIEM/GRC osobno nie łączą technicznego dowodu z zegarem regulacyjnym w jednym rekordzie.
Trzy elementy, które osobno istnieją na rynku we fragmentach, są w ipIII spięte w jeden rekord dowodowy:
13 konektorów/parserów (Burp, ZAP, Nessus, Qualys, CSV, DefectDojo, SARIF, SBOM, secrets, cloud posture, RE, generic, dedup) → evidence z sha256 i chain-of-custody w PostgreSQL. LIVE
Warstwa bezpieczeństwa agentów AI (inwentaryzacja/wykrywanie zatruwania narzędzi MCP) jako odrębna linia produktowa (F9) — dziś częściowo MVP/ROADMAP, patrz /dev-api-reference sekcja 6.
Legal Trigger Engine mapuje incydent na obowiązki DORA/NIS2/RODO/AI Act i zegary terminów. Decision-support, nie porada prawna — wymaga przeglądu prawnika/DPO przed wysyłką do organu. LIVE
Poniższe liczby pochodzą bezpośrednio z repozytorium — nie są elementem modelu rynkowego z sekcji 5. Źródło weryfikacji: /dev-api-reference (referencja techniczna) i /pages.json (rejestr stron modułu). Data: 2026-07-05.
routes/ip3-*.js, status per moduł w dev-api-reference| Warstwa | Definicja | Założenie (ilustracyjne) | Podstawa założenia / źródło |
|---|---|---|---|
| TAM total addressable |
Cały rynek narzędzi security+GRC+compliance software (skanery, SIEM, GRC, vuln management łącznie). | Rząd wielkości: rynek liczony globalnie w miliardach USD rocznie w tych segmentach łącznie (bez precyzyjnej sumy). | Ogólnie cytowane, publicznie dostępne kategorie rynkowe (AppSec/vuln mgmt, SIEM/SOC, GRC) — K0NSULT nie prowadzi własnego, niezależnego badania rynkowego tej liczby. |
| SAM serviceable |
Podzbiór TAM: organizacje w UE objęte reżimami wymagającymi dowodu i terminowości (DORA/NIS2/AI Act high-risk) i rozważające warstwę evidence-ops ponad istniejący stos narzędzi. | Rząd wielkości: dziesiątki tysięcy podmiotów finansowych i „kluczowych/ważnych" w UE objętych DORA/NIS2 (transpozycje krajowe różnią się zakresem i tempem). | Publicznie dyskutowane szacunki zakresu DORA (podmioty finansowe) i NIS2 (podmioty kluczowe/ważne) w konsultacjach sektorowych UE — orientacyjne, do weryfikacji przez klienta/analityka, nie potwierdzone niezależnie przez K0NSULT. |
| SOM obtainable |
Realistycznie osiągalny segment w perspektywie pierwszych wdrożeń: banki/fintechy/zespoły pentesterskie już w pipeline pilotażowym, sektor regulowany w Polsce/UE. | Bez liczby — SOM w tej fazie definiowany jakościowo: liczba aktywnych pilotów i partnerów pentesterskich (patrz /pilot-intake), nie liczba klientów płacących. | Wewnętrzny pipeline K0NSULT (piloty 5-day/30-day, model współpracy w /pricing) — nie ekstrapolacja rynkowa, tylko stan faktyczny rozmów. |
Ten model nie jest używany do wyceny spółki ani do żadnego zobowiązania wobec inwestora czy klienta. Jego jedyny cel: pokazać jawnie, jak K0NSULT myśli o wielkości szansy — z zaznaczonym poziomem niepewności każdego założenia.
ipIII nie wymaga wymiany istniejącego skanera, SIEM ani GRC — integruje się jako warstwa nad nimi. Ocena wdrożenia zaczyna się od pilotu na danych syntetycznych/zanonimizowanych: /pilot-intake.
Teza inwestycyjna to „luka w spięciu", nie „jedyny gracz na rynku". Model rynku w sekcji 5 jest jawnie oznaczony jako szacunkowy — należyta staranność wymaga własnej weryfikacji założeń, nie polegania wyłącznie na tej stronie.
Status każdego elementu produktu (LIVE/MVP/ROADMAP) jest jawny i zweryfikowalny w /dev-api-reference, /pages.json oraz /known-limitations. Zaufanie i bezpieczeństwo operacyjne opisane w /trust-center.
Przykład końcowego artefaktu, który ipIII generuje z realnego incydentu: /pentest-report-board-pack — pentest report → board pack w kilka minut.
Powiązane: pełna analiza porównawcza per kategoria → /porownanie · referencja techniczna API/konektorów → /dev-api-reference · rejestr stron modułu → /pages.json · znane ograniczenia → /known-limitations · trust center → /trust-center · modele współpracy → /pricing · pilot intake → /pilot-intake.