Ukrywanie długu jest gorsze niż jego pokazanie. Nabywca w due diligence i tak go znajdzie — a dług znaleziony samodzielnie wygląda na zatajony, nawet jeśli nikt go celowo nie ukrywał. Ta strona pokazuje ryzyka aktywa ipIII wprost: co jest otwarte, co zostało zamknięte w tej wersji (z dowodem) i co musiałoby być prawdą, żeby transakcja nie miała sensu. Doktryna claim ≤ proof obowiązuje tu tak samo jak na reszcie ipIII.
Poniższy rejestr powstał z przeglądu repozytorium ipIII na dzień weryfikacji (2026-07-09), nie z szablonu ogólnego due diligence. Każde ryzyko ma nazwaną kategorię, ocenę prawdopodobieństwa i skutku, mitygację, właściciela i status w kanonie 7 statusów ipIII — ten sam kanon, którego używa /status-matrix.
Kolumna Status = status mitygacji w kanonie 7 statusów ipIII, nie status samego ryzyka (ryzyko jest otwarte dopóki mitygacja nie jest LIVE_PROD). Data weryfikacji: 2026-07-09.
| Kategoria | Ryzyko | P | Skutek | Mitygacja | Właściciel | Status |
|---|---|---|---|---|---|---|
| techniczne | Brak wielotenantowości z izolacją na poziomie bazy (RLS) — dziś tryb pojedynczej organizacji. | wysokie | Niemożliwe bezpieczne współdzielenie jednej instancji przez wielu klientów; ryzyko wycieku między kontekstami przy skalowaniu do wielu pilotów naraz. | Tenant scoping w każdym zapytaniu + Row-Level Security w PostgreSQL, opisane na known-limitations. | inżynieria / platforma | ROADMAP |
| techniczne | 14 modułów enterprise załadowanych, ale wyłączonych flagą (enabled=0, fail-safe). |
średnie | Brak realnej wartości biznesowej z modułów dopóki nie są włączone; fail-safe oznacza, że dziś nie generują ryzyka bezpieczeństwa, ale też żadnej funkcji. | Włączanie moduł po module, z ACK i testami na środowisku kontrolowanym, po zapewnieniu zasobów prod (IdP/PKI/QTSP). | inżynieria | SCAFFOLD |
| techniczne | Brak trwałego magazynu artefaktów dowodowych (obiektowy storage z retencją). | wysokie | Artefakty (pakiety dowodowe, załączniki) nie mają dziś gwarancji przetrwania restartu/migracji infrastruktury poza samą bazą danych. | Wdrożenie zewnętrznego obiektowego storage (S3-kompatybilny) z polityką retencji i backupem. | inżynieria / infra | GAP |
| techniczne | Brak produkcyjnego dostawcy tożsamości (IdP), mTLS PKI i kwalifikowanego znacznika czasu (QTSP). | wysokie | Blokuje wdrożenie klasy bankowej/enterprise: brak federacji tożsamości, brak wzajemnego uwierzytelniania transportu, brak formalnego znacznika czasu na dowodach. | Integracja Keycloak/OIDC produkcyjnego, mTLS na bramie API, umowa z QTSP — zasoby do zakupu, opisane na known-limitations. | inżynieria / zakupy | ROADMAP |
| techniczne | Limiter żądań trzyma stan w pamięci procesu bez czyszczenia — rośnie wraz z liczbą unikalnych tożsamości/tras. | średnie | Przy długim uptime rosnące zużycie pamięci; dziś mitygowane wyłącznie przez restart procesu, nie przez mechanizm wygasania. | TTL/eviction w liczniku lub przeniesienie stanu do magazynu zewnętrznego z wygasaniem wpisów. | inżynieria | GAP |
| techniczne | Konta bez przypisanej organizacji nie są chronione unikalnym indeksem bazy — baza traktuje brak wartości jako wartość odrębną. | średnie | Świeżo naprawiona izolacja organizacji w deduplikacji (2026-07-09) jawnie NIE obejmuje kont bez organizacji — to zawężenie istniejącego, wcześniej szerszego ograniczenia, nie nowy defekt. | Częściowy unikalny indeks bazy (warunek NOT NULL) + walidacja aplikacyjna wymuszająca organizację przy tworzeniu konta. | inżynieria / baza danych | GAP |
| operacyjne | Ryzyko koncentracji wiedzy (bus factor) — kluczowa wiedza domenowa skoncentrowana u małej liczby osób. | wysokie | Utrata jednej osoby może istotnie spowolnić rozwój lub utrudnić przekazanie aktywa nabywcy. | Dokumentacja architektury i decyzji (ADR), plan handover, rozszerzenie zespołu przy transakcji. | zarząd / operacje | ROADMAP |
| operacyjne | Zależność od zasobów zewnętrznych, których dziś nie ma (produkcyjny IdP, mTLS PKI, QTSP, trwały storage). | wysokie | Uruchomienie warstwy enterprise wymaga zakupu/integracji usług spoza dzisiejszego zakresu — nie jest to praca wyłącznie inżynierska. | Plan zakupowy z budżetem i wyborem dostawców, powiązany z włączaniem modułów enterprise za flagą. | operacje / zakupy | GAP |
| rynkowe | Zero płacących klientów, zero certyfikacji zewnętrznych na dzień weryfikacji. | wysokie | Wpływa na wycenę i profil ryzyka transakcji — aktywo jest dowodliwym MVP/produktem przed pierwszą sprzedażą, nie produktem z historią przychodu. | Piloty/PoC z partnerami jako dowód popytu; ścieżka certyfikacji podejmowana po sygnale rynkowym lub decyzji nabywcy, nie z góry. | sprzedaż / zarząd | ROADMAP |
| prawne | Ryzyko regulacyjne AI Act: art. 50 (transparentność, termin 2.08.2026) i Aneks III high-risk (po odroczeniu Digital Omnibus, termin 2.12.2027). | wysokie | Terminy są pewne (harmonogram ustawowy); niedotrzymanie mapowania obowiązków przed terminem jest ryzykiem zgodności dla użytkowników ipIII i pośrednio dla aktywa. | Legal Trigger Engine jako decision-support + obowiązkowy przegląd prawnika przed każdym terminem; monitoring publikacji Dz.U. UE. | prawnik / compliance | MVP |
Rozróżnienie jest celowe. Kod mitygacji gotowy to nie to samo co ryzyko zamknięte. Ostatni wiersz tabeli opisuje ochronę dziennika audytu przed TRUNCATE: migracja istnieje i ma test, ale nie została uruchomiona na bazie produkcyjnej, więc ryzyko pozostaje otwarte. Oznaczone ROADMAP, nie LIVE_PROD.
Dowód, że ten rejestr żyje, a nie jest jednorazowym dokumentem: poniższe pozycje były otwarte i zostały zamknięte lub zawężone w toku pracy nad ipIII (wpisy z 2026-07-09, pełny opis na /aktualizacje).
| Ryzyko (było) | Co naprawiono | Dowód | Status |
|---|---|---|---|
Niekanoniczny hash pakietu dowodowego — ten sam logicznie pakiet, zbudowany inną ścieżką kodu, dawał inny package_sha256. |
Hash liczony po kanonicznej serializacji; dodano pole hash_alg, żeby audytor wiedział, którym algorytmem przeliczyć weryfikację. Pakiety wydane wcześniej mają hash starą metodą — to jawne, nie ukryte. |
tests/ip3-package-hash.unit.js, endpoint /verify |
LIVE_PROD |
| Hash zależny od czasu pobrania — dwa pobrania tego samego pakietu dawały różny hash, bo samo pobranie dopisywało wpis do dziennika audytu wchodzący w treść hashowaną. | Ślady pobrań wyłączone z treści pakietu (nadal widoczne w bazie i pod /audit); nowe pole hash_scope mówi wprost, które pola obejmuje hash. |
Narzędzie scenariusza na żywej bazie (scripts/ip3-e2e-staging.js): import, powtórzenie wsadu, porównanie hashy. Testy jednostkowe: 78 pakietów tests/ip3-* przechodzi bez błędu (weryfikacja: uruchom każdy plik i zsumuj wyniki N PASS / 0 FAIL). |
LIVE_PROD |
| Import findingów bez transakcji (N+1) — każdy finding kosztował 4–5 osobnych zapytań, błąd w połowie zostawiał połowiczny import. | Import przepisany na jedną transakcję; liczba zapytań nie zależy od liczby findingów. Zmierzone: 20 000 findingów obsłużonych 13 zapytaniami. | Narzędzie scenariusza na żywej bazie środowiska testowego; 78 pakietów testów jednostkowych bez błędów. | LIVE_PROD |
| Brak limitu wielkości importu — parsery przyjmowały dowolnie duży wsad, ryzyko cichego obcięcia danych. | Limit liczby findingów i rozmiaru wejścia z zasadą „odrzuć, nie obcinaj": przekroczenie zwraca 413 z podaniem limitu i wartości zaobserwowanej. Ochrona objęła dziesięć ścieżek importu, w tym /imports/generic. |
routes/ip3-parse-limits.js; 22 asercje PASS w teście tests/ip3-parser-limits.unit.js; ochrona objęła 10 ścieżek importu; parserów w repo: 19 (źródło: /api/ip3/ssot). |
LIVE_PROD |
| Deduplikacja bez izolacji organizacji — finding jednej organizacji dedupował się względem incydentu innej, ujawniając istnienie cudzego incydentu. | Deduplikacja ograniczona do organizacji; przygotowany unikalny indeks bazy dodatkowo blokuje duplikat przy dwóch jednoczesnych importach. Nie obejmuje kont bez organizacji — patrz ryzyko otwarte wyżej. | routes/ip3-dedup.js; scenariusz na żywej bazie przechodzi w całości. |
LIVE_PROD |
Brak ochrony dziennika audytu przed TRUNCATE — mechanizm, który nie uruchamia zwykłych wyzwalaczy wierszowych i mógłby ominąć ochronę przed nadpisaniem/usunięciem. |
Przygotowana migracja bazy blokująca UPDATE, DELETE i osobnym mechanizmem TRUNCATE. Migracja czeka na zastosowanie przez operatora na bazie produkcyjnej — to jest częściowe zamknięcie: kod mitygacji gotowy, wdrożenie nie. |
tests/ip3-audit-immutability.test.js |
ROADMAP |
Poniższe kryteria opisują, co musiałoby być prawdą, żeby transakcja NIE miała sensu — żaden z nich nie jest dziś potwierdzony jako prawdziwy w repozytorium; wymieniamy je, żeby proces due diligence miał jasny cel.
| Kryterium | Uzasadnienie |
|---|---|
| Brak udokumentowanych praw do istotnej części kodu (cesja praw autorskich wykonawców niepełna lub nieudokumentowana). | Nabywca mógłby nie mieć prawa legalnie eksploatować aktywa. |
| Aktywne krytyczne luki bezpieczeństwa bez planu naprawy w rozsądnym horyzoncie. | Ryzyko incydentu bezpieczeństwa bezpośrednio po przejęciu. |
| Brak dostępu do repozytorium i historii commitów dla zespołu weryfikującego nabywcy. | Nie da się niezależnie zweryfikować stanu technicznego aktywa. |
| Nieudokumentowane lub nielegalne przetwarzanie danych osobowych w środowiskach demo/testowych. | Ryzyko sankcji regulacyjnych i nakazów ograniczenia przetwarzania. |
| Element oznaczony jako LIVE_PROD bez odpowiadającego kodu, testu i endpointu (naruszenie doktryny claim ≤ proof gdziekolwiek na ipIII). | Podważa wiarygodność całego rejestru statusów, na którym opiera się ta strona i status-matrix. |
Powiązane: pełny rejestr znanych ograniczeń → /known-limitations · kanoniczna macierz statusów → /status-matrix · przegląd produktu ipIII → /przeglad-produktu · indeks due-diligence dla inwestora → /data-room · dziennik zmian z dowodami → /aktualizacje.