Raport pentestu czy AppSec sam w sobie nie zmienia decyzji zarządu — potrzebuje przejścia przez normalizację, przypisanie odpowiedzialności, dowód naprawy i skrót, który da się przeczytać w 5 minut na komitecie ryzyka. Ta strona opisuje dowodliwą ścieżkę MVP w ipIII: import → normalizacja severity → evidence (hash + chain-of-custody) → owner/SLA → retest → close → Board Pack → Regulatory Pack. Każdy krok ma tu jawnie oznaczony status LIVE albo ROADMAP — zgodnie z doktryną claim ≤ proof.
Problem, który rozwiązuje ta ścieżka, nie jest techniczny — jest komunikacyjny. Zespół bezpieczeństwa ma raport PDF/JSON z narzędzia skanującego albo od pentestera. Zarząd i audyt potrzebują czegoś innego: kto jest odpowiedzialny, do kiedy, jaki jest dowód że problem faktycznie naprawiono, i czy termin regulacyjny jest zagrożony. ipIII spina te dwa światy jednym pipeline'em, bez ręcznego przepisywania danych z arkusza do arkusza.
Punktem wejścia jest wynik pracy, którą już wykonują zespoły bezpieczeństwa: skan AppSec, raport pentestu, eksport z narzędzia DAST/SAST. ipIII nie zastępuje tych narzędzi ani pentesterów — konsumuje ich wyjście. Konektory LIVE parsują formaty Burp, ZAP, Nessus oraz generyczny CSV; opis parserów, testów i zakresu wsparcia jest na stronie /connectors. Jeśli format skanera nie jest jeszcze wspierany, import ręczny przez CSV pozostaje ścieżką zapasową (nie blokuje pilota).
Burp Suite (XML), OWASP ZAP (XML/JSON), Nessus (.nessus), CSV generyczny (mapowanie kolumn).
Tytuł findingu, opis, dotknięty zasób/endpoint, oryginalny severity narzędzia, referencje (CVE/CWE jeśli podane), znacznik czasu skanu.
Nie wykonujemy skanu ani testu penetracyjnego. Import wymaga istniejącego, uprawnionego wyniku dostarczonego przez klienta lub jego dostawcę testów.
Każdy skaner ma własną skalę: Burp mówi „High/Medium/Low/Info", Nessus liczy CVSS bazowy, pentester w raporcie
PDF może użyć opisowej kategorii „Krytyczny". Bez normalizacji porównanie findingów z trzech różnych źródeł
w jednym Board Packu jest bez sensu — priorytety byłyby niespójne. ipIII mapuje wejściowy severity na wspólną
skalę critical / high / medium / low / info, z regułami mapowania per źródło (np. CVSS ≥ 9.0 →
critical), oraz — tam gdzie finding ma powiązane CVE — dowiązuje offline hint CVSS/EPSS/KEV z seedu (opisane
w rejestrze ograniczeń jako dane odświeżane okresowo, nie w czasie rzeczywistym).
Ta normalizacja jest krokiem, który najczęściej ginie przy ręcznym sklejaniu arkuszy Excela z trzech zespołów — i który najbardziej wpływa na wiarygodność końcowego Board Packu wobec audytu.
Sam finding to twierdzenie („port X jest otwarty", „endpoint Y jest podatny na Z"). Twierdzenie bez dowodu nie
wytrzymuje pytania audytora „skąd to wiadomo i czy dane nie zostały zmienione po fakcie". Dlatego każdy import
i każdy retest w ipIII generuje evidence-package: manifest zawartości, sha256 całego pakietu
oraz zapis chain-of-custody (kto, kiedy, jaką operację wykonał na danym evidence) w bazie. To pozwala
wykazać integralność danych między momentem importu a momentem prezentacji w Board Packu — bez ingerencji
w oryginalny plik źródłowy.
Ważne rozgraniczenie, zgodnie z rejestrem ograniczeń: sha256 dowodzi niezmienności treści
pakietu, ale to nie jest kwalifikowany podpis elektroniczny (PAdES) ani znacznik czasu TSA — te dwa
elementy są dziś oznaczone jako ROADMAP, nie LIVE. Kto chce zweryfikować hash
konkretnego evidence-package niezależnie od interfejsu ipIII, może to zrobić na stronie
/verify.
Finding bez właściciela to finding, który nigdy nie zostanie naprawiony na czas. Każdy zaimportowany i znormalizowany finding jest przypisywany do ownera (osoby lub zespołu) z terminem SLA wyliczonym na podstawie severity — krytyczne i wysokie dostają krótsze okno niż średnie i niskie. To przypisanie jest tym, co odróżnia „listę problemów" od „planu naprawy z odpowiedzialnością". Szczegółowy opis mechaniki przypisania, eskalacji po przekroczeniu SLA i integracji z systemami ticketowymi jest na stronie /remediation.
Finding nie jest uznawany za zamknięty na podstawie deklaracji „naprawione". Zamknięcie wymaga retestu — ponownego zbadania tego samego zasobu — i dołączenia nowego evidence, które potwierdza, że warunek podatności już nie występuje (albo że ryzyko zostało formalnie zaakceptowane przez ownera z uzasadnieniem, jeśli naprawa nie jest możliwa w danym terminie). Dopiero taki komplet — finding + evidence importu + evidence retestu + decyzja ownera — trafia do statusu „closed" w rejestrze.
To jest różnica między „workflow do zarządzania listą" a rzeczywistym łańcuchem dowodowym: audytor pytający „skąd wiadomo, że ten krytyczny finding jest naprawdę zamknięty" dostaje odpowiedź w postaci konkretnego evidence-package z hashem, a nie tylko zmiany statusu w polu tekstowym.
Board Pack to wygenerowany dokument, który agreguje stan wszystkich findingów w danym oknie czasowym: liczbę krytycznych/wysokich w toku, procent zamkniętych na czas (SLA compliance), listę findingów przeterminowanych z nazwanym ownerem, oraz skrót trendu wobec poprzedniego okresu. Zarząd i komitet ryzyka nie czytają surowego raportu pentestu — czytają ten skrót, z odsyłaczem do pełnego evidence dla każdej pozycji, jeśli potrzebują drążyć głębiej. Mechanikę generowania i przykładową strukturę Board Packu opisuje strona /ciso-board-pack; gotowy przykładowy dokument (dane syntetyczne) można obejrzeć na /samples.
Miarą jakości Board Packu jest nie tylko kompletność, ale też pokrycie dowodowe — ile z prezentowanych twierdzeń ma za sobą realny evidence-package, a nie tylko wpis w tabeli. Ten wskaźnik liczy i pokazuje osobno strona /coverage-score.
Część findingów rodzi obowiązek zgłoszenia do organu (np. w reżimie DORA, NIS2, ewentualnie RODO przy incydencie z danymi osobowymi) — z twardym terminem liczonym w godzinach, nie tygodniach. Legal Trigger Engine w ipIII mapuje typ incydentu na potencjalny obowiązek i sugerowany termin, ale jest to wsparcie decyzji (decision-support), nie porada prawna. Każdy draft zgłoszenia do organu wymaga przeglądu prawnika lub kancelarii przed wysyłką — to ograniczenie jest trwałe z założenia i nie jest elementem, który planujemy „zautomatyzować w pełni" w przyszłej wersji.
| Krok pipeline'u | Co działa dziś | Status |
|---|---|---|
| Import (Burp/ZAP/Nessus/CSV) | Parsery z testami jednostkowymi i integracyjnymi na żywej PostgreSQL. | LIVE |
| Normalizacja severity | Mapowanie źródło→wspólna skala + offline hint CVSS/EPSS/KEV z seedu. | LIVE dane offline |
| Evidence (hash + chain-of-custody) | sha256 pakietu, manifest, zapis operacji w bazie. |
LIVE |
| Podpis PAdES / znacznik TSA | Nie wdrożone — dziś tylko hash integralności. | ROADMAP (P1) |
| Owner / SLA | Przypisanie i wyliczenie terminu wg severity, na żywej bazie. | LIVE |
| Retest / close-with-evidence | Zamknięcie wymaga nowego evidence-package z retestu. | LIVE |
| Board Pack | Generowany dokument skrótu dla zarządu, z odsyłaczem do evidence. | LIVE |
| Regulatory Pack (draft do organu) | Legal Trigger Engine sugeruje obowiązek/termin — wymaga przeglądu prawnika. | LIVE draft decision-support |
| SIEM ingestion (strumień zdarzeń) | Dziś import z plików eksportu, nie strumień z centrum detekcji. | ROADMAP |
Jedno miejsce, w którym widać status wszystkich findingów ze wszystkich źródeł, z ownerem i SLA — zamiast pytania zespołu co tydzień „na jakim to jest etapie".
Board Pack z odsyłaczem do evidence każdej pozycji zamiast surowego PDF-a od pentestera, którego nikt na sali nie ma czasu przeczytać w całości.
Draft Regulatory Pack jako punkt startowy do oceny obowiązku zgłoszenia — z jasnym zastrzeżeniem decision-support, nie gotowej decyzji.
Możliwość dostarczenia raportu w standardowym formacie narzędzia (Burp/ZAP/Nessus) bez ręcznego przepisywania wyników do arkusza klienta.
Pełny opis tego, co jest dowodliwe (kod, testy, żywy endpoint) a co jest deklaracją planowaną, jest scentralizowany na stronie /trust-center. Zasada jest prosta: element bez dowodu jest oznaczony jako ROADMAP, nigdy jako LIVE — niezależnie od tego, jak bardzo skraca to opowieść sprzedażową.
Powiązane: mechanika przypisania i SLA → /remediation · wskaźnik pokrycia dowodowego → /coverage-score · formaty i parsery wejściowe → /connectors · pełna struktura Board Packu → /ciso-board-pack.