K0NSULT // ai-truth/ipIII
k0nsult.cloud / ai-truth / ipIII / exchange / evidence-exchange

Evidence Exchange — wymiana dowodów między partnerami (F10)

Model wymiany, w którym pentesterzy i partnerzy przekazują findingi jako podpisane, zweryfikowane i zanonimizowane paczki dowodowe z klasyfikacją, gotowe do importu po stronie klienta. Ta strona opisuje docelowy model — element jest w fazie projektowej. Zgodnie z doktryną claim ≤ proof: dopóki nie ma kodu, testu i endpointu, oznaczamy go ROADMAP, a nie jako funkcję działającą.

Status tej strony. Evidence Exchange (F10) jest opisem modelu docelowego, nie działającej usługi. Poniższe przepływy, formaty i klasyfikacje to specyfikacja projektowa. Elementy warstwy dowodowej, na których Exchange ma się oprzeć (evidence-package z sha256, chain-of-custody, import parserów), są opisane na stronie orchestratora — Exchange jest ich rozszerzeniem o wymianę międzyorganizacyjną. Cała treść używa danych syntetycznych.
Finding u partnera → paczka dowodowa → import u klienta.

Zamiast przesyłać surowe raporty mailem, partner (pentester, zespół red/blue, dostawca skanów) pakuje findingi w ustandaryzowaną paczkę dowodową: podpisaną kryptograficznie, zweryfikowaną pod kątem integralności i zanonimizowaną wg polityki. Klient importuje ją jednym krokiem do swojego orchestratora, gdzie staje się incydentem z pełnym rodowodem (chain-of-custody). Wymiana jest decision-support — wspiera decyzję o remediacji, nie zastępuje oceny zespołu bezpieczeństwa klienta.

PRZEPŁYW: partner: findingklasyfikacja + anonimizacjapodpis + hashweryfikacjaimport u klienta

Model wymiany — trzy strony

Partner / pentester producent

Tworzy finding w toku uzgodnionego zaangażowania. Wybiera zakres danych do udostępnienia, uruchamia anonimizację i podpisuje paczkę kluczem organizacji. Zachowuje kontrolę nad tym, co opuszcza jego środowisko.

→ Partner Program

Warstwa wymiany pośrednik

Weryfikuje podpis i hash, sprawdza kompletność metadanych i klasyfikacji, rejestruje zdarzenie w rodowodzie. Nie przechowuje treści dłużej niż potrzebne do przekazania; pełni rolę kontroli integralności, nie repozytorium dowodów.

→ Verify

Klient konsument

Importuje zweryfikowaną paczkę do swojego orchestratora. Finding staje się incydentem z rodowodem, klasyfikacją i statusem remediacji. Klient decyduje, czy i jak działać — narzędzie wspiera decyzję.

→ Orchestrator

Cztery filary paczki dowodowej

FilarCo obejmujePo coStatus
Podpisana Paczka podpisana kluczem organizacji-producenta; docelowo podpis wg schematu odpornego post-kwantowo. Metadane zawierają tożsamość podpisującego i czas. Odbiorca może stwierdzić, kto wytworzył paczkę i że nie została podmieniona po podpisie. ROADMAP
Zweryfikowana Kontrola integralności (sha256 treści), spójności metadanych, obecności wymaganych pól klasyfikacji i rodowodu przed dopuszczeniem do importu. Klient nie importuje niekompletnych ani naruszonych paczek; weryfikacja jest bramką, nie formalnością. ROADMAP
Zanonimizowana Usunięcie / maskowanie danych wrażliwych producenta i osób trzecich wg polityki: adresy hostów, dane logowania, PII, wewnętrzne nazwy. Zachowanie technicznej istoty findingu. Wymiana bez ujawniania danych, które nie są potrzebne odbiorcy do oceny i remediacji. ROADMAP
Sklasyfikowana Etykiety: dotkliwość (CVSS/EPSS jako hint), typ (kategoria podatności), wrażliwość udostępnienia (poziom poufności), mapowanie do obowiązków jako wsparcie decyzji. Odbiorca od razu wie, jak pilna jest paczka i jak wolno ją dalej przetwarzać. ROADMAP

Ścieżka importu u klienta

1. Odbiór. Klient otrzymuje paczkę (kanał uzgodniony w programie partnerskim). Warstwa wymiany potwierdza podpis i hash przed pokazaniem treści.
2. Weryfikacja. Sprawdzenie kompletności klasyfikacji i rodowodu. Paczka niekompletna lub o naruszonej integralności jest odrzucana z jawnym powodem.
3. Podgląd. Klient widzi zanonimizowaną treść findingu, klasyfikację i sugerowane obowiązki (decision-support) przed decyzją o imporcie.
4. Import. Po akceptacji finding staje się incydentem w orchestratorze klienta, z zachowanym rodowodem i etykietami. Źródłowa tożsamość producenta pozostaje w metadanych.
5. Remediacja i retest. Dalej działa standardowy przepływ orchestratora (incydent → remediacja → retest → close), już po stronie klienta.

Przykład (dane syntetyczne)

{
  "package_id": "EXC-SYNTH-0007",
  "producer": { "org": "partner-alpha (synthetic)", "signed": true },
  "finding": {
    "title": "Reflected input handling — moduł demonstracyjny",
    "class": { "severity": "medium", "type": "input-validation" },
    "cvss_hint": 6.1,
    "epss_hint": 0.07
  },
  "anonymization": { "policy": "strip-hosts+pii", "applied": true },
  "integrity": { "package_sha256": "<syntetyczny-hash>", "chain_of_custody": true },
  "share_sensitivity": "restricted",
  "status": "ROADMAP — model docelowy, nie usługa działająca"
}

Wartości powyżej są syntetyczne i służą wyłącznie ilustracji formatu. Nie odnoszą się do żadnej rzeczywistej podatności ani klienta.

Powiązane funkcje

F10
Evidence Exchange
wymiana paczek — ta strona
Partner Program
/partner-program — zasady dołączenia
Verify
/verify — kontrola podpisu i hashu
Anonymizer
/anonymizer — polityka maskowania

Czego ta strona NIE deklaruje

To nie jest działająca usługa wymiany. Model, formaty i przepływy są specyfikacją projektową (ROADMAP). Elementy warstwy dowodowej, na których Exchange ma się oprzeć, opisano na stronie orchestratora — tam też są oznaczenia LIVE vs ROADMAP.
Wymiana wspiera decyzję, nie zastępuje oceny. Import paczki nie jest poleceniem działania. Klasyfikacja, mapowanie obowiązków i sugestie remediacji to wsparcie decyzji — zespół bezpieczeństwa klienta zachowuje pełną odpowiedzialność za ocenę i reakcję.
Granica etyczna i prawna. Evidence Exchange dotyczy wyłącznie wymiany dowodów w granicach pisemnych uzgodnień między partnerami a klientem. Nie obejmuje nieautoryzowanego pozyskiwania danych ani przekazywania findingów bez zgody producenta. Mapowania obowiązków to wsparcie decyzji, nie porada prawna — każdy draft do organu wymaga przeglądu prawnego. Zakres udostępnienia i anonimizacja podlegają uzgodnieniu w programie partnerskim.

Powiązane: zasady dołączenia partnera → /partner-program · kontrola podpisu i integralności → /verify · polityka anonimizacji → /anonymizer · znane ograniczenia warstwy → /known-limitations.