K0NSULT // ai-truth/ipIII
k0nsult.cloud / ai-truth / ipIII / orchestrator / remediation

Workflow remediacji — od zgłoszenia do zamknięcia z dowodem

Cykl życia podatności/incydentu w orchestratorze ipIII: open → triaged → assigned → fixing → retest → closed. Zamknięcie (close) jest możliwe wyłącznie z dowodem retestu o statusie CONFIRMED — reguła egzekwowana w bazie danych. Ta strona jest jawnym rejestrem: przypisanie właściciela, zegar SLA i przejścia lifecycle są LIVE MVP; pełny task board, eskalacja i przypomnienia pozostają ROADMAP.

Status jawny. Assign właściciela, zegar SLA i przejścia lifecycle (transition) = LIVE MVP — realne endpointy /incidents/:id/assign i /incidents/:id/transition na warstwie v1 (auth + DB). Reguła close-with-evidence (zamknięcie tylko przy reteście CONFIRMED) jest LIVE i egzekwowana w bazie danych (422 bez dowodu; PATCH-bypass zamknięty — audyt F4). Eksport tasku do Jira/GitHub = LIVE MVP (/incidents/:id/ticket). Pełny task board, eskalacja, automatyczne przypomnienia (reminders), workflow zatwierdzeń = ROADMAP. Terminy SLA poniżej są orientacyjne (domyślne, konfigurowalne per organizacja) — nie stanowią zobowiązania umownego.
Jedna reguła zamknięcia: close ≤ dowód CONFIRMED.

Remediacja nie kończy się deklaracją „naprawione". Kończy się artefaktem: retest o statusie CONFIRMED wpięty w łańcuch dowodowy, po którym package_sha256 evidence-package zmienia wartość. Bez tego dowodu incydent nie przejdzie do closed — baza danych odrzuci przejście (422).

LIFECYCLE: opentriagedassignedfixingretestclosed

Stan realny — co jest LIVE dziś (kanon testów: roadmap-dev → Evidence Matrix · kanon statusu: status-matrix)

6
Stany lifecycle
open→triaged→assigned→fixing→retest→closed
assign
Owner assignment
LIVE MVP · /incidents/:id/assign
422
Close bez CONFIRMED
LIVE · egzekwowane w DB (F4 zamknięty)
ticket
Eksport Jira/GitHub
LIVE MVP · /incidents/:id/ticket

Dowody statusów LIVE = Evidence Matrix (integracja na żywej PostgreSQL: import→pack→retest→engagement). Nie powielamy tu liczników testów — jedno źródło prawdy pozostaje w roadmap-dev. Wszystko poza opisanym LIVE/LIVE MVP = ROADMAP.

1 · Diagram lifecycle (cykl życia)

Każdy incydent przechodzi przez jawnie zdefiniowane stany. Przejścia (transition) są rejestrowane w audit logu (kto/co/kiedy). Przejście do closed jest bramkowane dowodem.

open — incydent utworzony (z importu skanera jako MEDIA_SIGNAL lub zgłoszony ręcznie). Severity znormalizowane P0–P3. Jeszcze bez właściciela. LIVE
triaged — potwierdzenie zasadności, klasyfikacja, ustalenie priorytetu i wstępnego SLA. Odrzucenie fałszywego alarmu kończy się przejściem do stanu odrzuconego (poza ścieżką naprawy). LIVE MVP
assigned — przypisany właściciel (owner) odpowiedzialny za naprawę. Start zegara SLA liczonego od created_at. Endpoint /incidents/:id/assign. LIVE MVP
fixing — prace naprawcze w toku. Właściciel dokumentuje działania; opcjonalny eksport tasku do Jira/GitHub (/incidents/:id/ticket). LIVE MVP
retest — walidacja naprawy. Uruchomienie ponownego testu; wynik musi otrzymać status CONFIRMED (np. przez Response & Retest / panel sędziów). Bez CONFIRMED incydent wraca do fixing. LIVE
closed — zamknięcie tylko z dowodem CONFIRMED. Baza odrzuca przejście bez dowodu (422). Po zamknięciu package_sha256 evidence-package odzwierciedla zmianę stanu. LIVE (close-with-evidence)
PRZEJŚCIA: opentriagedassignedfixingretestclosed retest ✗ → fixing (pętla)

2 · Role — przypisanie właściciela (owner assignment)

Za każdy incydent w stanie assigned i dalej odpowiada dokładnie jeden właściciel. Role są egzekwowane przez RBAC warstwy v1.

