k0nsult.cloud / ai-truth / ipIII / connectors / marketplace

Connector Marketplace / Registry SPEC / ROADMAP

Ta strona to szkielet specyfikacji (SPEC), nie działający marketplace. Dziś ipIII ma LIVE parsery importu plikowego (Burp/ZAP/Nessus/Qualys/generic CSV/JSON) wbudowane w rdzeń. To, czego tu nie ma jeszcze naprawdę, to rejestr publiczny konektorów społecznościowych — model publikacji, przegląd, weryfikacja i dystrybucja paczek. Poniżej dokładnie co jest LIVE, a co dopiero projektem.

Orchestrator Connectors Connector SDK Marketplace Normalize Status matrix Znane ograniczenia ← ipIII hub

Uczciwie na wstępie. „Marketplace" to dziś nazwa specyfikacji, nie uruchomiona usługa. Nie ma publicznego formularza publikacji konektorów, nie ma procesu code-review społeczności, nie ma podpisanych paczek do pobrania. To, co realnie działa i ma kod+test+endpoint, to import parserów opisany na /connectors — oznaczony tam LIVE v1. Cała treść poniżej dotycząca rejestru/publikacji/weryfikacji jest ROADMAP, o ile nie zaznaczono inaczej.

Dziś: 5 konektorów LIVE w rdzeniu. SPEC: rejestr otwarty na community.

Obecny model importu jest scentralizowany — parsery żyją w kodzie orkiestratora i są dodawane przez zespół K0NSULT (patrz Connector SDK dla formatu paczki). Marketplace ma docelowo umożliwić stronie trzeciej (partner, integrator, klient) publikację własnego konektora do rejestru, z procesem weryfikacji przed udostępnieniem innym. Dziś ten proces nie istnieje — jest to świadomie nazwana luka (gap), nie ukryta funkcja.

OŚ DOJRZAŁOŚCI: parsery wbudowane (dziś, LIVE)→SDK + format paczki (spec)→rejestr + metadane→proces weryfikacji→community marketplace

Co jest LIVE dzisiaj (dowód)

To nie jest część marketplace — to istniejący import plikowy, na którym marketplace miałby bazować. Dowód: kod + endpoint + test integracyjny.

Konektor	Typ	Format	Endpoint	Status
Burp Suite	DAST	XML	`/imports/burp`	LIVE v1
OWASP ZAP	DAST	JSON / XML	`/imports/zap`	LIVE v1
Nessus / Tenable	Vuln scan	CSV	`/imports/nessus`	LIVE v1
Qualys VMDR	Vuln scan	CSV / XML	`/imports/qualys`	LIVE v1 (pull API = ROADMAP)
Generic CSV / JSON	uniwersalny	CSV, JSON	`/imports/csv`, `/imports/generic`	LIVE v1

Pełny opis i historia weryfikacji: /connectors · format paczki konektora (SDK): /connector-sdk.

SPEC: model rejestru (ROADMAP)

Poniższe pola i procesy nie są wdrożone. To projekt struktury danych rejestru — punkt wyjścia do dyskusji, nie obietnica terminu.

Metadane konektora ROADMAP

Nazwa, wersja, autor/organizacja, licencja, typ źródła (DAST/SAST/SIEM/CTI/ticketing), format wejścia, checksum paczki.

Manifest zgodności ROADMAP

Deklaracja pól mapowanych na schemat normalizacji ipIII (Truth Engine), wersja schematu, zakres danych osobowych przetwarzanych przez parser.

Historia weryfikacji ROADMAP

Kto i kiedy przeglądał kod parsera, wynik testu na próbce syntetycznej, ewentualne zastrzeżenia bezpieczeństwa.

Kanał dystrybucji ROADMAP

Pobranie paczki z podpisanym checksumem; instalacja lokalna w instancji klienta — bez automatycznego wykonania kodu bez przeglądu.

SPEC: proces publikacji (ROADMAP, projekt)

Szkic kroków, jakie miałby przejść konektor od zgłoszenia do wpisu w rejestrze. Żaden z kroków nie jest dziś zautomatyzowany — dziś jedyną drogą dodania konektora jest kontakt z zespołem K0NSULT i wdrożenie w rdzeniu (patrz Connector SDK).

1. Zgłoszenie. Autor przesyła paczkę + manifest zgodności + próbkę danych syntetycznych do testu. ROADMAP

2. Przegląd statyczny. Skan kodu parsera pod kątem oczywistych ryzyk (brak wykonania kodu dostawcy, tylko deklaratywny mapping pól). ROADMAP

3. Test na próbce syntetycznej. Weryfikacja, że parser poprawnie mapuje pola na schemat normalizacji, bez uruchamiania w środowisku klienta. ROADMAP

4. Wpis do rejestru + znacznik wersji. Publikacja metadanych, checksum paczki, adnotacja "community" vs "K0NSULT core". ROADMAP

5. Instalacja opt-in. Klient sam decyduje o instalacji konektora z rejestru — brak automatycznego wgrywania bez zgody operatora instancji. ROADMAP

Czego marketplace NIE robi (granice z założenia)

Nie ma automatycznego wykonania kodu strony trzeciej. Nawet w docelowym modelu, paczka konektora ma być deklaratywnym mapowaniem pól, przeglądanym przed publikacją — nie dowolnym skryptem wykonywanym bez kontroli. To wymóg bezpieczeństwa, nie funkcja do dodania później.

Rejestr publiczny ≠ ocena jakości. Wpis w rejestrze (gdy powstanie) będzie oznaczał, że paczka przeszła przegląd zgodny z ówczesnym procesem — nie jest to certyfikat bezpieczeństwa ani rekomendacja dla każdego środowiska. Decyzję o instalacji podejmuje operator instancji klienta.

„100%" u nas znaczy pokrycie dowodowe, nie kompletność marketplace. Skoro nie mamy dziś kodu, endpointu i testu dla rejestru publikacji — cała ta strona jest oznaczona ROADMAP, zgodnie z doktryną claim ≤ proof. Jedyne LIVE elementy to istniejące parsery importu, wymienione wyżej.

Granica etyczna i prawna. ipIII jest narzędziem obrony i zgodności (GRC/blue). Ewentualne konektory społecznościowe, gdy powstaną, będą podlegać tym samym zasadom: brak nieautoryzowanych skanów, brak exploitacji, dane wejściowe wyłącznie w granicach zgody operatora danych. To wsparcie decyzji (decision-support), nie porada prawna dotycząca zgodności paczek stron trzecich.

Powiązane: format i wymagania paczki konektora → /connector-sdk · pełna lista konektorów LIVE i ROADMAP → /connectors · macierz statusów wszystkich elementów → /status-matrix.