ipIII (Evidence & Resilience Orchestrator) to warstwa dowodowo-regulacyjna — łącznik między technicznymi wynikami pentestu/AppSec/SOC a tym, czego potrzebują zarząd, audyt i regulator: uporządkowanym, weryfikowalnym dowodem, a nie kolejnym plikiem CSV. Ta strona pokazuje, co to jest, dlaczego wypełnia realną lukę i dla kogo jest przeznaczony — w oparciu o liczby, które można sprawdzić w kodzie.
/api/ip3/ssot — nie powinny się rozjeżdżać.
/api/ip3/ssot i weryfikowalne na żywych rejestrach — /pages.json
i /dev-api-reference. Wszelkie wzmianki o rynku, wielkości
popytu czy potencjalnym przychodzie są oznaczone osobno jako model szacunkowy — założenie do
dyskusji, nie prognoza ani zobowiązanie. Regulacje (DORA/NIS2/RODO/AI Act) omawiamy w trybie
decision-support: ostateczna kwalifikacja prawna należy do radcy prawnego/DPO klienta.
Skanery (SAST/DAST/SCA), pentesty i SIEM produkują findingi. Systemy GRC produkują rejestry
ryzyka i polityki. Między tymi dwoma światami jest luka: nikt domyślnie nie przekłada pojedynczego findingu
na dowód zamknięty w czasie, powiązany z konkretnym obowiązkiem regulacyjnym, gotowy do pokazania
audytorowi czy nadzorcy. ipIII spina ten przepływ: import → incydent → evidence-package → retest →
close, z chain-of-custody i hash-em integralności na każdym kroku.
Żadne z istniejących narzędzi nie robi tego samo z siebie:
Dają finding techniczny (CVE, podatność, exploit path). Nie mówią, który obowiązek regulacyjny naruszają ani czy dowód przetrwa kontrolę.
Widzi zdarzenia w czasie rzeczywistym. Nie buduje spójnego pakietu dowodowego z chain-of-custody dla pojedynczego incydentu na potrzeby audytu.
Zarządza rejestrem ryzyka i politykami na poziomie organizacji. Zwykle nie sięga do granularnego dowodu technicznego (który konkretnie test, retest, hash pliku).
Łączy finding z obowiązkiem i z dowodem: coverage score, evidence-package z hash-em i podpisem, mapowanie na DORA/NIS2/AI Act, gotowy Board Pack dla zarządu.
Innymi słowy: ipIII to komplementarna, nowa kategoria w łańcuchu bezpieczeństwo→zgodność, a nie konkurent Burp Suite, Nessusa, SIEM-u czy klasycznego GRC. Działa na wyjściu z tych narzędzi (import ich wyników) i na wejściu do zarządu/audytu/regulatora (evidence-package, Board Pack).
| Segment | Kontekst regulacyjny | Co dostaje z ipIII |
|---|---|---|
| Korporacje finansowe | DORA (operational resilience) | Mapowanie incydentu na wymogi DORA, evidence-package na potrzeby testów odporności operacyjnej i TIBER-owych ćwiczeń — jako decision-support, nie jako zapewnienie zgodności. |
| Podmioty krytyczne | NIS2 | Rejestr incydentu z chain-of-custody spójny z obowiązkami zgłoszeniowymi NIS2; Legal Trigger Engine podpowiada terminy — do weryfikacji przez compliance/prawnika. |
| Dostawcy i użytkownicy AI | AI Act | AI-risk pack: rejestr agentów, ślad nadzoru człowieka, inwentarz ryzyka modeli — warstwa dowodowa pod klasyfikację i obowiązki AI Act (MVP, część modułów ROADMAP). |
| Firmy cyber / pentest / MSSP | dostawa usługi klientowi | Import wyników własnych narzędzi (Burp, Nessus, DefectDojo, SARIF, SBOM) i automatyczne złożenie ich w Board Pack — mniej ręcznej pracy przy raportowaniu do klienta. |
| CISO / audyt wewnętrzny / compliance / DPO | nadzór i rozliczalność | Jeden punkt prawdy o statusie dowodów (coverage score, verify hash+podpis) zamiast rozproszonych arkuszy i maili między zespołami. |
Poniższe liczby modułu (strony, endpointy, parsery, moduły, narzędzia MCP) wczytywane są z
/api/ip3/ssot, endpointu który liczy je bezpośrednio z plików repo przy każdym wywołaniu — nie są
wpisane ręcznie do treści strony. Wartości widoczne od razu to ostatnio znany fallback (progresywne
ulepszenie); pakiet testów jest liczbą statyczną (SSOT nie liczy testów). Kliknij, żeby zweryfikować.
routes/ip3-*.js — parsery, transport, tenancy, MCP, legal, PDFtests/ (liczba statyczna, spoza SSOT)ip3_list_incidents, ip3_stats i in.liczby odświeżane z /api/ip3/ssot — wartości powyżej to fallback (ostatnio znany stan); trwa wczytywanie live…
źródło: /api/ip3/ssot · macierz techniczna z pełnym dowodem (kod+test per moduł): /przeglad-produktu.
Zgodnie z doktryną claim ≤ proof nie mówimy „gotowe do banku", dopóki nie mamy na to dowodu. Poniżej stan czterech kluczowych warstw fundamentowych (szczegóły i pełny status: znane ograniczenia i status matrix).
| Warstwa | Co robi | Status dziś |
|---|---|---|
| F1 — OIDC/JWKS | Federacja tożsamości, walidacja podpisu tokenu z zewnętrznego IdP. | E2E na staging — zweryfikowane testami end-to-end, jeszcze nie potwierdzone na produkcji banku. |
| F2 — hash-chain audytu + podpis HMAC | Łańcuch integralności zdarzeń audytowych z podpisem HMAC. | shadow LIVE (prod) — działa równolegle na produkcji w trybie obserwacyjnym, przed pełnym cutover. |
| F3 — izolacja multi-tenant | Rozdzielenie danych między organizacjami; testy IDOR/BOLA. | E2E na staging — próby przekroczenia granicy tenantu kończą się 404 w testach; brak jeszcze pełnego wdrożenia produkcyjnego wielu klientów. |
| F4 — realny transport (GitHub/Jira/webhook) | Dwukierunkowa integracja z systemami ticketingowymi klienta. | E2E na staging — połączenie z realnymi API działa w testach; produkcyjne wdrożenie u klienta wymaga jego konfiguracji. |
Regulatory packs (DORA / NIS2 / RODO / AI Act) mają dziś status MVP: mapowanie obowiązek→dowód działa, ale to wsparcie decyzji, nie automatyczna certyfikacja zgodności — każdy pakiet wymaga przeglądu prawnika lub compliance przed użyciem w kontakcie z regulatorem.
Nie. To komplementarna warstwa, która przyjmuje wyniki tych narzędzi jako import (Burp, Nessus, SARIF, SBOM i inne) i przekłada je na dowód powiązany z obowiązkiem regulacyjnym oraz gotowy pakiet dla zarządu. Skanery, pentest i SIEM pozostają potrzebne — ipIII działa na ich wyjściu.
Nie. ipIII wspiera workflow dowodowy i decision-support dla zgodności — pomaga zebrać, powiązać i pokazać dowód. Ostateczną ocenę i kwalifikację prawną zawsze wykonuje prawnik, DPO lub compliance klienta.
Liczby modułu (strony, endpointy, parsery, moduły, MCP tools) wczytywane są runtime z
/api/ip3/ssot, tego samego endpointu co na /przeglad-produktu —
nie są przepisane ręcznie do treści strony. Pełna lista stron: /pages.json,
pełna lista endpointów: /dev-api-reference. Liczba pakietów testów
(81) jest podana statycznie z tests/ repo. Nie są to liczby z prezentacji sprzedażowej.
Tak — najniższy próg wejścia to PoC na danych syntetycznych opisany na /pricing, zgłoszenie przez /pilot-intake, pełny zakres zaufania i bezpieczeństwa dostawcy na /trust-center.
Powiązane: techniczna macierz modułów z dowodem → /przeglad-produktu · pełny rejestr stron → /pages.json · kontrakt API → /dev-api-reference · przykład dowodu z pentestu → /pentest-report-board-pack · zaufanie i bezpieczeństwo dostawcy → /trust-center · zgłoszenie pilota → /pilot-intake · modele współpracy → /pricing.