Jedna liczba dla zarządu: jaki procent findingów jest w pełni udowodniony — ma dowód CONFIRMED, retest, właściciela, SLA, mapowanie regulacyjne i chain-of-custody. To miara kompletności dokumentacji dowodowej, nie ocena odporności infrastruktury. Wysoki wynik = „wiemy i mamy udokumentowane", nie „jesteśmy bezpieczni".
Każdy finding oceniamy w 6 binarnych wymiarach (spełniony = 1, brak = 0). Wynik findingu to średnia jego 6 wymiarów. Wynik zbioru to średnia po findingach. Prosty, audytowalny, liczony z realnych rekordów bazy — bez wag uznaniowych.
Każdy wymiar jest binarny i weryfikowalny z rekordu w bazie — brak ocen „na oko".
Finding ma powiązany dowód o statusie CONFIRMED (nie tylko MEDIA_SIGNAL / zgłoszenie). Import z pentestu to sygnał, nie dowód naprawy.
Źródło: tabela evidence, status = CONFIRMED.
Wykonano retest weryfikujący (potwierdzenie istnienia lub naprawy), z odrębnym rekordem i znacznikiem czasu.
Źródło: rekord retestu powiązany z incydentem.
Finding ma przypisanego właściciela odpowiedzialnego za remediację (osoba/zespół), nie pole puste.
Źródło: pole owner / assignee incydentu.
Findingowi przypisano termin (deadline/priorytet SLA) — jest zegar, wobec którego mierzymy opóźnienie.
Źródło: pole terminu / priorytet P0–P3.
Finding zmapowany na obowiązek (DORA / NIS2 / RODO / AI Act) przez Legal Trigger Engine — wiadomo, co z niego wynika prawnie.
Źródło: Legal Engine — legal-triggers.
Artefakt dowodowy ma nieprzerwany łańcuch pochodzenia: hash sha256 + ślad audytowy kto/co/kiedy.
Źródło: manifest evidence-package, package_sha256.
Ilustracja metodyki na 5 findingach demonstracyjnych. SIMULATION — wartości poglądowe, nie stan realnej infrastruktury.
| Finding (syntetyczny) | CONFIRMED | Retest | Owner | SLA | Mapow. | Chain | Wynik findingu |
|---|---|---|---|---|---|---|---|
| F-01 · SQLi w module raportów | 1 | 1 | 1 | 1 | 1 | 1 | 6/6 = 100% |
| F-02 · Podatny komponent (CVE-KEV) | 1 | 0 | 1 | 1 | 1 | 1 | 5/6 = 83% |
| F-03 · Błędna konfiguracja TLS | 1 | 0 | 1 | 1 | 0 | 1 | 4/6 = 67% |
| F-04 · Ekspozycja danych osobowych | 0 | 0 | 1 | 1 | 1 | 1 | 4/6 = 67% |
| F-05 · Brak logowania zdarzeń | 0 | 0 | 1 | 0 | 0 | 1 | 2/6 = 33% |
| Suma wymiaru (z 5) | 3/5 | 1/5 | 5/5 | 4/5 | 3/5 | 5/5 | Coverage = 70% |
Coverage % = (100 + 83 + 67 + 67 + 33) / 5 = 350 / 5 = 70% Odczyt po wymiarach (gdzie jest luka): CONFIRMED ....... 3/5 (60%) ← 2 findingi bez dowodu potwierdzonego Retest .......... 1/5 (20%) ← NAJSŁABSZY wymiar: brak retestów Owner ........... 5/5 (100%) ← każdy finding ma właściciela SLA ............. 4/5 (80%) Mapowanie ....... 3/5 (60%) Chain-of-custody 5/5 (100%) ← integralność artefaktów pełna
Progi pomagają czytać liczbę, ale zawsze patrz na rozkład po wymiarach — 70% z załamanym retestem znaczy co innego niż 70% równomierne.
| Zakres | Odczyt | Typowa akcja zarządu |
|---|---|---|
| 85–100% | Bardzo dobre pokrycie dowodowe. Findingi są udokumentowane end-to-end. | Utrzymanie procesu; przegląd wyjątków. |
| 70–84% | Dobre pokrycie z widoczną luką w 1–2 wymiarach (np. retesty). | Domknąć najsłabszy wymiar; przypisać właścicieli luk. |
| 50–69% | Częściowe pokrycie. Istotna część findingów bez dowodu/retestu. | Plan naprawczy dokumentacji; priorytet CONFIRMED + retest. |
| < 50% | Niskie pokrycie — proces dowodowy niedojrzały lub świeży zaciąg findingów. | Uruchomić dyscyplinę close-with-evidence; zbudować chain-of-custody. |
Narzędzie ilustracyjne — liczy tę samą średnią co wzór wyżej, lokalnie w przeglądarce. Zaznacz spełnione wymiary dla każdego findingu. SIMULATION — nie zapisuje nic, nie łączy się z bazą.
GET /api/ip3/v1/incidents/:id/coverage LIVE MVP — zwraca 6 wymiarów + wynik findingu, liczone z realnych rekordów PostgreSQL (evidence / retest / owner / SLA / legal-triggers / chain-of-custody). Kanon dowodowy dla liczb testów i statusów: Evidence Matrix (/roadmap-dev). Weryfikuj bieżący stan i liczby PASS w tej matrycy — ta strona nie podaje własnych „NN/NN".Kanon statusów wszystkich elementów portalu: Status Matrix. Definicje dowodów i artefaktów: Evidence Layer.