RolaZakres odpowiedzialnościStan
Reporter / ImporterTworzy incydent (import skanera = MEDIA_SIGNAL lub zgłoszenie ręczne). Nie zamyka.LIVE v1
TriagerWeryfikuje zasadność, nadaje priorytet i SLA, wykonuje przejście open→triaged.LIVE MVP
Owner (właściciel naprawy)Przypisany przez /incidents/:id/assign. Prowadzi naprawę (fixing), inicjuje retest.LIVE MVP
Retester / VerifierWaliduje naprawę; wynik CONFIRMED (dowód) odblokowuje przejście do closed.LIVE
Approver (zatwierdzający)Formalne zatwierdzenie zamknięcia / akceptacja ryzyka. Workflow wieloetapowego zatwierdzania.ROADMAP

Przypisanie i przejścia zapisują wpis w audit logu (kto/co/kiedy) w PostgreSQL. Separacja obowiązków (reporter ≠ retester ≠ approver) jako twarda reguła = częściowo v1, pełne rozdzielenie ról = ROADMAP.

3 · SLA per severity (orientacyjnie — domyślne, konfigurowalne per org)

Zegar SLA startuje od created_at i jest liczony do wymaganego stanu (naprawa/retest). Poniższe wartości są domyślne i orientacyjne — nie stanowią zobowiązania umownego ani gwarancji.

SeverityPriorytetSLA (orientacyjnie)Znaczenie
P0 KrytycznaNatychmiast24 hAktywne ryzyko lub exploit w KEV; wymaga natychmiastowego właściciela i naprawy.
P1 WysokaPilne72 hPoważna podatność; naprawa w oknie zgodnym z obowiązkami raportowymi (NIS2 24h/72h — patrz Legal Engine).
P2 ŚredniaPlanowe7 dniIstotna, lecz bez natychmiastowego ryzyka; planowa remediacja.
P3 NiskaBacklog30 dniNiski wpływ; naprawa w ramach cyklu utrzymaniowego lub świadoma akceptacja ryzyka.
Zastrzeżenie SLA. Wartości 24h / 72h / 7d / 30d są orientacyjnymi wartościami domyślnymi systemu, a nie zobowiązaniem umownym. Rzeczywiste terminy ustala organizacja (konfiguracja per org) oraz mające zastosowanie obowiązki regulacyjne (DORA, NIS2, RODO — patrz Compliance / Legal Engine). Zegar i naliczanie SLA = LIVE MVP; automatyczna eskalacja po przekroczeniu i przypomnienia = ROADMAP.

4 · Retest → close-with-evidence (LIVE · egzekwowane w DB)

Najtwardsza reguła całego workflow. Incydentu nie da się zamknąć samą deklaracją — potrzebny jest dowód retestu o statusie CONFIRMED.

Krok 1 — retest uruchomiony. Właściciel/retester inicjuje walidację naprawy. Wynik zapisany jako dowód w łańcuchu (chain-of-custody, sha256). LIVE
Krok 2 — status CONFIRMED. Dowód naprawy musi otrzymać status CONFIRMED (weryfikacja, np. przez panel sędziów / Response & Retest). Bez CONFIRMED przejście do closed jest odrzucane. LIVE
Krok 3 — bramka DB. Próba zamknięcia bez dowodu CONFIRMED zwraca HTTP 422. Obejście przez PATCH zostało zamknięte (audyt F4 + testy regresyjne). LIVE
Krok 4 — dowód zmiany. Po zamknięciu package_sha256 evidence-package przyjmuje inną wartość (integralność łańcucha), co jest weryfikowalnym śladem zamknięcia. LIVE
close ≤ proof. Zamknięcie incydentu jest funkcją dowodu, nie deklaracji. Jeśli retest nie osiąga CONFIRMED, incydent wraca do fixing (pętla). To jedyna waluta zaufania warstwy remediacji: status ≤ dowód.

5 · Akceptacja ryzyka / wyjątek (risk acceptance / exception)

Nie każdą podatność da się (od razu) naprawić. Ścieżka świadomej akceptacji ryzyka lub wyjątku ma być jawna, ograniczona czasowo i zatwierdzona.

Risk acceptance

Świadoma, udokumentowana decyzja o niepodejmowaniu naprawy (lub odroczeniu) z uzasadnieniem, właścicielem ryzyka i datą przeglądu.

Status: ROADMAP — model danych + workflow zatwierdzania w planie.

Exception (wyjątek czasowy)

Ograniczony czasowo wyjątek od SLA/polityki (np. mitigacja kompensacyjna zamiast pełnej naprawy), z terminem wygaśnięcia.

