Serce Evidence & Resilience Orchestrator: sprowadza heterogeniczny sygnał z dziesiątek konektorów do jednego, kanonicznego modelu obiektu. Bez wspólnego kształtu nie ma korelacji, priorytetyzacji ani dowodu. Tu surowy „finding" z dowolnego skanera staje się porównywalnym, oflagowanym prawnie, wycenionym pod ryzyko obiektem K0.
Ścieżka odczytu /api/ip3/* serwuje statyczne obiekty demo w kanonicznym kształcie K0.
Zestaw smoke sprawdza dostępność read-path i zgodność kształtu odpowiedzi ze schematem obiektu K0.
Szkielet autoryzacji (nagłówek operatora / sekret) — ramka, nie pełny RBAC. Bez normalizera write-path.
Mapery per-konektor, deduplikacja, potok priorytetyzacji, zapis znormalizowanych obiektów — projekt, brak kodu produkcyjnego.
GAP §4.2 do implementacji
Konektor tłumaczy narzędzie → surowy rekord. K0-NORMALIZE tłumaczy surowy rekord → kanoniczny obiekt K0. Dopiero znormalizowany obiekt wchodzi do Truth Engine, Evidence Layer i Legal Engine. Nic nienormalizowanego nie liczy się jako dowód.
Warstwa normalizuje każdy przychodzący sygnał do jednego z dwunastu typów obiektu. Każdy niesie public_id, źródło (konektor), znacznik czasu, status dowodowy i odnośniki do obiektów powiązanych.
| Obiekt | Rola w modelu | Kluczowe pola (kanoniczne) |
|---|---|---|
| Asset | Zasób podlegający ochronie — host, usługa, aplikacja, model AI, tożsamość, dane. | asset_id, type, criticality, owner, exposure |
| Finding | Pojedyncze ustalenie skanera / analityka. Generyczny nośnik sygnału przed klasyfikacją. | finding_id, source, raw_severity, asset_ref, evidence_ref |
| Vulnerability | Podatność techniczna, zwykle powiązana z CVE i wyceną CVSS/EPSS/KEV. | cve, cvss, epss, kev, exploitability |
| Incident | Zdarzenie bezpieczeństwa (cyber lub AI) skorelowane z findings i evidence. | incident_id, type, level (L1–L4), status, priority |
| Evidence | Dowód: URL, screenshot, hash SHA-256, log, IoC. Chain of custody. | evidence_id, kind, sha256, confidence, custody |
| Control | Zabezpieczenie / kontrola (techniczna lub organizacyjna) mapowana na ramkę. | control_id, framework, state, coverage |
| Test | Wykonany test (skan, pentest w RoE, retest walidacyjny) i jego wynik. | test_id, scope, roe_ref, result |
| TTP | Technika/taktyka/procedura — mapowanie na ATT&CK (i ATLAS dla AI). | ttp_id, attack_id, tactic, technique |
| LegalFlag | Flaga obowiązku prawnego wyzwolona automatycznie (AI Act, NIS2, KSC, RODO, DORA). | flag_id, regime, article, clock, trigger |
| Action | Krok reakcji z playbooka; wymaga human-in-the-loop dla P0/P1. | action_id, playbook_ref, owner, state |
| Retest | Dowód naprawy — walidacja domknięcia. Bez Retest incydent nie może być zamknięty. | retest_id, action_ref, verdict, evidence_ref |
| Report | Eksport dla organu / audytu: zegar raportowy, załączniki dowodowe, ślad audytowy. | report_id, recipient, deadline, bundle |
Normalizacja severity to funkcja deterministyczna: nie ufa jednej liczbie z jednego narzędzia. Surowa severity to wejście, nie werdykt. Kolejne warstwy podnoszą lub obniżają wynik, aż do priorytetu K0 P0 P1 P2 P3.
POTOK PRIORYTETYZACJI (K0-NORMALIZE §4.2)
============================================================
[tool severity] surowa ocena narzędzia (low/med/high/crit)
│ ── wejście, NIGDY nie werdykt końcowy
▼
[CVSS / EPSS / KEV] wycena podatności:
│ CVSS = dotkliwość teoretyczna
│ EPSS = prawdopodobieństwo exploitacji
│ KEV = czy aktywnie wykorzystywana (CISA)
│ exploitability = dostępność exploita
▼
[asset criticality] krytyczność zasobu (Asset.criticality)
│ krytyczny bankowy core ≫ host testowy
▼
[business impact] wpływ biznesowy / ciągłość działania
│ MTTR, zależności, klienci, rozliczenia
▼
[legal flag] czy wyzwala LegalFlag?
│ AI Act art.73 / NIS2 24h / RODO 33
│ → obowiązek zgłoszenia PODNOSI priorytet
▼
[evidence strength] siła dowodu (Evidence.confidence 0–100)
│ słaby dowód = status GAP, nie eskalacja
▼
========================================================
[ K0 PRIORITY ] ──► P0 P1 P2 P3
========================================================
Zasada §16: priorytet zmienia stan tylko z dowodem.
Ten sam sygnał przed i po przejściu przez K0-NORMALIZE. Wejście jest płaskie i narzędziowe; wyjście jest kanoniczne, oflagowane prawnie, wycenione pod priorytet i spięte dowodem.
{
"source": "scanner-x",
"rule": "TLS-WEAK-CIPHER",
"severity": "high",
"host": "core-payments-03.bank.internal",
"port": 443,
"cve": "CVE-2025-XXXXX",
"observed_at": "2026-07-04T09:12:00Z",
"raw": "Negotiated TLS_RSA_WITH_3DES_EDE_CBC_SHA"
}
{
"finding_id": "K0-FND-2026-07-04-0731",
"public_id": "FND-731",
"object": "Finding",
"source": { "connector": "scanner-x", "rule": "TLS-WEAK-CIPHER" },
"asset_ref": {
"asset_id": "AST-core-payments-03",
"type": "service",
"criticality": "critical", // bankowy core płatności
"exposure": "internal"
},
"vulnerability": {
"cve": "CVE-2025-XXXXX",
"cvss": 7.4,
"epss": 0.61, // 61% — wysokie prawdopod.
"kev": true, // aktywnie wykorzystywana
"exploitability": "public-poc"
},
"raw_severity": "high",
"business_impact": "high", // ciągłość rozliczeń
"legal_flags": [
{ "regime": "DORA", "trigger": "ict-risk", "clock": null },
{ "regime": "NIS2", "article": "23", "clock": "24h", "state": "candidate" }
],
"evidence_ref": {
"evidence_id": "EV-9f2a...",
"kind": "scan-log",
"sha256": "9f2a4c…e17b",
"confidence": 82 // dowód mocny → brak statusu GAP
},
"k0_priority": "P1", // po potoku: podniesione z high
"status": "OPEN",
"ttp": [{ "attack_id": "T1557", "tactic": "credential-access" }],
"normalized_at": "2026-07-04T09:12:03Z",
"normalizer": "K0-NORMALIZE",
"spec_status": "ROADMAP" // §16: kształt referencyjny
}
Surowe rekordy per-konektor (§4.1). Dowolny schemat narzędzia, byle z minimalnym zestawem: źródło, znacznik czasu, odnośnik zasobu.
Mapowanie pól → typ obiektu, deduplikacja, wzbogacenie (CVSS/EPSS/KEV), potok priorytetyzacji, przypięcie evidence i legal flags.
Kanoniczny obiekt K0 z public_id, priorytetem P0–P3, statusem dowodowym i grafem powiązań. Gotowy do korelacji i eksportu.