Warstwa §4.7 orkiestratora: maszyna stanów działania naprawczego (remediation) i twarda reguła zamknięcia. Nic nie zostaje uznane za naprawione bez dowodu naprawy, retestu, właściciela, daty, statusu dowodowego i zdarzenia audytowego. To ostatnie ogniwo łańcucha „incydent → wzmocniona odporność".
Działanie naprawcze to nie checkbox. Przejście do stanu VERIFIED wymaga sześciu warunków spełnionych łącznie — inaczej maszyna stanów odrzuca tranzycję. Ta reguła jest już egzekwowana w kodzie PoC (gałąź auth-skeleton), nie tylko opisana.
Zgodnie z §16 rozdzielamy to, co ma pokrycie dowodowe, od architektury docelowej.
Ścieżka odczytu /api/ip3/* serwuje dane statusów i incydentów (tylko odczyt). Weryfikowalne przez smoke test.
Gałąź auth-skeleton egzekwuje: zamknięcie działania tylko z dowodem o statusie CONFIRMED. Zestaw testów 15/15 PASS.
Prod smoke potwierdza dostępność read-path i spójność status.json. Bez zielonego smoke — brak deployu.
Każde działanie naprawcze (action) powiązane z findingiem lub incydentem przechodzi przez zamknięty zbiór stanów. Tranzycje są jednokierunkowe poza jawnym REOPENED. Stan VERIFIED jest bramkowany (patrz reguła zamknięcia).
| Status | Znaczenie | Warunek wejścia | Dozwolone przejścia |
|---|---|---|---|
| OPEN | Działanie zarejestrowane, brak właściciela | Powstało z findingu / incydentu | → ASSIGNED, CLOSED (odrzucone) |
| ASSIGNED | Przypisany owner | Wskazano właściciela + termin | → IN_PROGRESS, BLOCKED |
| IN_PROGRESS | Naprawa w toku | Owner rozpoczął pracę | → REMEDIATED, BLOCKED |
| BLOCKED | Zablokowane (zależność, decyzja, budżet) | Wskazano blocker + uzasadnienie | → IN_PROGRESS, RISK_ACCEPTED |
| REMEDIATED | Naprawa wdrożona, oczekuje na retest | Załączony dowód naprawy | → RETEST_PENDING |
| RETEST_PENDING | Retest zlecony / w kolejce | Zlecony retest (owner ≠ wykonawca) | → VERIFIED, REOPENED |
| VERIFIED | Potwierdzone retestem — bramkowane | 6 warunków łącznie (poniżej) | → CLOSED, REOPENED |
| RISK_ACCEPTED | Ryzyko formalnie zaakceptowane | Decyzja właściciela ryzyka + podpis | → CLOSED, REOPENED |
| CLOSED | Zamknięte (naprawione lub zaakceptowane) | Z VERIFIED lub RISK_ACCEPTED | → REOPENED |
| REOPENED | Wznowione (retest fail / regresja / nowy dowód) | Dowód, że problem wrócił / nie zniknął | → ASSIGNED, IN_PROGRESS |
Nie można przejść do VERIFIED bez spełnienia wszystkich sześciu warunków. Reguła (1) — dowód o statusie CONFIRMED — jest już egzekwowana w kodzie PoC (gałąź auth-skeleton, 15/15 test PASS); pozostałe warunki są w specyfikacji docelowej (ROADMAP).
Artefakt potwierdzający wdrożenie (diff/PR, wpis konfiguracji, ticket zmiany, screenshot, hash). Status dowodu musi być CONFIRMED, nie GAP/SYMULACJA.
Powtórzenie testu, który wykrył problem — z wynikiem PASS. Wykonawca retestu ≠ owner naprawy (rozdział ról).
Jednoznaczny właściciel działania (osoba/zespół). Bez ownera brak odpowiedzialności — tranzycja odrzucona.
Znacznik czasu naprawy i retestu (UTC). Umożliwia liczenie MTTR i zgodność zegarów raportowych.
Poziom pewności dowodu (0–100) i klasa (CONFIRMED / GAP / SYMULACJA). VERIFIED wymaga CONFIRMED.
Niezmienialny wpis do dziennika audytu (kto, co, kiedy, na jakim dowodzie). Ślad dla KNF / CSIRT / DPO.
transition(action, VERIFIED) zwraca sukces tylko gdy AND(dowód, retest, owner, data, evidence_status=CONFIRMED, audit_event). Brak choćby jednego warunku = REJECTED z powodem. W PoC egzekwowany jest warunek dowodu (CONFIRMED); reszta bramki jest w ROADMAP.
Kanoniczny przepływ od ustalenia pentestowego (w ramach autoryzowanego RoE) do zweryfikowanej naprawy. Zero payloadów, zero instrukcji ofensywnych — wyłącznie proces zarządczy.
PLAYBOOK §11.1 PENTEST FINDING -> REMEDIATION -> VERIFIED
============================================================
PRECONDITION:
- Pisemne RoE (Rules of Engagement) obowiazuje i jest waine.
- Zakres, okno czasowe, kontakt eskalacyjny — zatwierdzone.
- Brak dzialania poza zakresem. Brak hack-back. Brak exploitacji
poza uzgodnionym scope. (regula granicy — patrz disclaimer)
[1] INTAKE FINDINGU
finding := { tytul, severity(P0-P3), asset, dowod(PoC-ref),
CVE?/CWE?, repro-steps(opis, BEZ payloadu) }
-> rejestracja jako action.status = OPEN
-> nadanie public_id, powiazanie z incydentem/assetem
[2] TRIAGE + PRIORYTET
severity -> P0/P1/P2/P3 (P0/P1 => human-in-the-loop)
duplikat? -> merge do istniejacego action
-> action.status = ASSIGNED (owner + termin wg SLA)
[3] REMEDIATION (owner)
plan naprawy -> wdrozenie (patch/config/segmentacja/rotacja)
-> action.status = IN_PROGRESS
zablokowane? -> BLOCKED (blocker + uzasadnienie)
-> ew. RISK_ACCEPTED (decyzja wlasc. ryzyka + podpis)
[4] DOWOD NAPRAWY (warunek 1 bramki)
zalacz artefakt: PR/diff-ref, wpis konfig, ticket zmiany, hash
evidence.status := CONFIRMED (nie GAP / nie SYMULACJA)
-> action.status = REMEDIATED
[5] RETEST (warunek 2; wykonawca != owner)
powtorz test wykrywajacy -> wynik PASS/FAIL
-> action.status = RETEST_PENDING
FAIL -> action.status = REOPENED (dowod regresji) -> [3]
[6] BRAMKA VERIFIED (AND: 1..6)
AND( dowod_naprawy, retest_PASS, owner, data,
evidence.status=CONFIRMED, audit_event )
= TRUE -> action.status = VERIFIED
= FALSE -> REJECTED(powod) — pozostaje w RETEST_PENDING
[7] CLOSURE + AUDIT
audit_event := { kto, co, kiedy, dowod-ref, decyzja } (immutable)
-> action.status = CLOSED
-> aktualizacja odpornosci (L4): loop incydent -> wzmocnienie
-> ew. wpis do zegara raportowego (NIS2 24/72h, RODO 33/34)
[8] REOPEN (w kadym momencie)
nowy dowod / regresja / retest fail
-> action.status = REOPENED -> [2]
============================================================
GRANICA: caly przeplyw dziala TYLKO w ramach pisemnego RoE.
Poza RoE system nie testuje i nie eksploituje. Zero payloadow.
Wartości demonstracyjne — ilustrują format panelu, nie stan realnej infrastruktury. Dane realne pojawią się po implementacji write-path (ROADMAP).
| Priorytet | Klasa findingu | Reżim zamknięcia |
|---|---|---|
| P0 | Krytyczny — czynny wektor, dane, ciągłość | Human-in-the-loop obowiązkowy; VERIFIED tylko z pełną bramką 6/6 |
| P1 | Wysoki — realna ekspozycja | Human-in-the-loop; retest przez niezależnego wykonawcę |
| P2 | Średni — ograniczony wpływ | Bramka 6/6; retest może być zautomatyzowany |
| P3 | Niski / informacyjny | Bramka 6/6 lub RISK_ACCEPTED z uzasadnieniem |
/api/ip3/*, smoke test oraz reguła dowodu w PoC (auth-skeleton, 15/15 PASS). Write-path, pełna bramka 6/6, retest engine i audit ledger są ROADMAP — do implementacji z kodem, testem i endpointem, zanim zostaną oznaczone jako LIVE.