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.
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. |
Każda liczba poniżej jest policzalna w repozytorium i/lub na żywym rejestrze modułu. Kliknij, żeby zweryfikować.
routes/ip3-*.js — parsery, transport, tenancy, MCP, legal, PDFtests/ip3_list_incidents, ip3_stats i in.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.
Są policzalne w kodzie i na żywych rejestrach: /pages.json zwraca pełną listę stron, /dev-api-reference pełną listę endpointów. 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: 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.