K0NSULT // ai-truth/ipIII
k0nsult.cloud / ai-truth / ipIII / landing-appsec

Od skanu do dowodu zamknięcia — dla AppSec i developerów

Masz plik z Burp Suite, Nessusa, skanera SARIF albo eksport z DefectDojo. Importujesz go do ipIII — dostajesz evidence package z hashem integralności, zadanie remediacji trafia do właściwego zespołu, a po poprawce retest zamyka incydent z dowodem, nie na słowo. To jest działające MVP jednej ścieżki: import → evidence → zadanie → retest → close. Sample pack możesz pobrać bez logowania i zobaczyć realny JSON, zanim cokolwiek podłączysz.

Import parsera do zamkniętego incydentu z dowodem — jedna ścieżka, zero ukrytych kroków.

ipIII to MVP warstwy evidence dla zespołów AppSec: parsery Burp / Nessus / SARIF / DefectDojo / CSV zamieniają surowy raport skanera na finding w bazie, z którego powstaje evidence package (manifest + sha256 + chain-of-custody), zadanie remediacji dla dewelopera i retest, który zamyka incydent razem z dowodem naprawy. Nie musisz wierzyć nam na słowo — pobierz próbkę i sprawdź hash sam.

ŚCIEŻKA: import (SARIF/Burp/Nessus/DefectDojo)finding + evidence packagezadanie remediacjiretestclose z dowodem

Co zyskuje zespół AppSec

Jeden import, nie pięć excelów

Zamiast ręcznie zbierać wyniki z kilku skanerów do jednego arkusza dla managera, importujesz plik parsera i dostajesz znormalizowany finding z ID skanera, severity i metadanymi w jednym miejscu.