Status: ROADMAP — automatyczne wygaszanie + przypomnienia w planie.

Approval trail

Ślad zatwierdzenia (kto zaakceptował ryzyko, kiedy, na jak długo) wpięty w audit log i pakiet DORA/TIBER.

Status: ROADMAP.

Do czasu dostarczenia tej ścieżki: akceptacja ryzyka odbywa się poza systemem (decyzja operatora/organizacji) i nie zamyka incydentu w rozumieniu close-with-evidence. Incydent pozostaje otwarty ze statusem odzwierciedlającym stan faktyczny.

6 · Eksport tasku do Jira / GitHub (LIVE MVP)

Właściciel może wyeksportować incydent jako task do zewnętrznego trackera przez /incidents/:id/ticket — most między warstwą dowodową ipIII a operacyjnym backlogiem zespołu.

Payload tasku (MVP) — tytuł, severity (P0–P3), opis, odsyłacz do incydentu ipIII, link do evidence-package (JSON/PDF + package_sha256). Endpoint GET/POST /api/ip3/v1/incidents/:id/ticket. LIVE MVP
Zakres MVP — generowanie ładunku tasku (Jira/GitHub Issue) z danymi incydentu. Dwukierunkowa synchronizacja statusu (webhook z Jira/GitHub → transition w ipIII), automatyczne aktualizacje i zamykanie po stronie trackera = ROADMAP.
Element eksportuZakresStatus
Generowanie tasku (Jira / GitHub Issue)tytuł + severity + opis + linki (incydent, evidence-package, hash)LIVE MVP
Deep-link zwrotny do ipIIItask odsyła do incydentu i dowodu w orchestratorzeLIVE MVP
Sync statusu (tracker → ipIII)webhook zamknięcia w Jira/GitHub → transition/retestROADMAP
Auto-provisioning projektu/boardamapowanie org → projekt trackera, pola customROADMAP

Endpointy warstwy remediacji

EndpointFunkcjaStatus
POST /api/ip3/v1/incidents/:id/assignPrzypisanie właściciela (owner), start zegara SLA.LIVE MVP
POST /api/ip3/v1/incidents/:id/transitionPrzejście lifecycle (open→triaged→assigned→fixing→retest→closed), audit log.LIVE MVP
… /transition → closedZamknięcie bramkowane dowodem CONFIRMED (422 bez dowodu; F4 zamknięty).LIVE
GET/POST /api/ip3/v1/incidents/:id/ticketEksport tasku do Jira/GitHub (payload + linki + hash).LIVE MVP
Task board / eskalacja / remindersKanban, auto-eskalacja po przekroczeniu SLA, przypomnienia.ROADMAP

Kanon dowodowy dla statusów LIVE = roadmap-dev → Evidence Matrix (nie powielamy liczników testów na tej stronie). Kanon statusu = status-matrix.

Reguła statusów (§16)

Każdy element tej strony nosi dokładnie jeden status. To jedyna waluta zaufania warstwy remediacji.

StatusZnaczenieWarunek nadania
LIVEDziała z dowodem (kod + test + endpoint).Egzekwowane w DB / zweryfikowane w Evidence Matrix.
LIVE MVPDziała w minimalnym zakresie z realnym endpointem.Endpoint istnieje i odpowiada; zakres świadomie ograniczony.
ROADMAPSpecyfikacja docelowa, jeszcze nie zbudowane.Opisane kryteria, brak działającego kodu.
GAPLuka bez pokrycia dowodowego.Brak dowodu — nie wolno przedstawiać jako fakt.
Granica etyczna i prawna. Warstwa remediacji jest narzędziem obrony i zgodności (GRC/blue). Nie wykonuje nieautoryzowanych skanów, exploitacji ani hack-back. Retest oznacza walidację naprawy, nie ponowny atak poza zakresem. Wszelkie działania o charakterze testu bezpieczeństwa wyłącznie w granicach pisemnych Rules of Engagement. Ta strona nie zawiera payloadów ani instrukcji ofensywnych. Terminy SLA i mapowania obowiązków mają charakter orientacyjny (DECISION-SUPPORT), nie stanowią porady prawnej.
Zasada nadrzędna. Remediacja to nie zmiana etykiety statusu — to łańcuch dowodowy zakończony retestem CONFIRMED. Assign, SLA i lifecycle są dostarczone jako LIVE MVP; task board, eskalacja i przypomnienia są jawnie oznaczone jako ROADMAP. Bez dowodu CONFIRMED nie ma zamknięcia (§16). Kanon testów: roadmap-dev. Kanon statusu: status-matrix.