k0nsult.cloud / Common-Source-of-Truth / report

Zgłoszenia

Jeden punkt wejścia dla 7 typów zgłoszeń: incydenty, podatności, naruszenia AI, Big Tech dependency. Każde zgłoszenie otrzymuje unikalny ID, status, ownera i pełny ślad dowodowy.

WAŻNE. REAL i SIMULATION nie mieszają się w jednej kolejce — każde zgłoszenie oznacz wyraźnie jako REAL lub SIMULATION. Sekwencja triage i retencja danych zależą od tej klasyfikacji.

1. Typy zgłoszeń

Siedem kategorii — każda z priorytetem triage (P0–P2) i wymaganiami dowodowymi:

Incydent cyber P0–P1

Atak, włamanie, DoS, wyciek danych, sabotaż infrastruktury. Wymaga opisu zagrożenia, wpływu i wektora ataku.

Podatność P0–P2

Vulnerability. Błąd w kodzie, konfiguracji lub protokole. Wymaga dowodu (CVE, PoC, log).

System AI P0–P1

Hallucynacja, bias, model drift, fail-safe failure. Wymaga scenariusza test i wyjścia z logów.

Naruszenie AI P0–P2

Nieprzestrzeganie AI Act, MiCA lub wewnętrznych polityk bezpieczeństwa. Wymaga cytatu prawa i dowodu naruszenia.

Big Tech dependency P1–P2

Zależność od jednego dostawcy, lock-in, brak fallback. Wymaga mapy zależności i analizy suwerenności.

PPP / współpraca P2

Publiczno-prywatne partnerstwo, konflikt interesów, przejrzystość. Wymaga umowy lub komunikatu prasowego.

Sandbox / test SIMULATION

Zgłoszenie testowe w środowisku izolowanym. Nie trafia na prod; służy walidacji procedury i formuszy.

2. Model danych: Incident

Każde zgłoszenie przechowuje:

Pole	Typ	Opis
incident_id	string (PK)	Unikalny identyfikator: CST-2026-001 lub CSTSIM-2026-001 (REAL vs SIMULATION)
type	enum	cyber \| ai \| data \| bigtech \| vulnerability \| supply-chain \| other
severity	enum	P0 (krytyczne) \| P1 (wysokie) \| P2 (umiarkowane) \| P3 (niskie)
environment	enum	REAL \| SIMULATION
summary	text	Jednoliniowy opis zgłoszenia
source	string	Kto zgłosił: autor, mail, afiliacja
evidence_ids[]	array	Lista odniesień do indeksu dowodów: EV-2026-001, log file, URL
legal_triggers[]	array	Artykuły AI Act, MiCA lub otras regulacji: "AI Act Art. 50"
owner	string	Zespół właściciela: K0NSULT-Triage, K0NSULT-Legal, GRL
status	enum	new \| triage \| investigation \| contained \| reported \| closed \| disputed
created_at	timestamp	Data i czas zgłoszenia (UTC)
retention_class	enum	permanent \| 3y \| 1y (zależy od typu i environment)

3. Procedura triage

Wybierz typ

Określ kategorię: cyber, podatność, AI, naruszenie, BigTech, PPP, sandbox.

Podaj minimum danych + REAL/SIMULATION

Summary, source, environment (REAL lub SIMULATION), przynajmniej jeden evidence_id lub cytat artykułu.

Triage P0–P3

Automatycznie lub ręcznie: P0 = krytyczne (24h response), P1 = 3d, P2 = 1w, P3 = backlog.

Nadanie ID i ownera

System generuje incident_id (CST-2026-NNN lub CSTSIM-2026-NNN). Owner = zespół podle typu i statusu.

Ślad dowodowy

Archiwum: zgłoszenie → status → changes → closure/resolution. Każda zmiana logowana z timestamp i operatorem.

4. Formularze i kontakt

Formularze zgłoszeń są uruchomione:

› Zgłoś incydent — formularz (REAL/SIMULATION, triage)
› Zgłoś podatność — responsible disclosure
Alternatywnie przez e-mail: report@k0nsult.cloud
W tytule podaj typ: [CYBER], [AI VIOLATION], [SANDBOX]
Klauzula zgodności i owner wymagane; brak = triage reject
Szczegóły techniczne (evidence_ids, legal_triggers) opcjonalne przy pierwszym kontakcie, ale wymagane do acceptance

Zastrzeżenie prawne. Niniejszy portal nie stanowi certyfikacji, nie jest opinią jednostki notyfikowanej ani wnioskowaniem prawnym (not a certification · not a notified body · not a legal conclusion). Statusy zgłoszeń odzwierciedlają ocenę wewnętrzną K0NSULT i mogą podlegać aktualizacji lub weryfikacji przez właściwe organy. REAL i SIMULATION są całkowicie rozdzielone.