LIVE parsery Burp/ZAP/Nessus/CSV/SARIF (Fala Wisienka #1, testy 13/13 unit).

Zadanie remediacji, nie tylko finding

Z findingu powstaje zadanie z przypisanym właścicielem, priorytetem i terminem — deweloper widzi konkretną rzecz do naprawy, nie surowy log skanera do interpretacji.

MVP szkielet zadania; integracja z Jira/GitHub Issues jako ROADMAP.

Dowód, nie deklaracja "naprawione"

Retest po poprawce generuje nowy wpis w evidence package — zamknięcie incydentu ma za sobą hash i chain-of-custody, nie tylko zmianę statusu w tabeli.

LIVE evidence-package JSON z package_sha256.

Sprawdzasz sam, zanim zaufasz

Sample pack (Burp/Nessus/SARIF demo + evidence-package demo) jest publiczny i bez logowania — możesz zweryfikować hash i strukturę danych przed integracją z realnym środowiskiem.

PUBLIC /samples — brak auth.

Jak to działa — pod maską

Cztery kroki, każdy z dowodem. Szczegóły parserów i endpointów opisane osobno na /connectors i /api-explorer.

KrokCo się dziejeCo powstaje jako dowódStatus
1. Import Wgrywasz plik z Burp Suite (XML), Nessusa (CSV/.nessus), SARIF (skaner statyczny) lub eksport DefectDojo. Parser normalizuje pola do wspólnego formatu findingu. Rekord finding w PostgreSQL z ID źródłowym skanera, severity, opisem, znacznikiem czasu. LIVE
2. Evidence package Z findingu(ów) powiązanych z incydentem generowany jest pakiet: manifest + sha256 całości + log chain-of-custody (kto, kiedy, co zmienił). Plik JSON (i opcjonalnie PDF board-pack) do pobrania i zweryfikowania hasha przez /verify. LIVE
3. Remediation task Finding zamienia się w zadanie do wykonania — z priorytetem wynikającym z severity/CVSS/EPSS (offline hint) i przypisanym właścicielem. Rekord zadania powiązany z findingiem; status "otwarte/w toku/do retestu". MVP
4. Retest → close Po poprawce zespół zgłasza retest; jeśli finding nie występuje ponownie w kolejnym imporcie, incydent zamyka się razem z dowodem (nowy wpis w evidence package, nie tylko zmiana statusu). Zamknięty incydent z pełnym łańcuchem: import → finding → task → retest → close, wszystko z sha256. LIVE
Coverage score, nie "100% bezpieczne". Ile z Twoich importów ma pełny łańcuch dowodowy (od findingu do zamknięcia z evidence) pokazuje /coverage-score — to metryka pokrycia dowodowego procesu, nie deklaracja poziomu bezpieczeństwa aplikacji.

Jak zacząć — 4 kroki bez wdrożenia

Pobierz sample pack. Wejdź na /ai-truth/ipIII/samples — bez logowania, zobaczysz listę plików demo: import Burp (XML), import Nessus (CSV), evidence-package (JSON), kolekcja Postman do API.
Zweryfikuj hash. Otwórz evidence-package demo i sprawdź package_sha256 na /verify — zobaczysz, że manifest i hash są spójne, zanim zaufasz realnym danym.
Sprawdź konektory dla swoich narzędzi. Na /connectors jest lista wspieranych formatów (Burp, ZAP, Nessus, SARIF, DefectDojo, CSV) i to, co jest LIVE, a co ROADMAP.
Podłącz API testowo. /api-explorer pokazuje endpointy /api/ip3/v1 z przykładowymi żądaniami — możesz przetestować import na środowisku deweloperskim przed integracją z pipeline CI/CD. Doku dla developerów zbiorczo na /dev.

Czego dziś nie ma — uczciwie

Zgodnie z doktryną claim ≤ proof: to, czego nie potwierdzamy kodem i testem, oznaczamy ROADMAP, nie LIVE.

ObszarStan dziśStatus
Integracja z Jira / GitHub Issues (auto-tworzenie ticketu)Zadanie remediacji istnieje w ipIII; eksport do zewnętrznego trackera nie jest jeszcze zautomatyzowany.ROADMAP
MSSP-mode / transport do SIEM strumieniowoImport dziś z pliku parsera, nie ze strumienia zdarzeń SIEM.ROADMAP
Automatyczne odpytanie CVE/EPSS onlineWzbogacanie działa offline z seedu przy imporcie.MVP (offline)
Pluginy IDE (podpowiedzi w edytorze)Nie istnieją — dziś przepływ jest przez import pliku i API.ROADMAP

FAQ dla AppSec i developerów

Czy muszę się logować, żeby zobaczyć przykładowe dane?

Nie. Sample pack na /samples jest publiczny — zawiera demo importu Burp/Nessus/SARIF oraz przykładowy evidence-package w JSON, bez konieczności zakładania konta.

Jakie formaty importu są dziś realnie wspierane?

Burp Suite (XML), Nessus (CSV/.nessus), SARIF (skanery statyczne), eksport DefectDojo i generyczny CSV. Pełna lista z rozróżnieniem LIVE/ROADMAP jest na /connectors.

Jak sprawdzę, że evidence package nie został podmieniony?

Każdy pakiet ma package_sha256. Wejdź na /verify, wklej hash z Twojego pliku i porównaj — dziś to weryfikacja integralności hashem, nie kwalifikowany podpis PAdES/TSA (ten element jest oznaczony jako ROADMAP na stronie known-limitations).

Czy mogę podłączyć to do naszego pipeline CI/CD?

API do importu jest dostępne i opisane na /api-explorer oraz /dev. Dziś to integracja przez wywołania API/plik, bez gotowego pluginu CI — wdrożenie w pipeline wymaga własnego skryptu wywołującego endpoint.

Co dokładnie znaczy "coverage score"?

To odsetek incydentów, które przeszły pełną ścieżkę import → finding → evidence → retest → close z dowodem, względem wszystkich zaimportowanych findingów. Metodologia i liczby na /coverage-score — to metryka pokrycia procesu dowodowego, nie ocena bezpieczeństwa całej aplikacji.

Czy to zastępuje mój pentest albo red-team?

Nie. ipIII to warstwa evidence dla wyników, które już masz ze skanerów i testów — porządkuje dowód i remediację. Sam proces testowania (skan, pentest) wykonujesz swoimi narzędziami w granicach ustalonych RoE.

Następny krok

Zobacz dowód, zanim zapytasz o wdrożenie.

Nie prosimy o rozmowę handlową na starcie. Pobierz sample pack, zweryfikuj hash evidence-package, sprawdź listę konektorów dla swoich skanerów — dopiero potem, jeśli ścieżka pasuje do Twojego zespołu, przejdź do dokumentacji API i zaplanuj integrację z pipeline.

Granica etyczna i prawna. ipIII jest narzędziem obrony i zgodności (GRC/blue), decision-support, nie poradą prawną. Nie wykonuje skanów ani testów ofensywnych za Ciebie — importuje i porządkuje wyniki testów wykonanych w granicach pisemnych Rules of Engagement.

Powiązane: pełna macierz statusów → /status-matrix · uczciwy rejestr ograniczeń → /known-limitations.