15 realnych zarzutów, jakie usłyszy każdy, kto próbuje sprzedać lub wdrożyć wczesne narzędzie bezpieczeństwa. Zasada tej strony jest prosta: tam, gdzie zarzut jest trafny — przyznajemy to wprost. Strona, która odpiera każdy zarzut, jest niewiarygodna — audytor i doświadczony nabywca wyczuwają to natychmiast. Doktryna claim ≤ proof obowiązuje też tutaj: żadna odpowiedź poniżej nie twierdzi więcej, niż pokazuje dowód.
Ta strona nie jest materiałem sprzedażowym w klasycznym sensie. Jest testem uczciwości: jeśli zarzut ma pokrycie w faktach (brak klientów, brak certyfikatów, bus factor, moduły wyłączone flagą), mówimy to tu, a nie dopiero po podpisaniu umowy. Format każdej odpowiedzi: dowód → odpowiedź → następny krok.
Dowód: import findingów z DefectDojo do ipIII to kod + test + endpoint (routes/ip3-defectdojo.js,
tests/ip3-defectdojo.unit.js, POST /imports/defectdojo) — patrz
porównanie ipIII vs DefectDojo.
Odpowiedź: Częściowo trafne — integracja z DefectDojo rzeczywiście istnieje i jest jedną z dróg wejścia danych. Nietrafne jest jednak słowo „tylko nakładka": DefectDojo nie generuje natywnie evidence-package z chain-of-custody, nie ma silnika mapowania regulacyjnego ani Board Pack. To osobna warstwa nad danymi z DefectDojo, nie kosmetyczny interfejs na tych samych danych.
Następny krok: pokazać na danych demo pełen łańcuch finding → evidence-package → board pack, żeby różnica była widoczna na artefakcie, nie tylko deklarowana.
Rozróżnienie, które decyduje o odpowiedzi: przedmiotem transakcji jest ipIII jako aktywo, a nie spółka K0NSULT. To dwie różne rzeczy i mylenie ich byłoby wprowadzaniem w błąd — w którąkolwiek stronę.
Trafne co do produktu: ipIII nie ma dziś ani jednego płacącego użytkownika. Zero wdrożeń komercyjnych, zero przychodu przypisanego do tego produktu. Żadna strona portalu nie twierdzi inaczej.
Nietrafne co do spółki: K0NSULT Sp. z o.o. realizuje odpłatne zlecenia — obsługę informatyczną i prawno-regulacyjną dla podmiotów jednej branży (kilka podmiotów, obsługa ciągła) oraz usługi audytowo-przeglądowe. Nazwy klientów i warunki handlowe nie są publikowane — udostępniane w procesie due diligence, po NDA.
Co z tego wynika dla nabywcy: istnieje zespół z historią odpłatnej realizacji, ale ipIII nie ma jeszcze zweryfikowanego rynku. Ryzyko produktowe zostaje. Nie należy przenosić wiarygodności spółki na produkt.
Następny krok: pilot ipIII z jasno określonym kryterium sukcesu i terminem oceny — patrz sekcja pilotażu w przeglądzie produktu.
Dowód: obowiązki dot. zakazanych praktyk i GPAI weszły w życie 2.02.2025 i 2.08.2025; termin dla systemów wysokiego ryzyka (Aneks III) został przesunięty przez Digital Omnibus na 2.12.2027 — ale sama ustawa nie została uchylona ani wycofana.
Odpowiedź: Nietrafne. To obowiązująca ustawa UE z wiążącymi terminami, nie nieformalny trend. Terminy bywają przesuwane (jak w przypadku Digital Omnibus), ale przesunięcie terminu to nie zniknięcie obowiązku.
Następny krok: pokazać aktualny harmonogram — które terminy już minęły, które są przesunięte — bez zaokrągleń w żadną stronę.
Dowód: pojedyncze elementy (parser CSV, prosty hash pliku) są rzeczywiście proste do odtworzenia. Trudniejsze okazały się detale: determinizm hasha, transakcyjny import, cap wejścia parserów (413, fail-closed), izolacja dedupu per organizacja, niezmienność dziennika audytu — to realne poprawki wykonane już po tym, jak pierwsza wersja miała w nich luki.
Odpowiedź: Częściowo trafne — pojedyncze komponenty owszem, da się odtworzyć szybko. Całość (evidence + legal triggers + audit log + board pack jako spójny, zdeterminowany łańcuch) zwykle zajmuje więcej czasu, niż się wydaje na starcie, bo błędy ujawniają się dopiero przy integracji, nie przy pojedynczym module.
Następny krok: udostępnić listę napraw wykonanych po pierwszej iteracji jako materiał do własnej wyceny kosztu budowy równoważnika.
Dowód: brak certyfikatu (np. ISO 27001, SOC2) w repo lub dokumentacji projektu.
Odpowiedź: Trafne wprost. Zero certyfikatów. Nie oznaczamy niczego jako potwierdzone certyfikatem, bo nie ma do tego podstawy.
Następny krok: jeśli certyfikat jest twardym wymogiem zakupowym, dziś ipIII tego wymogu nie spełnia — to trzeba rozstrzygnąć przed dalszą rozmową, nie po niej.
Dowód: historia commitów rdzenia kodu wskazuje jednoosobowy zespół wykonawczy.
Odpowiedź: Trafne. Bus factor jest realny i to jedno z poważniejszych ryzyk operacyjnych tego aktywa, nie kosmetyczne zastrzeżenie na końcu listy.
Następny krok: dokumentacja repo, testy jednostkowe i runbook zmniejszają — nie eliminują — ryzyko wiedzy nieprzekazanej; do zweryfikowania osobno przy przekazaniu aktywa.
Dowód: 14 modułów enterprise (access-model, rls-enforce, tsa, canonical, cve-enrich, siem-guard,
ticket-sync, stix, scm-ingest, board-report, approval, redteam, observability, ci-gate) jest załadowanych w
kodzie, ale domyślnie enabled=0 (fail-safe) — widoczne na /api/ip3/v1/waves/status.
Odpowiedź: Częściowo trafne — dokładny ułamek „połowa" nie jest zweryfikowany liczbą wszystkich modułów, ale kierunek jest prawdziwy: znacząca część funkcji istnieje jako kod załadowany-lecz-wyłączony, nie jako aktywna ścieżka danych. To świadomy fail-safe (żeby włączenie nie było przypadkowe), nie ukryta usterka — ale to nie zmienia faktu, że nie są dziś LIVE.
Następny krok: pełna macierz statusów, moduł po module, na status-matrix.
Dowód: brak izolacji RLS wielotenantowej w kodzie; jawnie oznaczone jako ROADMAP w known-limitations.
Odpowiedź: Trafne wprost. Dziś jedna organizacja na instancję. Jeśli potrzeba wielu klientów w jednej instalacji z izolacją danych na poziomie bazy — to dziś nie istnieje.
Następny krok: do czasu wdrożenia multi-tenant, model operacyjny to jeden pilot/partner na instancję.
Dowód: sha256 w evidence-package potwierdza integralność (czy plik nie został zmieniony
po wygenerowaniu) i moment powstania w łańcuchu, nie prawdziwość faktów opisanych w środku pliku.
Odpowiedź: Trafne wprost, i to ważne rozróżnienie epistemiczne. Hash mówi „ten plik jest dokładnie taki, jaki był w chwili X" — nie „to, co w nim napisano, jest prawdą". Jeśli źródłowy finding był błędny, hash to zakonserwuje, nie naprawi.
Następny krok: prawdziwość treści zależy od jakości źródła (skaner, pentester) i procesu weryfikacji przed zamknięciem findingu — nie od samego mechanizmu hashowania.
Dowód: Legal Trigger Engine jest jawnie oznaczony jako decision-support, nie porada prawna — wymaga weryfikacji prawnika przed jakąkolwiek decyzją operacyjną.
Odpowiedź: Pierwsza część zarzutu jest trafna: to rzeczywiście nie jest porada prawna. Wniosek „po co mi to" jest nietrafny — wstępne, szybkie oznaczenie potencjalnego obowiązku (do potwierdzenia przez prawnika) skraca czas reakcji zespołu bezpieczeństwa, nawet jeśli ostateczna ocena prawna pozostaje po stronie prawnika.
Następny krok: pokazać przykład mapowania finding → potencjalny obowiązek na danych demo, z jasnym zaznaczeniem „do weryfikacji prawnika" przy każdym wyniku.
Dowód: zero opublikowanych referencji dotyczących ipIII — bezpośrednia konsekwencja braku płacących użytkowników tego produktu (zarzut 2).
Odpowiedź: Trafne. Nie publikujemy fikcyjnych case studies ani cytatów „od klienta”, którego dla ipIII nie ma. Realizacje spółki dla innych klientów istnieją, ale nie dotyczą tego produktu i objęte są poufnością — powoływanie się na nie jako na referencje ipIII byłoby nadużyciem.
Następny krok: pierwsza referencja ipIII pojawi się po pierwszym pilocie z jasno zdefiniowanym i zweryfikowanym kryterium sukcesu.
Dowód: brak raportu z niezależnego testu bezpieczeństwa lub przeglądu wykonanego przez podmiot trzeci dla samego ipIII (jako produktu, nie jako narzędzia testującego coś innego).
Odpowiedź: Trafne wprost. Wewnętrzne testy jednostkowe i integracyjne istnieją, ale to nie zastępuje niezależnego przeglądu przez zewnętrzny zespół.
Następny krok: niezależny przegląd bezpieczeństwa jest naturalnym krokiem przed jakimkolwiek wdrożeniem z rzeczywistymi danymi produkcyjnymi klienta.
Dowód: brak integracji z zewnętrznym kwalifikowanym dostawcą usług zaufania (QTSP); PAdES oznaczone jako ROADMAP/GAP w macierzy zasobów.
Odpowiedź: Trafne wprost. Board Pack ma sha256 i manifest wewnętrzny (dowód integralności
generowanego artefaktu), ale nie ma podpisu kwalifikowanego uznawanego prawnie na poziomie QTSP.
Następny krok: jeśli podpis kwalifikowany jest formalnym wymogiem odbiorcy (np. dla celów dowodowych przed sądem lub organem), potrzebny jest zewnętrzny QTSP — dziś tego elementu brak.
Dowód: silnik działa na deterministycznym mapowaniu atrybutów findingu na klauzule regulacyjne, nie na generatywnym modelu językowym podejmującym decyzję.
Odpowiedź: Częściowo trafne — to rzeczywiście nie jest generatywne rozumowanie modelu. To jednak świadomy wybór, nie niedopatrzenie: deterministyczne mapowanie jest audytowalne — można prześledzić, dlaczego dany finding wywołał dany trigger — co przy decyzjach o obowiązkach regulacyjnych jest cechą, nie wadą.
Następny krok: pokazać ślad decyzji (który atrybut findingu wywołał który trigger) jako dowód audytowalności mapowania.
Dowód: DefectDojo jest rzeczywiście open-source i bezpłatny do samodzielnego hostowania — to prawda, nie zaprzeczamy temu.
Odpowiedź: Pierwsza część jest trafna. Wniosek jest częściowo nietrafny, bo DefectDojo i ipIII adresują różne warstwy: DefectDojo zarządza cyklem życia podatności, ipIII dokłada dowód (evidence-package) i wstępne mapowanie regulacyjne, których DefectDojo nie robi — patrz porównanie ipIII vs DefectDojo. Czy ta dodatkowa warstwa jest warta ceny — to decyzja nabywcy, zależna od tego, czy potrzebuje evidence-package i legal triggers.
Następny krok: policzyć koszt braku tej warstwy dziś (czas ręcznego przygotowania pakietu dowodowego dla zarządu/regulatora) jako punkt odniesienia do porównania ceny.
Każdy nowy zarzut, który nie jest jeszcze na tej liście, odpowiadamy tym samym formatem — nie improwizacją:
Dowod: [artefakt / metryka / test / log / brak dowodu — wprost] Zakres twierdzenia: [co dokladnie potwierdza dowod] Ograniczenie: [czego dowod NIE potwierdza] Nastepny krok: [test / poprawka / decyzja / rozmowa]
Powiązane: przegląd produktu (co jest LIVE/MVP/ROADMAP) → /przeglad-produktu · porównanie ipIII vs DefectDojo → /porownanie-vs-defectdojo · pełna macierz statusów modułów → /status-matrix · znane ograniczenia (auth, transport, tenancy, PDF signing) → /known-limitations.