Ta strona zwiększa zaufanie — nie udajemy systemu klasy bankowej. Jeden rejestr zamiast rozproszonych statusów ROADMAP: dla każdego ograniczenia podajemy jawnie ryzyko, mitigację i priorytet. Jeśli czegoś tu nie ma, a nie jest oznaczone jako LIVE gdzie indziej — traktuj jako niepotwierdzone.
ipIII jest dziś dowodliwym MVP warstwy evidence (import → incydent → evidence-package → retest → close, z JWT/RBAC/audit na żywej PostgreSQL). To NIE jest jeszcze system klasy bankowej pod względem tożsamości federacyjnej, transportu wzajemnie uwierzytelnianego, formalnych podpisów dowodów i wielodostępności. Poniżej dokładnie które elementy i dlaczego.
Kolumna Status = priorytet domknięcia: P0 blokuje wdrożenie enterprise · P1 wymagane dla banku/partnera, nie blokuje pilota. Data weryfikacji: 2026-07-05.
| Kategoria | Ograniczenie | Ryzyko | Mitigacja | Status |
|---|---|---|---|---|
| Auth | JWT wystawiany lokalnie; brak OIDC / federacji tożsamości. Konta seedowane, nie z IdP. | enterprise gap — brak SSO, brak centralnego provisioningu/deprovisioningu, tożsamość nie jest weryfikowana przez zewnętrzny IdP. | Swap na Keycloak / JWKS (walidacja podpisu z zewnętrznego IdP), OIDC authorization-code flow. Funkcja JWT+RBAC już działa (LIVE) — to hardening, nie budowa od zera. | P0 |
| Transport | Brak mTLS (wzajemnego uwierzytelniania TLS) między klientem a API i między usługami. | bank gap — bank SIFI wymaga wzajemnego TLS na styku integracji; dziś tylko TLS jednostronny na warstwie hostingu. | mTLS na bramie API + certyfikaty klienckie dla konektorów; opcjonalnie spięcie z PKI instytucji. Status: ROADMAP. | P0 |
Evidence-package/board-pack ma sha256 integralności, ale nie ma podpisu PAdES ani znacznika czasu TSA. |
formal evidence gap — hash dowodzi niezmienności treści, ale nie jest kwalifikowanym podpisem elektronicznym; słabsza wartość formalno-prawna przed organem/sądem. | PAdES (podpis PDF) + znacznik czasu TSA (RFC 3161), docelowo podpis PQC. Dziś: package_sha256 + chain-of-custody w DB. |
P1 | |
| Tenancy | Jedna organizacja. Brak izolacji wielodostępnej (multi-tenant) — dane nie są rozdzielone per bank/partner/urząd. | bank/partner gap — niemożliwe bezpieczne współdzielenie instancji przez wielu klientów; ryzyko wycieku między kontekstami przy skalowaniu. | Tenant scoping w każdym zapytaniu + Row-Level Security (RLS) w PostgreSQL; separacja audit-logów per tenant. | P1 |
| CVE | Wzbogacanie CVE → CVSS/EPSS/KEV działa offline (hinty z seedu przy imporcie), bez odpytania online w czasie rzeczywistym. | freshness gap — dane o podatnościach mogą być nieaktualne; nowe CVE / zmiany w KEV nie są widoczne do czasu odświeżenia seedu. | Online lookup NVD / CISA KEV / EPSS z cache i rate-limit; harmonogram odświeżeń. Dziś: offline hint (LIVE Fala 1). | P1 |
| SIEM | Brak konektora do SIEM (Splunk / Microsoft Sentinel / QRadar). Import findings dziś z plików skanerów, nie strumieniem z SIEM. | integration gap — brak dwukierunkowej wymiany zdarzeń z centrum detekcji; ingest wymaga eksportu pliku zamiast strumienia. | Webhook ingestion + wymiana STIX/TAXII (MISP/OpenCTI); docelowo konektor Splunk/Sentinel. Status: ROADMAP (S5). | P1 |
| Legal | Legal Trigger Engine to wsparcie decyzji (decision-support), nie porada prawna. Terminy (DORA/NIS2/RODO/AI Act) są orientacyjne. | compliance risk — automatyczne mapowanie może nie objąć niuansów jurysdykcji/sektora; poleganie bez weryfikacji prawnika jest ryzykiem zgodności. | Przegląd prawny każdego draftu przed wysyłką do organu; kwalifikacja przez radcę/kancelarię. To ograniczenie trwałe z założenia — narzędzie nie zastępuje prawnika. | always |
Powiązane: pełna roadmapa 7 sprintów z dowodami → /roadmap-dev · macierz statusów wszystkich elementów → /status-matrix.